Post-Acquisition Ops

Run More Companies Without Making Every Decision Central

For a holdco founder, operating partner or shared-services lead deciding which recurring work to reuse across companies and which authority must stay local.

Uli PrantzBuilds and operates all-agents
Published
Key takeaways

Key takeaways

  • Portfolio operations should make recurring work visible and supportable across companies; it should not turn every local choice into a central approval.
  • Standardize definitions, evidence and control interfaces before forcing one procedure or system onto every company.
  • Reuse a workflow skeleton only where the trigger, output and control objective match. Keep local rules as explicit variants with named owners.
  • A shared service needs a service boundary, request contract, exception owner and verified return state. A central inbox is not an operating model.
Portfolio operations is the discipline of giving several operating companies shared visibility, reusable process structures and clear support boundaries while local managers remain accountable for local results. Centralize evidence-heavy recurring work only when the portfolio can define the service, preserve necessary variation, route exceptions and verify the returned state.

Portfolio operations is an interface between local companies and shared work

A holdco can own several companies without operating them in the same way. The useful portfolio layer is narrower: common definitions, a repeatable review cadence, a few shared capabilities and a clear contract for work that crosses the boundary. Local leaders still own customers, people, safety and operating decisions in their scope.

A ServiceTitan account of a multi-branch home-services group describes a centralized hub alongside partnership with continuing management teams and explicit integration priorities. It is one operator example, not a universal blueprint. The transferable lesson is that the hub needs a defined relationship with the local company; software alone does not create it.

Four portfolio layers and the mistake each prevents.
LayerPortfolio responsibilityLocal responsibility
DefinitionsCommon metric dictionary, reporting period and evidence contractExplain valid local data and exceptions
Workflow skeletonShared states, control points and minimum audit recordOwn local triggers, thresholds and destinations
Shared servicePublished scope, intake, response clock, escalation and return stateSubmit complete evidence and accept or dispute the result
GovernanceDecide what must be common and review cross-company riskRemain accountable for local commitments and execution

Build the common layer in five passes

  1. 01Reconcile the wordsHuman approval
    Compare what each company means by completed, urgent, active, approved and exception. Do not build a common report until the definitions agree or carry an explicit local variant.
  2. 02Inventory recurring workTrigger
    List the process, frequency, consequence, owner dependence, evidence and repeatability. Use actual cases, not department labels. “Finance” is not a process; “assemble the Friday branch pack” is.
  3. 03Select a reusable skeletonCode
    Choose work whose trigger, output and control objective match. Reuse the state model and evidence contract; keep local thresholds and authorities as configuration that a named owner reviews.
  4. 04Publish the service boundaryHuman approval
    State what the central team accepts, what it returns, the response clock, the exception queue and who decides a disputed case. Work outside the boundary stays local.
  5. 05Test one company before the portfolioAI judgment
    Run normal and imperfect cases, reconcile the final state and record interventions. Expand only after the template survives a real local variant.

Centralize the repeatable service, not the accountable judgment

A decision screen for one recurring process. The answer can be hybrid.
QuestionCandidate for shared executionKeep local or narrow
Is the output the same?Comparable record, reconciled report or complete evidence packetDifferent customer promise or legal outcome
Can inputs be specified?Named fields and sources with visible quality checksContext arrives through private relationships or memory
Are exceptions routable?Known types with owners, clocks and closure evidenceNovel cases require local authority with no fallback
Can the effect be verified?Read-back, acknowledgment or reconciled source stateSuccess is subjective or visible only much later
Is authority portable?The central role has explicit permission and limitsThe local manager remains legally or commercially accountable

A process can be split. The central team may collect evidence, normalize fields and prepare a proposal while a local manager approves a customer commitment. The human-in-the-loop guide shows how to keep that boundary permanent rather than treating it as temporary supervision.

Northline standardizes the pack but keeps branch exceptions visible

Simulated portfolio operating mapSimulated example data

Northline is a fictional three-company home-services portfolio. Each branch sends a weekly operating pack. The headings look identical, but “completed job” means technician closeout in one company and customer sign-off in another.

The portfolio team first publishes a metric dictionary and an evidence field for local completion type. A shared workflow checks period, source completeness and arithmetic, then routes definition disputes back to the local controller. Adjustments and final sign-off remain human decisions.

The reusable part is the reporting skeleton and exception record. The local completion rules stay visible. Northline does not claim that one system or connector makes the companies identical.

Measure whether the interface works

  • First-pass completeness: requests accepted without chasing missing evidence.
  • Exception age: time unresolved cases spend without a named owner.
  • Definition disputes: cases blocked because two companies use one label differently.
  • Verified return: completed shared-service items whose intended source state was reconciled.
  • Local overrides: permitted variants used, with owner and reason; track them instead of hiding them.
  • Central interrupts: decisions that still reach the holdco because authority or service boundaries are unclear.

Start with the acquisition process inventory. It separates transition attention from definition strength and gives high-consequence work a control route rather than a readiness badge.

Limitations and when not to use this

  • This is general operating guidance, not legal, tax, accounting, employment, cybersecurity, investment or transaction advice.
  • A shared process can create a single point of failure. Define fallback ownership, recovery and local continuity before moving essential work.
  • Local customer commitments, safety duties, licenses and employment decisions may require local accountable control even when evidence preparation is shared.
  • Northline is simulated. No multi-entity dashboard, connector, customer result, staffing outcome or savings claim is made.

Sources

  1. How to Manage Multiple Service Locations with Len the PlumberServiceTitan Accessed 6 August 2026
  2. The State of Organizations 2026McKinsey & Company Accessed 6 August 2026
  3. Contingency Planning Guide for Federal Information SystemsNIST Accessed 6 August 2026

Inventory the first portfolio processes

Rank transition attention and definition strength before choosing a shared-service candidate.

Inventory the first portfolio processes
About the author

Uli Prantz

Builds and operates all-agents

Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.

Bring one process. We will scope it in 30 minutes.

You leave the call knowing whether it is a fit, what can become code and what still needs a person.

Book a discovery call