A 90-Day Rollout Plan for a Portfolio Company's First AI Workflow

Give the first AI workflow a 90-day decision window, a named company owner, and a bounded operating scope. Use the first month to establish the baseline and test the handoffs, then admit real work in stages. By day 90, management needs evidence to fund the next stage, change the design, or end the pilot, including the effort staff spend reviewing and supporting it.

Give the rollout a company-owned charter

The private equity sponsor can help select a value lever and fund specialist support, but the portfolio company's management must own the operating change. Name the executive accountable for the outcome, the process owner who accepts completed work, and the technical owner who maintains the system. Give someone explicit authority to pause it without waiting for the next board meeting.

Write a short charter for a single workflow. State its start and end, eligible cases, intended benefit, and exclusions. Define what the system can read, what it can propose, and who approves consequential actions. Add the pilot budget, decision dates, and the evidence required for wider use. Keep those terms available to the people running the queue.

Use the 90 days as a planning window, with progress conditional on evidence. Data access, vendor review, or a slow business cycle may prevent a meaningful trial within that period. Record that dependency early and change the decision date when necessary. Reaching a calendar milestone doesn't authorise the next stage.

A Reddit discussion about piloting AI delivery tools asks whether to start with a team or roll out broadly, and which measures justify expansion. It records practitioners' questions rather than verified performance evidence. Answer those questions in the charter before access spreads beyond the pilot group.

This plan starts after management has selected a candidate workflow; it can apply well after an acquisition. Our guide to the first 100 days of AI work after acquisition covers the earlier connection to the investment thesis. Here, the work is to put a specific process into controlled operation and make its release decisions inspectable.

Days 1–15: select the scope and establish readiness

Observe the workflow with the people who do it. Follow recent cases through the source records, decision points, and final acceptance. Include ordinary exceptions and work that falls outside the candidate scope. Establish where staff correct data or ask someone else for an interpretation; the formal process map may omit both.

For a concrete example, consider a distributor drafting orders from customer emails. The proposed assistant extracts order details and suggests catalogue matches. Staff still check contract terms and approve entry into the order system. Exclude credit decisions, price overrides, and release to fulfilment unless management separately authorises and tests those capabilities.

Measure the current method on comparable work. Record accepted orders, active handling time, waiting time, corrections, and errors by severity. Keep task identifiers so you can reconcile the measurements to actual work. Note missing records and changes in volume or staffing instead of reporting a precision the baseline cannot support.

Check access and source ownership before development depends on them. Identify the approved product catalogue, contract records, and customer identifiers, including their update path. Agree the data the workflow can send to each service and inspect the actual account configuration. A test using copied records doesn't prove that the production integration has the right permissions.

NIST's AI RMF 1.0 Core links knowledge of the operating context to an initial decision about whether an AI system should proceed. It is voluntary guidance, and NIST currently marks the framework as under revision. Use it to inform the review; the schedule here is our planning method, not a NIST-mandated sequence.

At day 15, the company owner reviews the scope, baseline, and readiness gaps. Continue only if the team has a credible test path and approved access for the next stage. Resolve a named blocker with an owner and date, or stop spending on the candidate. Don't let the team build around an unresolved business rule that governs acceptance.

Days 16–30: test the workflow before live use

Build the smallest end-to-end path that can test the proposed operating change. For the order assistant, that includes retrieving the approved records, preparing a draft, presenting evidence to the reviewer, and recording their decision. Keep production writes disabled during this stage. Review the full handoff rather than testing only the extraction response.

Create an evaluation set from approved cases with expected outcomes checked by subject-matter experts. Include ambiguous product descriptions, missing customer references, and records that require escalation. Keep a holdout set separate from cases the team uses to adjust the system. Re-run the relevant checks when the model, prompt, integration, or source rules change.

Test failure handling deliberately. Simulate a missing catalogue record, an unavailable upstream system, and a duplicate request. Check that the workflow avoids an unapproved action, exposes enough context for staff to continue, and preserves the task's state. If a timeout leaves an uncertain write outcome, the team needs a reconciliation step before retrying.

