An operating team may see the same pressures across several companies: inconsistent sales intake, slow reporting, fragmented knowledge, or work that depends on a handful of people. That does not mean every company needs the same AI system.

Meru works with the portfolio team to define the operating priority, then with company management to design, integrate, and support the implementation. Shared standards can reduce repeated work. Local ownership makes the system useful.

Our experience includes more than 200 full-scale AI implementations, not simply isolated task automations. The emphasis is on the operating system around the AI: integration, review, adoption, and continued improvement.

Scope is specific to the company. We do not promise that every workflow needs AI, that every company is ready, or that one technology stack should be imposed across the portfolio.

1. Understand the operation. Follow real work through the people, records, systems, and exceptions that carry it. Establish access and a credible baseline.
2. Define the priority. Choose a bounded workflow with a business owner, measurable demand, and a reason to change. Make a go, defer, or do-not-build recommendation.
3. Design the solution. Agree the integration, data boundaries, review points, test cases, costs, and acceptance criteria before delivery expands.
4. Implement the system. Build against actual operating conditions. Introduce controlled usage and test failures as carefully as the successful path.
5. Support and improve. Measure adoption and operational performance, maintain the controls, and decide whether to deepen or replicate the work.

Meru coordinates the technical detail. Management remains responsible for business policy, people, approvals, and the decisions that the system supports. Scope changes and dependencies are made explicit rather than absorbed into an unclear promise.

Before sensitive access, establish permissions, retention, approved vendors, human review, and any required DPA or BAA. Client account control, ownership or licensing of deliverables, export rights, and the support arrangement must be written into the agreement.

Portfolio visibility does not justify pooling company data. Keep company access and reporting boundaries explicit, with only approved information moving into portfolio-level oversight.

A good starting point has a named owner, recurring operating demand, usable source records, and management willing to change the surrounding process. A polished AI brief is not required.

• There is a concrete bottleneck in revenue operations, delivery, reporting, or client experience.
• The company can provide authorized system access and time from the people who perform the work.
• Someone can approve workflow changes and accept the result against agreed tests.
• The team can distinguish released capacity from cash savings, and measure both honestly.

When we would pause

No process owner, unresolved data rights, contradictory records, or no practical route into the core system are reasons to repair the conditions first. A rules-based change or existing product feature may solve the problem more simply than AI.

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