Why the 100-day plan needs an AI layer now
The 100-day plan is the one document every platform company gets on day one of the hold. Diligence findings become workstreams. Workstreams get owners. Owners get a board slide at the first quarterly review. It is the fastest-moving document in the deal, and until recently it had nothing to say about AI beyond a bullet point.
That bullet point is no longer optional. 98% of sponsors have told portfolio CFOs to prioritize AI, and the mandate now arrives inside the first 100 days rather than at year two. But the mandate and the capability are two different things. Only 36% of PE-backed portfolio companies use AI in day-to-day operations and just 7% call it fully integrated across the portfolio. Board expectations moved first. The operating layer has not caught up.
The industry-wide track record explains why boards are right to ask for a plan rather than a pilot. MIT NANDA research, as reported by Fortune, found that 95% of enterprise generative-AI pilots produce no measurable P&L impact. A pilot with no plan behind it is a coin flip against a bad base rate. A 100-day plan with a named owner, a baseline number and a shipped system is how a portfolio company gets on the right side of that statistic instead of adding to it.
This is also a hold-period argument, not just an operating one. The plan has to produce evidence a buyer will read at exit, not a slide the current board forgets by the next quarterly review.
The anatomy of an AI line in the value-creation plan
Most AI lines in a VCP fail the same test: they read like a workstream list, not a commitment. A defensible line item has exactly four parts.
- One function. Not "AI across the company." Finance close, claims processing, inside sales, field service scheduling: pick one function the first quarter, not five.
- One owner. A named person inside the function, not a steering committee, not the CIO by default, with the mandate written into their goals.
- One number. A baseline that exists before the system ships, expressed in the unit the CFO already uses: hours, dollars, cycle time or basis points of EBITDA.
- One system. A single thing that reaches production with a maintainer, not a portfolio of pilots that never leave the sandbox.
If a candidate line item cannot answer all four in one sentence, it is not ready for the investment committee. It is a hope, and hopes do not survive a board that has seen the 36% and 7% figures.
The one-function rule
Running five pilots at once feels like progress and produces none. Every function that gets touched adds a data owner, a change-management conversation and a training burden. A portfolio company with one function fully shipped in 100 days has more to show a board, and a buyer, than one with five functions half-started. Sequence, do not parallelize.
Day 0 to 30: diagnose, name the owner, baseline the number
The first 30 days are not for building anything. They are for making the four decisions above correctly, because a wrong pick here costs the rest of the 100 days.
Run the diagnostic
Walk every candidate function and score it against an impact-against-ease matrix. Impact is the dollar value at stake if the recoverable cost is real. Ease is whether the data is clean, the function head is willing and the system of record is stable rather than mid-migration. Plot every function on the grid and pick the one that is high on both axes, not the one with the largest theoretical number attached to it.
Name the adoption owner
One person, inside the function, before any system design starts. The owner is not a steering-committee seat. It is a name in the function head's org chart with protected time and a line in their goals. If nobody in the function will take the job, that is the diagnostic result: the function is not ready, and the plan should say so rather than proceed anyway.
Baseline the number
Measure the current state before anything changes: cycle time, error rate, hours per ticket, cost per unit, whatever the function's own operating review already tracks. A system that ships without a baseline cannot prove anything happened, however well it works.
Write the do-not-automate list
Alongside the target function, write down what will not be touched this quarter: anything reaching a protected-class employment decision, anything a regulator reads, anything where a wrong answer is expensive and unrecoverable. This list is not a delay tactic. It ends the argument that would otherwise consume week three, and it is evidence a buyer's counsel will want to see at exit.
Day 31 to 60: ship into the real system, not a demo
The second 30-day block is where most portfolio company AI programs quietly die, because this is where a demo has to become a system with real users and real data.
Build into the system of record
The system has to live where the function already works, not in a side tab nobody opens. If the function runs on the CRM, the ERP module or the claims platform, the AI layer sits inside that system or is deeply integrated with it. A tool that requires switching windows loses the adoption fight before it starts.
Use real data from day one
Synthetic or sampled data produces a demo that impresses a steering committee and fails on the first real ticket. Connect the system to production data, with the access and retention controls the governance plan already specified, and accept that the first two weeks will surface data-quality problems the diagnostic did not catch.
Train three to five people, not the whole function
A narrow, high-touch rollout to three to five people who work with the adoption owner beats a company-wide training day. These early users find the edge cases, become internal references and give the owner a working answer to "does this actually work" before the wider rollout in the next block.
Publish the weekly usage number
Starting the week the system goes live, publish one number every week: weekly active users over eligible users in the pilot group. Not licenses issued. Not logins ever. A number the function head sees in the same place they already look for other operating metrics.
Day 61 to 100: scale, report and package
The final block turns a working pilot inside one team into a function-wide system with board-ready evidence.
Scale inside the function
Extend from the initial three to five users to the full function, using the early users as internal trainers. Do not extend to a second function yet. A function fully adopted is worth more, and is more defensible in front of a board, than two functions half-adopted.
Report in the CFO's number
By day 90, the board report should carry the same unit the rest of the value-creation plan uses: dollars, basis points of EBITDA or whatever the CFO already reports on. Baseline, current, target, adoption rate, what shipped, what is next.
Package the playbook
Write down what worked, what the vendor or build actually cost, how long each step took and what the second portfolio company should skip. A single deployment is a project. A packaged one is an asset the fund can redeploy at declining cost across the rest of the portfolio.
| Phase | Primary output | Owner accountable |
|---|---|---|
| Day 0 to 30 | Function selected, adoption owner named, baseline number set, do-not-automate list written | AI operating partner and function head |
| Day 31 to 60 | System live in the real system of record on real data; 3 to 5 users trained; weekly usage number published | Adoption owner |
| Day 61 to 100 | Full function adopted; board report in the CFO's number; playbook packaged for the next portfolio company | Adoption owner and CFO |
A worked example (illustrative)
The numbers below are illustrative, built to show the formula, not a claim about any specific company. Every real engagement replaces them with the diagnostic's measured figures.
Take an $80M-revenue services portfolio company with a 40-person function identified as the target: say, claims processing or client onboarding. Loaded cost per person in that function runs about $95,000 a year, which is headcount times fully loaded compensation, not just base salary.
Assume the diagnostic finds that 20% of the function's work is recoverable: the share of time spent on tasks the system can plausibly take over without degrading quality. Assume 70% adoption at the 100-day mark, which is a realistic, not aspirational, target for a well-run rollout.
The formula
Annual recoverable value = function headcount × loaded cost per head × recoverable percentage × adoption rate.
40 × $95,000 × 20% × 70% = $532,000 a year.
As basis points of revenue: ($532,000 ÷ $80,000,000) × 10,000 = about 66 basis points.
Sixty-six basis points on an $80M revenue base is not a rounding error to a board that has watched only 9% of operating partners report a demonstrable AI premium in a completed transaction. It is also a number the CFO can defend line by line, because every input traces back to a diagnostic measurement rather than a vendor's projected ROI.
The six failure modes as the risk register
Every 100-day plan needs a risk register. For the AI line, the register is the same six failure modes the Pilot-to-P&L Scorecard scores. Run the score on the target function before day 1, and again at day 100, to show the board the delta.
| Failure mode | Risk to the 100-day plan | Mitigation inside the plan |
|---|---|---|
| The License Trap | Budget spent on seats nobody uses; adoption number never moves | No license purchase before the adoption owner and baseline exist |
| The Strategy Shelf | Day 0 to 30 produces a deck instead of a decision | Diagnostic ends with a named function and owner, not a roadmap document |
| The Demo Graveyard | Day 31 to 60 ships a prototype on sample data that never reaches production | Build inside the real system of record on real data from day one of that block |
| The Workshop Certificate | Training measured in attendance instead of usage | Weekly active users over eligible users is the only training metric that counts |
| Vendor Lock-in | The system cannot be extended, exported or repriced at renewal | Build-versus-buy decided with an exit clause before signature, reviewed by the AI operating partner |
| No Adoption Owner | Every other mitigation collapses without someone accountable inside the function | Named on day 1, not day 90; the mandate is written into the owner's goals |
Full definitions, tells and fixes for each mode: six ways portfolio AI stalls before the P&L.
The one-page plan template
One page, one function, filled in before the first investment committee meeting on the topic. Every row needs a name in the owner column, not a department.
| Workstream | Owner | KPI | Baseline | Day 30 target | Day 60 target | Day 100 target |
|---|---|---|---|---|---|---|
| Function diagnostic and owner selection | AI operating partner | Function selected, owner named | None | Complete | — | — |
| Baseline measurement | Adoption owner | Cycle time or cost per unit | Measured day 30 | Set | 10% improvement | Target improvement hit |
| System build and integration | AI operating partner and IT lead | System live in production | Not built | In build | Live, real data | Fully deployed |
| Adoption and training | Adoption owner | Weekly active users / eligible users | 0% | — | 40% (3 to 5 users) | 70%+ (full function) |
| Governance and do-not-automate list | AI operating partner and compliance lead | List published; audit trail live | None | Published | In effect | Reviewed at day 100 |
| Board reporting | CFO and AI operating partner | Monthly slide in CFO's units | None | Format agreed | First report | Third report, trend visible |
What the board slide should contain
One slide, every month, same format. Baseline, current and target for the one number the CFO recognizes. Adoption rate by function, as weekly active users over eligible users. What shipped this month. What ships next. What is blocked, and who owns unblocking it. Nothing else belongs on the slide: no tool logos, no roadmap graphics, no aggregate list of pilots in flight. A board that has read the 36% and 7% figures is not persuaded by activity. It is persuaded by a number that moved.