Shadow processing can compare the assistant's proposals with the existing method without using the proposals to act. Obtain the required permission for any production data in that test, and keep the current process in control. Log the cases the system cannot process. Those exclusions affect whether the proposed workflow covers enough work to justify operation.

Set acceptance criteria before reviewing the test results. Specify tolerable correction effort and the quality required for the agreed scope, with separate treatment for serious failures. Record the sample size and the cases it covers. Zero observed severe errors in a small sample doesn't establish that a rare failure cannot occur.

At day 30, review evidence of task quality, permission boundaries, and recovery with the process and technical owners. A successful demo doesn't close those checks. Authorise a supervised pilot only when its documented controls and staffing are ready. Otherwise, narrow the scope or set a specific repair and retest within the remaining budget.

Days 31–45: run a supervised production pilot

Admit a defined group of trained users and eligible cases. State the opening hours, volume cap, review requirement, and support contact. The order assistant still prepares proposals, while staff approve each order under the company's existing authority. Keep the excluded cases in the normal process and measure them so coverage stays visible.

Route access through explicit user and service permissions. Enforce data boundaries in the application and storage systems, and separate environments where the design requires it. A message asking the model to obey the policy cannot grant or restrict actual system authority. Review who can change the configuration and who can authorise a broader permission.

Set a reviewer capacity limit before the pilot opens. If review demand exceeds the agreed queue or staffing, send additional cases through the fallback. Don't accumulate an invisible backlog while reporting fast draft generation. Track elapsed time to an accepted order, including waiting for a reviewer and any correction.

Keep a clear record of why staff reject, repair, or bypass a proposal. Categorise recurring causes without turning each case into a lengthy reporting task. Feed those records into the weekly review, where the team decides which problem to fix. Preserve consequential examples under the company's approved access and retention rules.

Use a controlled comparison when the operation permits it. Compare similar cases handled under the existing method during the same period, noting supplier mix, staff experience, and workload. Avoid selecting only clean inputs for the assistant. If the comparison is observational, state the limits and don't attribute every change to AI.

At day 45, the company owner assesses the supervised evidence and operating burden. Retain the current boundary until the team closes its next-stage criteria. A serious breach needs incident handling and a pause under the charter, even if other measures improve. The sponsor's deadline doesn't replace the owner's release decision.

Train managers for the decisions they own

Managers need practice with the actual workflow before they supervise its use. Give them cases that show an acceptable proposal, an ambiguous input, and a failure that needs escalation. Ask them to identify the evidence for approval and demonstrate when they would use the fallback. Attendance at a presentation doesn't establish that capability.

Teach the boundary between a system suggestion and an authorised company action. A supervisor may manage the queue without authority to approve a price override. Explain who settles uncertain business rules, who handles technical faults, and who can pause access. Put those responsibilities into the working instructions and practise the handoff.

Microsoft's Copilot adoption guidance recommends a rollout team with executive sponsorship, security, governance, and an adoption champion, plus a focused initial cohort. Its context is Copilot, but the planning principle applies here: prepare the people and permissions before widening use. The company's product and workflow still need their own checks.

Protect time for practice and feedback in the manager's existing schedule. Replace an existing status discussion where possible, and make the pilot's support commitment explicit. Staff who assist their colleagues need a defined allocation and a backup. Relying on an enthusiastic volunteer for every exception creates an operating dependency.

Explain what management has decided about roles and what it has not yet decided. Don't promise job security or headcount savings that the company hasn't approved. Give staff a route to report wrong output and workload changes without having to prove the pilot is a success. Our guide to training managers to redesign work with AI develops that preparation.

Repeat the practical check when a new cohort joins or the system gains authority. A user trained to review a draft may need different instructions when the workflow writes to an operational system. Keep training tied to the version and scope they actually use, with the relevant owner approving the change.

Run a weekly review of completed work

Use a compact weekly pack with stable definitions. Show eligible cases, cases sent through the assistant, accepted outcomes, and cases that use the fallback. Put counts beside percentages. Explain missing coverage and case-mix changes so a small, easy week doesn't look like a broad improvement in capability.

