Automation in Portfolio Company Value Creation: Where the Hours Actually Are

Automation shows up in most value creation plans now, usually as a line item somewhere between pricing and procurement. It is also one of the least reliably executed items on that list, partly because it gets scoped as a technology initiative when it is really an operations one.

The framing that works better for a sponsor is narrow: automation is a way to break the link between transaction volume and headcount. In a portfolio company pursuing a growth thesis, that link is the thing that quietly consumes the margin expansion the model assumed. This post covers where the recoverable hours actually sit, why portfolio-wide programmes stall, and how to sequence the work so the first company proves the thesis for the rest.

The value is cost avoidance, not cost reduction

Worth separating these two early, because they behave very differently in a deal.

Cost reduction removes existing labour. It is slow, culturally disruptive, and creates a period where the process is running in two modes at once. It also tends to be the version that gets promised and the version that underdelivers.

Cost avoidance is headcount you do not add as volume grows. If a company processes 40% more orders next year with the same back-office team, the saving is real, appears directly in margin, and required nobody to be let go. It is also far easier to get the operating team to cooperate with, because nobody at the company is being asked to automate their own colleagues out of a job.

In a growth thesis, cost avoidance is almost always the larger and more defensible number. It is also the one most consistent with what automation actually does well, which is absorb volume in processes whose cost currently scales linearly with it.

Where the recoverable hours sit

Across most mid-market portfolio companies, the same handful of processes carry the recoverable hours. They share a profile: high frequency, document or message driven, and currently absorbing staff time in proportion to revenue.

• Order and invoice processing. Inbound documents in inconsistent formats, manually keyed into an ERP. Volume scales directly with revenue, which makes it the clearest cost-avoidance case in most companies.
• Customer or client onboarding. Document collection, data entry across several systems, verification steps, and a lot of chasing. Usually slow, usually the first impression the customer gets, and usually staffed by people you would rather have doing something else.
• Quote and proposal preparation. Pulling data from several places into a template. High frequency in any business with a sales motion, and often invisible in the cost base because it sits inside sales roles rather than operations.
• Claims, tickets, or case handling. Classification, routing, status chasing, and updates. Automating the triage layer alone frequently returns more time than automating any single downstream step.
• Management and investor reporting. Assembling the same numbers from the same systems every month. Lower frequency, but it lands on expensive people and it lands during the week everyone is busiest.

The consistency across companies matters more than any individual entry. Two portfolio companies in unrelated sectors often share the same underlying process shape, which is where portfolio-level leverage genuinely exists.

Why portfolio-wide programmes stall

The instinct after a promising diligence read is to design a programme: a platform decision, a centre of excellence, a rollout schedule across the portfolio. This pattern fails often enough to be worth naming.

It front-loads the hardest decision. Choosing a platform before understanding any company's processes in detail means choosing on vendor material rather than on fit.

It delays the first result past the attention span of the sponsor. A rollout designed to touch six companies produces its first measurable hour saved a long way into the programme, which is usually after the operating partner who championed it has moved on to the next priority.

It assumes uniformity that does not exist. Portfolio companies run different systems, at different levels of process maturity, with wildly different data hygiene. A programme designed for the average company fits none of them.

It creates a governance layer with nothing to govern. A steering committee formed before a single workflow exists spends its meetings on the programme rather than on the work.

The alternative is not to abandon portfolio-level thinking. It is to sequence it so that the standardisation follows a proven result rather than preceding it.

The sequence that works

Start with one company and one workflow. Pick the company with the clearest volume, the most cooperative operating team, and an existing system landscape that is not mid-migration. Pick the workflow with the highest frequency, not the one with the most impressive narrative. One trigger, one output, live in weeks.

Measure the hours actually returned. Not documents processed. Hours per week, by role, before and after, with an explicit statement of what those hours are now being used for. This number is the entire basis for everything that follows, so it needs to be defensible enough to survive a sceptical read.

Write down the process shape, not the implementation. The transferable asset across a portfolio is rarely the code, because the systems differ. It is the knowledge of what the process looked like, where the exceptions were, what the exception rate turned out to be, and what the scoping mistakes were. That documentation is what makes the second deployment faster than the first.

Find the same shape elsewhere. Now the portfolio question becomes answerable. Which other companies run a document-driven intake process at meaningful volume? Those are the next candidates, and they now have a proven internal reference rather than a vendor case study.

Then, and only then, consider standardising. Once three companies have run the same shape of workflow, common tooling and shared vendors start to make sense, because the requirements are now known rather than assumed.

Screening a company for fit

A quick screen before committing effort. The disqualifiers are more useful than the qualifiers.

Volume. How many times per week does the candidate process run? Below a few dozen, the business case rarely survives contact with the build cost, however painful the process feels.

Process consistency. Does the work follow a recognisable path most of the time, or is every instance genuinely different? Some variation is fine and is exactly what AI handles well. Total variation means there is no process to automate yet.

System stability. Is an ERP migration, a CRM replacement, or a post-merger systems consolidation underway? If so, wait. Building against systems that are about to be replaced is how you spend the budget twice.

An operational owner with capacity. Someone at the company who owns the process, feels the pain, and has time. This is the most common reason a technically sound project stalls, and it is the hardest to fix from the sponsor side. Enthusiasm at the board level does not substitute for an owner at the company.

Data accessibility. Can the required data be reached through APIs or structured exports, or does it live only inside a system nobody has credentials for? This is usually the difference between a four-week build and a four-month one.

What this looks like at exit

The version of this that carries weight in a sale process is not a slide describing an automation strategy. It is a documented operational change: this process ran at this cost per transaction at entry, it runs at this cost now, volume grew by this much over the period and the team did not.

That is a durable, verifiable margin story, and it is materially different from a technology narrative. Buyers discount narratives. They pay for demonstrated unit economics.

Getting there requires starting early enough for the change to be visible in the numbers, which in practice means the first year of the hold rather than the year before the process. Automation started late produces a story about what the next owner could do. Automation started early produces a track record.

For sponsors working through this across a portfolio, our private equity page covers how we approach diligence and post-close work. The scoping discipline that makes any individual deployment succeed is the same regardless of ownership structure, and it is covered in more depth in why most automation projects fail.