Do not begin by asking every company to submit an AI use case. Ask where important work loses time, context, accuracy, or commercial opportunity. Follow that work from its trigger to a completed outcome.

Meru’s experience spans more than 200 full-scale AI implementations. The practical lesson behind this guide is to treat AI as part of an operation: data, integrations, people, controls, and feedback must work together. A demonstration tests only a small part of that system.

Start with one company and one bounded workflow. The goal is not a small, disconnected automation; it is a complete implementation with a clear boundary and evidence about whether it works.

Write a one-sentence hypothesis: “If we improve this workflow, this operating measure should change, without breaching these quality and cost limits.” Record the baseline period, data source, owner, and comparison method.

Time released is capacity, not automatically a cost reduction. Revenue improvement requires evidence beyond usage. Finance should approve any claim about realized savings, margin, or EBITDA; do not count the same benefit twice.

The portfolio team sets the mandate, reporting definitions, and minimum controls. Company management owns the workflow, acceptance decision, staffing, and adoption. The implementation partner owns delivery within the agreed scope.

Name one business owner who can change the process, one technical owner for access and integration, and an escalation route for security, legal, and financial questions. “The AI team” is not a sufficient answer.

Keep company data boundaries intact. Share approved implementation patterns and aggregate reporting where authorized, not unrestricted access to another company’s records.

1. Observe the work. Review representative transactions, including failed and unusual ones. Map the systems and human handoffs.
2. Establish the demand. Confirm volume, frequency, cycle time, and where errors or delays become costly.
3. Check readiness. Verify data rights, usable records, system access, an accountable owner, and a route for exceptions.
4. Compare alternatives. Consider process repair, rules, existing software, and AI. Choose the least complicated approach that meets the need.
5. Set a bounded decision. Define what evidence permits a build, what must be repaired first, and what would stop the work.

Do not hide missing evidence inside a readiness score. Label it as unknown, assign someone to obtain it, and keep its consequence visible in the decision.

Full-scale does not mean an unbounded build. It means the selected workflow is carried through integration, production use, review, and ownership, not left as a proof of concept.

Activity is rising, but the operation is unchanged.

The program measures seats, prompts, or demos rather than completed business work.

What to do: Measure the whole workflow, including review and rework. Ask the owner what actually changed.

The pilot works only when its builder is present.

Knowledge, credentials, and exceptions depend on one person.

What to do: Require approved account control, a runbook, fallback, and an independent handover test.

The second company struggles with the first company’s solution.

Different records, permissions, operating definitions, and integrations were treated as identical.

What to do: Reuse the pattern; revalidate local inputs, decisions, controls, and acceptance tests.

The rollout is broad, but no manager owns adoption.

Training is being substituted for workflow change and accountability.

What to do: Assign the operating owner, embed use in real work, and inspect abandoned or overridden outputs.

For each implementation, report the business owner, stage, baseline and current measure, successful work volume, exception and rework rates, total operating cost, unresolved risks, and the decision required. Keep unknowns visible.

Use consistent definitions across companies, but retain local context. A metric is not comparable if one team excludes human review or reports a different unit of work.

Expand only after representative live use meets agreed quality, cost, adoption, and control requirements. Confirm support capacity and the next company’s readiness before approving replication.

These projects illustrate relevant operating patterns. They are not represented as private equity engagements, and their results should not be projected onto another company.

Before the next operating review, write down the workflow, the failure or bottleneck, its owner, the baseline source, the proposed change, known dependencies, quality limits, and the decision requested. Leave unsupported numbers out; show the evidence you still need.