Include active handling time, total elapsed time, and review or repair effort. Report severe errors and near misses separately from routine corrections. Show the open exception queue and support load. Adoption belongs in this pack, but the task outcome gives it meaning: repeated accepted work tells you more than login or prompt totals.

For an illustrative calculation, assume 300 comparable accepted orders each week. The old process takes eight active minutes per order, while the pilot takes five minutes including review and correction. That releases 900 minutes, or 15 hours, before additional operation. Four hours of weekly support reduce the net capacity gain to 11 hours.

These are invented figures, not a client result or a target. Include software and service charges in the cost comparison, and separate initial integration spend from ongoing operation. Call the hours capacity unless the company changes an actual paid workload or budget. Show how it plans to use that capacity and check whether the intended outcome follows.

End each weekly review with a decision and a named action. Keep the current boundary, approve the next limited group, repair a specified issue, or pause the workflow. Record the evidence, owner, and due date. A red measure without an assigned response leaves the team to improvise under the same conditions next week.

Control changes between reviews. Record the deployed version and material changes to source data or policy. Re-run relevant evaluation cases and check the effect on the production record. Preserve enough continuity to explain the result rather than comparing different versions and customer mixes as though the trial were unchanged.

Days 46–70: expand access within a defined boundary

Expand in a dimension the team can observe. You may add a second group handling the same case type, or increase volume for the existing group. Avoid changing users, case scope, and action authority together unless the review explicitly covers their combined effect. State what remains subject to the original approval requirement.

Inspect the next group's operation before copying the workflow. Another branch may use a different catalogue, contract process, or source-system configuration. Test those differences and establish a local process owner. A successful pilot in the first branch supports a defined claim about that branch; it doesn't establish readiness elsewhere.

Keep the fallback available throughout expansion. Verify that staff can return cases to the old method, that task status stays clear, and that the receiving system avoids duplicate actions. Practise recovery from an outage and check any work the system attempted before the pause. Reverting software alone may not undo a completed business action.

Watch review capacity and support as volume rises. An implementation engineer can solve early problems without establishing a sustainable support arrangement. Record recurring assistance by cause, and agree which work the company owns after handover. Expansion needs evidence that the agreed operating team can handle normal cases and exceptions.

NIST's AI RMF Core includes post-deployment monitoring, feedback, incident response, and responsibilities for deactivating systems that perform outside intended use. Apply those concerns to the actual workflow. Keep the pause authority and incident route active after the first successful week rather than treating the pilot approval as permanent.

At day 70, review whether the wider boundary still meets the agreed quality and operating conditions. Document new exceptions and limits on transfer to other sites. If evidence is incomplete, maintain the current scope or return to a narrower stage. A portfolio-wide replication plan needs each company's access, context, and local authority to support it.

Days 71–90: decide and complete the handover

Prepare a decision pack that the company's management can inspect without reconstructing the pilot. Include the charter, baseline, accepted-task results, failure record, and full operating cost. State which populations and business cycles the evidence covers. Show remaining assumptions in the forecast for the next stage and the cost of testing them.

Approve expansion only for a stated scope with funded operating responsibilities. Specify the next group, eligible work, review model, and monitoring cadence. Separate approval to add volume from approval to let the system act with fewer checks. Any change to authority needs evidence about that action and its consequences.

Revise when a named, testable change can address the gap. Give the revised pilot a budget and decision date rather than leaving it open indefinitely. Stop when the accepted outcome or delivery burden cannot support the business case within the available means. Close access and retained pilot data through the company's approved process when the pilot ends.

Complete a practical handover for any workflow that continues. Provide approved access, operating instructions, evaluation cases, monitoring, and a route to support. Have the receiving team demonstrate a normal run and an exception or recovery case. Record who maintains source records and who reviews a vendor or model change.

Management should leave the day-90 meeting with a specific funded scope or a recorded closure decision. Put the next operating review on its existing calendar and assign the outstanding work. The sponsor can then follow progress through accepted business outcomes and accountable company owners, with the evidence boundaries intact.