How PE operating partners should start AI across a portfolio: a 90-day playbook

Start with three portfolio companies, one workflow at each. Write down how that workflow performs today and the 90-day result that would end the project. Have the company's best people write the tests before anyone builds. Then prove it in one company and copy what worked to the next.

That's the short version. It's written for an operating team that's small next to the portfolio, say six people across 30 companies, and the rest of this post is the practical detail: what to ask, what to count, who owns what, and what to hand a buyer at exit.

It's also where most funds are right now. In May, Accordion and Wakefield Research surveyed 150 operating partners who run AI, data and technology at PE sponsors. The largest group, 41%, is deploying AI across several portfolio companies without an operational playbook. Only 38% measure revenue or margin impact.

What to ask each portfolio company CEO

Skip the survey. Ask each CEO to walk you through one customer request from start to finish: how it comes in, who touches it, which systems it passes through, where it waits, and when the customer gets an answer. A walkthrough shows you the handoffs and the waiting, and those are the places a first AI workflow can help.

During the walkthrough, get answers to five questions:

1. Is AI in the budget, or only in the board deck? A line item with a number on it means someone has already argued for it.
2. Is there a tech team, or only vendors and spreadsheets? This decides who looks after the work once your team moves on.
3. Does anyone track cycle time, rework or cost per case? If nobody does, you'll build the baseline yourself before you can prove anything.
4. Could they pull last month's cases out of their systems in a day? This is the data question in a form a CEO can answer. Accordion's respondents ranked poor data foundation first among the barriers to adoption.
5. Who would build something overnight if you handed them a coding agent? Get the names. Those people are your best candidates to own the workflow inside the company.

How to check what the CEOs tell you

Check the answers against the usage logs. Most office suites and AI tools a company already pays for have an admin view of who used them and how often. If the CEO says the team is ready and the logs show the same four people every week, find out why before you choose that company. It might be training, or the tools might not fit the work. Either way, you learn it in a week instead of in month two of a project.

Then sort the portfolio. Some companies are ready for a workflow project now. Some need a data project first, because their cases can't come out of the systems in a day. With six people, most of the portfolio waits a quarter. Tell those CEOs what they'd need in place to be next, so the wait gives them something to work on.

How to choose the first three workflows

Three at once is what six people can run properly, two per company. One person can own the build while the other owns the measurement and the people doing the work.

A good first workflow has four things:

• A bottleneck the customer feels, like slow quotes, slow onboarding, billing errors or missed dispatch windows.
• Data you can reach. The cases live in a system you can export from.
• One owner, a single person at the company who'll answer for the result.
• A line on the P&L, so a faster workflow points at revenue or cost you can name.

Support, onboarding, billing and dispatch are good places to look. The work repeats, there's usually a record of every case, and a delay shows up in what the customer gets. Leave internal reporting for later. It's easy to automate and hard to tie to a number on the P&L.

Set the baseline: four numbers

Before anyone builds, measure the current process for a few weeks and write down four numbers:

1. Work finished per week, in whatever unit the workflow produces: tickets closed, orders shipped, invoices sent.
2. Time per case, including the waiting. Clock it from start to finish, because that's what the customer experiences.
3. How much gets sent back, meaning the share of cases that need a second pass, a correction or a follow-up with the customer.
4. Cost per case. Labor plus the tools and vendors the workflow uses, divided by cases finished.

Write each one down with the date and how you counted it. Once the project starts, people will want to count differently, and an agreed method ends that argument before it starts.

Pick the 90-day kill number

Then write down the 90-day result that would end the project. Pick one of the four numbers and a level for it. If time per case hasn't come down to that level by day 90, the project stops and the team moves on to the next company.

This number is easiest to agree before anyone has built anything. By day 90 the people who did the work will want more time, and they'll have good reasons. Write it down in week one and have the CEO sign off on it.

A kill number also protects the other 27 companies. A project that's stuck and keeps getting funded uses up the time your team was going to spend on them.

Write expert test cases before anyone builds

Ask the company's best people, the ones others go to with hard cases, to write out what a correct result looks like on real cases. Pull a few dozen from last month, including the messy ones. For each case, the expert writes down:

• what came in
• what a correct result looks like
• what the system should never do with it
• when it should stop and hand the case to a person

Write as many handoff cases as normal ones. They're how you find out whether the system knows its limits.

These become the first tests. Every version of the workflow runs against them before it goes near a customer, and the score goes in the weekly update. They're also the fairest way to judge the work, because the experts wrote them before anyone had something to defend.

Split ownership between the fund and the company

The fund owns priorities, vendor terms, spending limits and the playbook. Those get better when they're shared across the portfolio, like a vendor contract negotiated once for every company.

The company owns the workflow, the budget line and one named owner. If the budget line sits with the fund, the project ends when the fund's attention moves somewhere else.

Inside the workflow, split the work the same way. AI reads, gathers context and proposes the next step. People approve and handle the cases that need experience. That split is easy to explain to the team doing the work, and it keeps a person responsible for every result that reaches a customer.

Before buying anything, check what the company already pays for. A lot of AI requests are covered by features in existing software that nobody turned on.

Put the limits in code

Permissions, approvals and spending caps belong in the system. A policy document on its own won't stop an agent at 2 a.m. In practice that means:

• The agent's account can read and draft. Only a person's account can send, refund or change a customer record.
• Each workflow has its own API key, with a monthly spending cap and an alert set well below it.
• Anything above a set dollar amount, or outside the usual pattern, goes to a person for approval.

Keep the prompts, tests and integrations in accounts the company owns. That way they can be copied to the next company, and they're still there after the people who built them have moved on.

Measure rework and the AI bill

Run the old process and the new one on the same cases for a few weeks. Then hand the new one to a small group and keep tracking the four numbers.

Add two more. The first is the AI bill for the workflow: model usage, tools and hosting, divided by cases finished. The second is rework, the hours people spend fixing what the agent got wrong. Have reviewers log it as they go. It's tedious, and without it the cost per case looks better than it is.

Watch output and rework together. If both go up, the bottleneck moved to review. The team is producing more drafts and spending the time it saved on checking them.

Every miss becomes a new test case. A named person inside the company owns the workflow, with written steps for changes, incidents and rollback: who can change a prompt, who gets called when something breaks, and how to switch back to the old process the same day.

Once the first company has held its result, take the playbook, the test format and the limits to the next one. The second company still writes its own expert tests on its own cases.

Build the exit file for buyer diligence

The first company should leave a playbook, a result that shows up in EBITDA and people who can run it without outside help. It should also leave the evidence that the result is real.

Accordion found that 86% of operating partners expect buyers to pay a premium for AI-enabled finance capability within two years. A buyer's diligence team will ask for proof, and the proof is easiest to collect while the work is happening.

Keep one folder per workflow with:

• the baseline and how it was counted
• the 90-day kill number and the date it was agreed
• the before and after on the same cases
• the AI bill and rework hours by month
• the test cases and their scores over time
• the runbook and the name of the owner

The same folder covers the board and LP update. Accordion found only 29% of operating partners include AI impact in that reporting today.

If you'd like a second opinion on which three companies to start with, talk to the team. Bring your notes from the CEO walkthroughs and last month's case counts.