1.1 Purpose of this document

This document is the methodology reference that backs how Anneal works with portfolio companies to drive growth and value. It is for internal use by anyone applying the SCALER system on an investment — partners running deal teams, operating partners working alongside portco management, analysts running diagnostics, and new hires being onboarded into how we work.

It is not a deck. The v8 presentation deck explains what we do externally — to LPs, to management teams, to advisers. This document explains how we do it: the diagnostic stance we take, the cadence we run, the tooling we deploy, the artefacts we produce, the language we use, and the failure modes we engineer against.

Read this document end-to-end once. After that, treat it as a reference. The appendices are designed for repeated dipping in — checklists, KPI libraries, diagnostic question banks. The body of the document is designed to teach the model and our point of view.

1.2 Anneal’s transformation thesis

The thesis is one sentence: growth in mid-market businesses is constrained, and the constraints are removable. Everything that follows in this document is a working out of that sentence.

Three positions follow.

The largest opportunity is growth, not efficiency. Most of the value we create comes from removing barriers to growth — strategic, capability, and execution barriers — rather than from cost reduction. Productivity improvements emerge as a consequence of better growth, not as the goal. We are not a cost-out firm.

Transformation works only when strategy, capability, and execution move together. Most transformation programmes address one of these or, at most, two. A strategy without capability is a deck. Capability without strategy is overhead. Execution without either is busywork. SCALER is engineered to address all three together, in a defined sequence, in real businesses.

The work of transformation is the work of removing constraints. We do not add programmes to a business; we identify what holds growth back and dismantle it. That is sometimes a strategic choice, sometimes a capability gap, sometimes an execution problem. The portfolio company runs the business; we work alongside management as partners in the same outcome. We do not produce reports; we install systems and capabilities the business owns.

This is not consulting. We do not have engagements; we have investments. We do not have deliverables; we have outcomes. The success measure is not “we finished”; it is “the business is materially more capable than when we started, and the results show it.”

1.3 What we believe about transformation

Ten beliefs that govern everything in this document. Disagree with these and you will disagree with most of what follows.

1. Growth, not efficiency, is the prize. Cost-out is the lever of last resort, not first. Most cost-out is a sign of a missing strategy.
2. You cannot transform what you cannot see. Workshops and interviews systematically lie. Real workflow data — what people actually do — is the foundation of every credible transformation programme.
3. Strategy without capability is theatre. A growth plan the organisation cannot deliver is worse than no plan, because it absorbs management attention while producing nothing.
4. Pilots are not strategy. A transformation programme made of pilots is a transformation that has not started. Scale is the test.
5. Tools serve workflow, not the other way around. AI deployed onto a broken process produces a faster broken process.
6. Orchestration is the unsung lever. The right work, going to the right resource, at the right time, is worth more than any individual tool.
7. Management runs the business; we work with management. We do not replace, override, or compete with the management team. Where management is missing, we fix that first.
8. Cadence beats intensity. A weekly drumbeat at fifty per cent intensity beats a quarterly off-site at one hundred.
9. Trust is the substrate. Observational data, AI deployment, and orchestration only work in a trust environment. Build that environment deliberately.
10. Repeatability is the multiplier. Every investment must teach the next. Anything we do that does not generalise is, by default, a tax on the next portco.

1.4 Why most transformations fail

We engineer against six recurring failure modes. Naming them honestly is more important than memorising the model — because the model is just a means of avoiding them.

Failure mode 1 — Visibility over value. Teams pick the most visible processes (typically the loud ones, the recently-broken ones, or the ones with charismatic owners) rather than the most valuable. The result: a lot of activity, no movement on the things that determine the company’s trajectory.

Failure mode 2 — Workshop-led diagnosis. The organisation describes how work is supposed to happen, in a room. The methodology then attempts to fix those described processes. The actual work, which looks nothing like the description, continues unchanged. Process intelligence — observational data — exists precisely because every organisation lies about its own workflows, and not always knowingly.

Failure mode 3 — POC theatre. Pilots prove that something can work. Scale proves that it does work, in this organisation, repeatedly, without heroes. Programmes that consist of seven pilots and zero scale-ups are a category of failure we recognise on sight.

Failure mode 4 — Tool-first thinking. Buying an AI platform, an RPA suite, or a CRM is not a transformation. Tools serve a workflow; if the workflow is wrong, the tool amplifies the wrongness. SCALER puts Analyse and Lead before Execute for this reason.

Failure mode 5 — Capability gap denial. The organisation is assumed to be able to deliver the strategy. It often cannot. Honest capability assessment, followed by deliberate building, is the most consistently underpriced part of transformation work.

Failure mode 6 — One-off thinking. Each portfolio company is treated as a custom build, with no learning re-used, no toolkit re-deployed, no cadence imported. Anneal exists in part because mid-market private equity has been chronically bad at this; we treat it as a first-class problem.

1.5 How SCALER fits the deal lifecycle

SCALER is a continuous loop, but its emphasis shifts predictably across the hold period. Knowing where you are in the lifecycle tells you which stages of the model deserve the most attention right now.

A common error is to apply the early-stage emphasis (Strategic Alignment, Capability) too late, or to start scaling (Repeat) too early. The framework is sequenced; the lifecycle is sequenced; they should match.

2.1 Overview

SCALER is six stages, sequenced for the first cycle and then run as a continuous loop. The first five letters describe the work of unlocking growth in a single business; the sixth describes how the unlock travels to the rest of the portfolio.

Two structural points before we go stage-by-stage.

The order matters, even though the work is parallel. We do not finish one stage before starting the next. Strategic Alignment kicks off pre-deal and is refined in the first 100 days; Capability assessment overlaps with Strategic Alignment; Analyse can begin within weeks of close. But the primary intent of the work moves through the stages in order, and skipping ahead is a recognisable form of failure.

The model is recursive. Each stage applies SCALER to itself. To build Capability, we identify the strategic capability gaps (S), assess the capability of our capability function (C), analyse how capability decisions actually get made (A), structure how they will be made (L), execute the build (E), and create reusable capability assets (R). The pattern repeats.

The next six sections follow a consistent format: Purpose, What good looks like, Inputs, Activities, Outputs, Common failure modes, Connection to AI.

2.2 S — Strategic Alignment

Purpose. Force the business to choose where it wants to win. Most underperforming mid-market businesses have not made the choice — they are doing too many things, in too many segments, for too many customers, and the result is an organisation that is busy, tired, and stalled.

What good looks like. A clear, contestable, written answer to two questions: (1) where does growth live in this business — which customers, which segments, which products, which geographies, in what sequence? and (2) what are we deliberately not doing, and why? The second question is the harder one and the more important one.

Inputs.

• Investment thesis from the deal
• Customer cohort and segment data — revenue, growth, margin, churn, CAC, LTV by cut
• Product / service-line P&L
• Sales pipeline by segment and stage
• Competitive landscape and white-space view
• Management team’s own view, treated as one input among several, not the answer

Activities.

• Segment economics deep-dive: where is gross profit actually being made, and where is the marginal investment going?
• Win-loss analysis on the last 24 months of pipeline
• Customer retention and expansion analysis at cohort level
• Strategy off-site with the management team to make the choice. The off-site exists to make the choice, not to discuss it. Choices that do not get made on the day rarely get made later.
• Stop list: an explicit list of activities, segments, customers, and products the business will stop doing. The stop list is treated with the same seriousness as the start list.
• Reallocation map: capital, people, sales effort, and management attention re-flowed to the chosen priorities.

Outputs.

• One-page strategic priority statement (the company’s, signed off by the CEO)
• Sector / segment / product priority ranking with rationale
• Stop list with named owners and deadlines
• Reallocation map (resources, people, attention)
• Hypothesis register — what we believe about the chosen priorities, and what evidence will confirm or refute each

Common failure modes.

• Picking too many priorities. If everything is a priority, nothing is.
• Not making the stop list real. A stop list with no owner and no deadline is not a stop list.
• Treating Strategic Alignment as a one-off off-site rather than a re-running discipline.
• Allowing the management team’s existing comfort to drive the priorities, rather than the data.

Connection to AI. AI’s role in Strategic Alignment is small, by design — strategy is judgement, not computation. But AI helps in three specific places: accelerating segment economic analysis from raw data, running win-loss pattern detection across hundreds of deals, and competitive landscape synthesis. Treat these as inputs to judgement, not substitutes for it.

Platform AI note. For some portcos, Strategic Alignment includes a more fundamental choice — whether to remain a service or product business with operational AI inside it, or to build a data-platform capability that repositions the business model itself. This is a strategic choice, not a technical one, with material implications for capital allocation, capability build, and time-to-value. Where the pre-conditions are present (recurring client relationships, accumulating data exhaust, sufficient capital for an 18–24 month build, management appetite for the ride), this can be among the highest-leverage strategic moves available. See Part 4.6 and Pattern 4 in Part 6.

2.3 C — Capability

v4 — pattern-specific capability shape. For Experience AI, the capability gap is rarely engineering — it is product, design, evaluation, and behaviour engineering. Weight product and design more heavily in the Buy-Build-Blend Worksheet; treat evaluation engineering as a specific named role. For Decision AI, the capability gap is rarely data engineering — it is decision science and business ownership. The build sequence anchors on the decision owner; the function head’s capability to use the model is on the critical path.

Purpose. Honestly assess whether the organisation can deliver the chosen strategy, and where it cannot, build the capability deliberately. This is the most chronically underpriced stage in transformation programmes; we treat it as the second-most important stage in the model.

What good looks like. A clear-eyed map of the capability gap between the strategy and the organisation, an actionable plan to close the gap, and named owners for each part of the plan. Capability is not an aspiration; it is a build job.

Inputs.

• Strategic priority statement from Strategic Alignment
• Org chart, comp data, span-of-control analysis
• Performance management data — who is delivering, who is not, who is mis-roled
• Talent pipeline, hiring plan, retention risk register
• System and tooling inventory
• Cultural diagnostic — typically a short, structured set of interviews and observations rather than a survey

Activities.

• Capability stack review across the four dimensions we always look at: People, Process, Technology, Culture
• Top-team assessment: is the management team the right team for the next two years? Common honest answers: yes; yes with two specific gaps; mostly, but with one critical replacement; no, and we need to change the CEO. The honest answer is named.
• Skills gap mapping against the strategy
• Tooling and systems audit, with a deliberate eye on data foundations (without which AI capability is impossible)
• Culture diagnosis — how decisions actually get made, how disagreement is handled, whether the company is execution-paced or meeting-paced
• Activation plan: targeted hiring, upskilling, tooling investments, leadership strengthening, cultural moves

Outputs.

• Capability gap register, ranked by criticality to the strategy
• Org change plan, including any management-team changes with sequencing
• Hiring plan with named priority roles and search timelines
• Tooling investment plan, with explicit data-foundation work called out
• Leadership coaching / strengthening plan where applicable
• Culture moves — concrete behaviours to start, stop, and continue, owned by the CEO

Common failure modes.

• Assuming capability exists because nobody has said it does not.
• Avoiding the management-team conversation. Where the team is wrong for the strategy, naming this early is the single highest-leverage decision in the hold.
• Confusing “we trained them” with “they are now capable.” Capability requires application and reinforcement.
• Treating data foundations as IT housekeeping. Without clean operational data, neither AI nor process intelligence will deliver value.

Connection to AI. AI capability sits inside this stage, deliberately. Building AI capability is a capability build like any other — it requires people who can scope, govern, deploy, and maintain AI systems; it requires data foundations; it requires leadership sponsorship; it requires governance. Most portco AI failures are capability failures dressed up as technology failures.

Platform AI note. Building Platform AI capability requires roles distinct from Workflow AI — data engineering, ML engineering, MLOps, instrumentation / IoT, product management, sometimes hardware engineering. The instinct to retrain existing engineers and analysts as data scientists is usually wrong; the gap is too large to bridge through training in any reasonable time. Hire what is needed; pair the new hires deliberately with domain experts who understand what the data is showing; and build the capability as a stand-alone function with a clear leader and a clear roadmap.

2.4 A — Analyse (Process Intelligence)

v4 — pattern-specific diagnostic. For Experience AI, the diagnostic is customer journey mapping plus voice-of-customer evidence at the interaction level — conversation logs, support tickets, NPS verbatim, in-product behaviour, qualitative customer interviews — not process intelligence on internal workflows. For Decision AI, the diagnostic is a decision audit: list the high-volume recurring decisions, score them on volume, value, current quality, data availability, and willingness-to-act. The Top-Team AI Readiness Diagnostic gets a Decision AI variant in v4.

Purpose. Replace assumption and interview-derived narrative with observed reality. This is the diagnostic spine of SCALER and the most distinctive stage of our methodology.

What good looks like. A complete, evidence-grounded picture of how value-relevant work actually happens in the business — at task level, in real time, without reliance on what people said in workshops.

Inputs.

• Strategic priority statement (so we know what to look at)
• Capability gap register (so we know what we already understand)
• Live workflow data captured via process intelligence tooling (KYP.ai or equivalent)
• Operational and financial data via APIs into key systems (CRM, ERP, ticketing, comms, finance)
• Pre-existing process documentation — read with appropriate scepticism

Activities.

• Deploy process intelligence tooling on selected end-user populations, with explicit governance on scope, retention, and anonymisation
• Capture live activity at task level for a representative period (typically 4–8 weeks)
• Layer AI-driven workflow analytics: identify bottlenecks, hidden manual work, rework, system-switching cost, time-of-day patterns
• Cross-reference observed workflows against documented processes to surface the gap
• Identify the value-relevant constraints — the bottlenecks that, if removed, unlock the largest movement in the priority KPIs
• Run a small number of focused interviews to understand context, never to substitute for the data

Outputs.

• Observed workflow map for each priority area, at task level
• Constraint register: ranked list of bottlenecks, hidden manual work, rework, and inefficiency, each tied to a value-relevant KPI
• Process intelligence baseline that future improvements measure against
• Initial AI use-case longlist generated from the data — where can AI actually help?
• Anonymised, aggregated dashboards for management consumption

Common failure modes.

• Boiling the ocean. Capture everything, analyse nothing. Fix this by scoping process intelligence tightly to the priority areas from Strategic Alignment.
• Treating the data extraction as the deliverable. The data is the input; the constraint register is the deliverable.
• Letting the data linger. If process intelligence runs for ten weeks and produces no constraints to act on, the methodology has failed.
• Surfacing the data without the trust framework. Process intelligence without explicit transparency to the workforce destroys the operating environment it was meant to improve.

Connection to AI. AI is foundational to this stage. Manual analysis of process intelligence data does not scale; we use AI for pattern detection across millions of task-level events, anomaly identification, and natural-language description of observed workflows. AI also generates the longlist of AI use-cases for the next stages — we do not generate this list in a workshop.

Platform AI note. For Workflow AI, Analyse is typically a 4–8 week study with process intelligence tooling on knowledge workers — bounded, time-limited, scoped to a transformation question. For Platform AI, Analyse is a permanent infrastructure layer — sensors, IoT, telemetry, image capture, log ingestion — that runs continuously and accumulates data over years. The shift from study to infrastructure is fundamental to the pattern. Plan, fund, and govern it as such.

Infrastructure AI note. Process intelligence is itself a form of Infrastructure AI (see §5.0). When deployed across multiple workflows in a single portco, or — at the firm level — across multiple portcos, it is a substrate investment that compounds: the same data, observability, and analytical capability serves many use cases simultaneously. Once portfolio-level pattern detection comes online, process intelligence is no longer a study but a permanent firm capability. Treat its scope, retention, and anonymisation discipline as governance questions from day one, not as deployment questions.

2.5 L — Lead (Orchestration)

v4 — pattern-specific leadership. For Experience AI, the leader sits at the intersection of product, customer success, and AI engineering. The wrong shape (an AI engineering lead without product instinct) builds technically correct features customers do not adopt. For Decision AI, the leader is the function head whose decisions are being augmented (pricing director, credit officer, head of service planning), supported by a decision scientist — not the other way around. The model is in service of the function, not the function in service of the model.

Purpose. Structure execution so that the right work goes to the right resource — human or system or AI — at the right time, repeatably and at scale. Orchestration is the single most underpriced lever in mid-market transformation; without it, execution is a series of well-intended improvisations.

What good looks like. A defined operating model in which workflows are explicit, ownership is clear, handoffs are instrumented, and the mix of human, system, and AI execution is deliberately designed and continuously optimised.

Inputs.

• Constraint register from Analyse
• Strategic priority areas (so orchestration is built where it matters)
• Existing operating model documentation
• AI use-case longlist from Analyse
• Tooling stack inventory

Activities.

• Workflow design: break the priority workflows into discrete tasks, with defined inputs, outputs, ownership, and SLAs
• Allocate each task across human, system, and AI execution. Three questions: who owns this, who actually does it, and how is it done?
• Deploy orchestration platform (Enate or equivalent) for the priority workflows. Orchestration is not optional; it is the substrate on which AI deploys safely.
• Define the governance model for each orchestrated workflow: change control, exception handling, escalation, SLAs
• Wire in monitoring and instrumentation. Orchestrated work generates its own management dashboard.

Outputs.

• Target operating model for each priority area, at task level
• Orchestration deployment with workflows live in production
• Live monitoring dashboards by workflow
• Exception and escalation playbooks
• AI deployment plan integrated into orchestration, not bolted on top

Common failure modes.

• Designing orchestration around the existing org chart rather than the work. The org chart is an output of the workflow design, not a constraint on it.
• Skipping orchestration and going straight to AI deployment. The result is fragile, hero-dependent AI that does not survive contact with the operations team.
• Building orchestration on top of broken processes. Always re-design the workflow first.
• Treating orchestration as an IT project rather than an operating-model change. Operations must own it.

Connection to AI. Orchestration is where AI moves from pilot to scale. AI tasks live inside orchestrated workflows alongside human tasks and system tasks; the orchestration layer is what makes AI deployments controllable, recoverable, observable, and auditable. We do not deploy AI outside orchestration except in the most contained, low-stakes use cases.

Platform AI note. Orchestration in Platform AI extends beyond workflow orchestration to include data orchestration — real-time ingestion pipelines, feature engineering, model serving infrastructure, and ML operations (model monitoring, drift detection, automated retraining, rollback). These are distinct from the workflow-orchestration patterns described in this section, and both layers are required for mature deployments. Workflow orchestration manages the human and system actions; data orchestration manages the model and pipeline that drive those actions.

Infrastructure AI note. When the orchestration layer is running multiple AI deployments across multiple workflows — which is the steady state for any portco past Phase 3 of the 100-day plan — orchestration is itself Infrastructure AI in the sense of §5.0. The same orchestration platform serves as the substrate for many deployments and accumulates value over time as a Repeat-stage asset (§2.7). Design the orchestration substrate for that future from the start, not retrospectively: shared exception handling, shared model registry, shared observability, shared governance. The cost of bolting these on after the third or fourth deployment is the most consistent reason mid-market AI programmes stall.

2.6 E — Execute

v4 — pattern-specific sequencing. For Experience AI, sequence from a single bounded customer surface outward. Resist the temptation to platform-engineer the customer experience layer in the first 100 days. Get one surface excellent, measure the outcome, then extend. For Decision AI, sequence from the highest-volume, highest-value, most-data-rich decision outward. Resist the temptation to build a decision platform that handles all functions. Get one decision to live deployment with measured outcomes, then extend.

Purpose. Deliver high-impact outcomes against the priority KPIs, in partnership with management. Execute is where strategy, capability, intelligence, and orchestration produce results.

What good looks like. Material, measurable improvement in the priority KPIs within the planned timeframe, delivered through changes the organisation owns and can sustain.

Inputs.

• Target operating model from Lead
• Capability moves underway from Capability
• AI use-case longlist, prioritised
• Orchestrated workflows live
• Management team aligned and accountable

Activities.

• Sequence execution by impact and feasibility (the impact-feasibility matrix runs as a working tool)
• Quick wins: visible, fast, credibility-building moves in weeks 1–12
• Structural improvements: deeper changes through months 3–12
• Platform-level moves: scalable capabilities through months 6–18
• Run the operating cadence (weekly, monthly, quarterly — see Part 3)
• Measure relentlessly. Every priority KPI has a named owner, a target, a baseline, and a delivery date.
• Iterate. SCALER is a loop; if Execute is showing no movement, the constraint register from Analyse needs revisiting.

Outputs.

• Priority KPIs improving against baseline
• Execution scorecard maintained at known cadence
• Management reporting upgraded — observed reality, not narrative
• Cumulative AI deployment delivering measured outcomes
• Patterns and reusable assets emerging for Repeat

Common failure modes.

• All quick wins, no structural change. The business looks better for two quarters, then reverts.
• All structural change, no quick wins. The organisation loses faith in the programme before the structural moves bear fruit.
• KPIs that are not tied to the strategy. Activity metrics flourish; outcome metrics languish.
• Imposing rather than partnering. The CEO is not running the transformation programme; this is a failure mode, not a feature.

Connection to AI. AI deployment in Execute follows the impact-feasibility prioritisation: easiest first, highest impact next. We deploy AI inside orchestrated workflows with measurement built in from day one. Every AI deployment has a baseline, a target, and a sunset criterion — under what conditions would we stop using this?

2.7 R — Repeat (Scale)

Purpose. Convert what worked in one place into a platform capability that travels — across teams, across functions, and across the portfolio.

What good looks like. A working, deployable, repeatable asset (a tool, a workflow template, a playbook, a dataset, a case study) that the next portco can use to compress its own SCALER cycle.

Inputs.

• Outcomes and assets from Execute
• Anonymised cross-portco data
• Existing Anneal platform tools
• Lessons-learned from prior investments

Activities.

• Codify the working pattern: what was done, in what order, by whom, with what tooling, producing what outcome
• Generalise the pattern: what is portfolio-wide vs. specific to this business?
• Productise the reusable parts: tools, templates, dashboards, playbooks
• Deploy across other applicable portcos
• Track adoption and outcomes across the portfolio
• Update the Anneal toolkit based on learnings

Outputs.

• New or upgraded entries in the Anneal toolkit
• Cross-portfolio playbook updates
• Anonymised case studies for internal reuse and external (LP, fundraise) use
• Portfolio intelligence — patterns visible across investments
• Updated SCALER methodology where material learning warrants

Common failure modes.

• Treating Repeat as documentation work. It is product work — a real tool that another portco will use without help.
• Failing to ring-fence the time and people to do Repeat. If Repeat has no owner, it does not happen.
• Deploying Anneal toolkit assets into portcos that have not done Strategic Alignment and Capability. The asset will not stick.

Connection to AI. Repeat is also where AI portfolio intelligence comes online — anonymised data flows from each portco into Anneal-level analytics that surface patterns no individual portco can see. This is the long-run compounding asset of the firm.

Platform AI note. Trained models and accumulated data are uniquely powerful Repeat assets. Models trained on one portco’s data often transfer (with calibration) to comparable portcos; with appropriate federated learning architectures and contractual frames, data from multiple portcos can train models that perform better for each individual portco than its own data alone could produce. This is the single most compounding asset class in the Anneal toolkit and warrants disproportionate investment. The economics: Workflow AI assets compound linearly with deployments; Platform AI assets compound super-linearly with data volume and model maturity.

3.1 The engagement model — partnership, not delivery

Anneal works alongside management teams. We do not run programmes for them, we do not deliver outcomes to them, and we do not own KPIs they should own. Where this language slips into our work, the work itself is at risk.

In practical terms:

• The CEO owns every priority KPI. We co-design how to move them; the CEO is accountable for the movement.
• Operating partners are embedded with management for defined periods, in defined roles. They are not consultants on rotation; they are operators on assignment.
• We bring tools, methodologies, capital, and a network. We do not bring people who will do the work for management — that is the wrong shape of help.
• Decisions are made in management meetings, by the management team, with our input as one input among several. Where we disagree, we say so clearly and once; if the decision goes the other way, we support it.

The single highest-leverage shift between consulting and partnership is in how friction is handled. In consulting, friction is the consultant’s problem to manage around. In partnership, friction is named and resolved by the people involved, on the day, in the meeting.

3.2 Governance and operating cadence

The rhythm of transformation matters more than its intensity. The cadence we run, by default:

The cadence is non-negotiable. Cancelling the weekly drives slippage faster than any other single move.

3.3 The diagnostic toolkit

Our diagnostic toolkit is the set of tools and methods we use to see the business. The principle: prefer observed data to reported data, prefer reported data to narrative, prefer narrative to assumption.

Process intelligence tooling. We use process intelligence platforms (currently KYP.ai as our primary tool) to capture activity data at task level on selected end-user populations. This is the foundation of Analyse. Deployment is always within an explicit governance frame — see Part 8.

API-level data access. Where possible, we wire portco operational systems (CRM, ERP, ticketing, comms, finance) into a portfolio data layer that allows real-time view at portco and portfolio level. Most portcos arrive without this layer in place; standing it up is part of the Capability build.

AI-augmented analysis. We deploy LLM-driven pattern detection, summarisation, and anomaly identification on top of the captured data. This compresses the time from data to insight from weeks to days.

Targeted interviews. Used for context, never for diagnosis. The principle is: interviews answer “why,” data answers “what” and “how much.”

Competitive and market data. Standard external data sources, treated as one input. We are sceptical of any narrative that originates entirely outside the business.

3.4 The orchestration toolkit

The orchestration toolkit is the set of tools that structure execution at scale.

Orchestration platform. Currently Enate as our primary platform; the role is to host workflow definitions, allocate tasks across human, system, and AI execution, and provide the substrate for monitoring, exception handling, and AI deployment.

AI Agents. Increasingly, AI Agents perform discrete tasks within orchestrated workflows — research, drafting, classification, extraction, summarisation. Agents are deployed inside orchestration, never beside it.

Workflow design templates. Standard task definitions, ownership patterns, and SLA templates that allow workflow design to be compressed. Adopted and adapted, not re-invented per portco.

Monitoring dashboards. Standard dashboards on top of orchestrated workflows that give the CEO and operating team a live view of execution.

3.5 Talent and leadership

The single highest-leverage decision in any hold period is whether the management team is right for the strategy. We treat this question with deliberate seriousness in the first 100 days and continuously thereafter.

The framework:

1. Top-team assessment. Honest, written, partner-level view of each member of the executive team against the strategy. Updated quarterly.
2. Gap-naming. Where there is a gap, name it. The two failure modes are pretending there is no gap, and naming the gap but not acting.
3. Action. Replace, augment, redeploy, or coach. Each action has a sequencing decision attached: now, on a specific trigger, by a specific date, or as part of a planned exit.
4. Pipeline. A standing pipeline of replacement and augmentation candidates is maintained at firm level. Surprises in talent should be rare.

We do not prefer change for its own sake. Most management teams are mostly right. But the cost of a wrong management team, allowed to stay too long, exceeds almost any other cost in the hold.

3.6 KPI framework

We instrument every investment around a small number of priority KPIs, tied directly to the strategy. Some principles.

Outcome over activity. Activity KPIs (calls made, tickets closed) are diagnostic; outcome KPIs (revenue growth, conversion, NRR, EBITDA margin) are managerial. The CEO’s scorecard is outcome-led.

Five to seven, not fifty. A KPI dashboard with fifty metrics is a KPI dashboard with no metrics. Five to seven on the CEO scorecard, with depth available below.

Defined the same way everywhere. Each KPI has a written definition, a baseline, a target, and an owner. Definitional drift is the leading cause of dashboards that nobody trusts.

Updated continuously. Monthly is the floor; for revenue and operational KPIs, weekly is preferable. Lag is the enemy of decision speed.

Connected to value at exit. Each priority KPI should map cleanly to the multiple-expansion or earnings-growth narrative we expect to tell at exit. If a KPI does not affect that narrative, it is the wrong KPI.

A standard CEO scorecard, indicative:

4.1 Growth levers

Pricing. The most consistently underused lever in mid-market transformation. Most portcos’ price architecture is a fossil record of past sales conversations rather than a designed system. Standard moves: segmented price–value mapping, list rationalisation, structured discounting governance, value-based pricing on new propositions, contract-renewal discipline.

Sales effectiveness. Pipeline rigour, segment focus (per Strategic Alignment), conversion improvement at the priority stages. Heavily AI-supported — see Pattern 1 in Part 6.

Customer expansion. Land-and-expand discipline, NRR improvement, separation of account management from new sales, success-led expansion playbooks.

New segments and geographies. Sequenced, disciplined entry, with early Capability investment to de-risk.

Inorganic growth. Bolt-ons that buy capability, geography, or customer base. Treated as an extension of the strategy, not a separate workstream. A repeatable acquisition playbook is a standard Repeat asset.

4.2 Capacity levers

The work of unlocking trapped capacity, predominantly in services-based businesses where headcount is high and process variance is higher than it should be. Pattern 2 in Part 6 walks the worked example.

Standard moves:

• Workflow standardisation across teams, regions, accounts
• Removal of manual, repetitive, error-prone work via automation and AI
• Orchestration to remove queueing time and rework
• Capacity unlocked equals revenue capacity unlocked, where demand exists. The case is growth-funded, not cost-funded.

4.3 Expertise scaling

Specific to professional-services and expertise-led businesses where senior specialists are the binding constraint. AI Agents augmenting human experts is the central move; Pattern 3 in Part 6 walks the worked example.

The principle: scale the expert’s reach, not the expert’s hours. AI does the first-pass work; the expert reviews, judges, and adds value at the high end.

4.4 Capital efficiency

Working capital improvements, capex discipline, inventory optimisation, payment terms. Less narrative impact than growth levers but high cash impact in many businesses. Routine moves: tighten DSO, extend DPO without rupturing supplier relationships, rationalise inventory, ROI-discipline capex above defined thresholds.

4.5 Cost — the last lever

Cost-out is the lever of last resort. When it is necessary, it is necessary; we do not avoid it for political reasons. But it is rarely the lever that materially moves the multiple at exit, and reaching for it first usually betrays a missing strategy.

Where cost-out is the right move (mis-sized G&A, unviable cost structures, post-acquisition integration), it is run with the same rigour as any other lever — orchestrated, measured, sustained. We do not run cost programmes as one-off events.

4.6 AI-enabled platform capability

The first five levers in this Part operate at the level of operational improvement. Section 4.6 sits at a different level — it can move the business model itself.

When a portfolio company has accumulating data exhaust and a recurring relationship with its clients, there is often an unbuilt platform asset inside the business. Instrumenting the data, training models on it, and building a diagnostic / recognition / recommendation capability on top — sometimes extending to autonomous action — turns operational performance into proprietary intellectual property that simultaneously:

• Improves the underlying service through diagnostics and recommendations the business could not previously produce.
• Strengthens the commercial position because the data and the trained models become a moat.
• Repositions the value proposition from labour-intensive or product-intensive to outcome-based, with the platform providing the evidence.
• Justifies premium pricing on the basis of measured outcomes the platform can demonstrate.
• Generates a new growth vector in the form of data products, platform subscriptions, or licensing.
• Strengthens the multiple at exit because data-platform businesses trade higher than equivalent labour-or-product businesses.
• Produces evidence and advocacy — and this is often as important as the operational gain itself. A platform that captures longitudinal outcomes lets the business prove its value to skeptical buyers, payers, regulators, and procurement functions in a way that case studies and testimonials cannot. In sectors where the buyer is risk-averse or budget-constrained, the proof is the sales tool.

4.7 Experience AI — reinventing the customer interface

Purpose. Make the customer experience materially better, materially cheaper to deliver, or both — and at the limit, reinvent the product itself around what AI now makes possible. This is the largest top-line lever in the methodology. In services and consumer businesses with sustained customer contact, Experience AI is increasingly the lever that determines whether the next five years will be flat, declining, or breakout.

What good looks like. A specific, sequenced re-design of one or more customer interactions where AI is doing work that previously could not have been done at all, or could only have been done at high human cost. Three flavours show up most often in mid-market:

• Conversational interfaces. Sales chat, support deflection, AI-assisted onboarding, AI sales co-pilots, voice agents for inbound. The metric set is conversion uplift, CSAT, time-to-value, and deflection rate of low-complexity tickets.
• Personalization at scale. Per-customer landing pages, per-segment product recommendations, dynamic content, generated marketing assets at the per-account level. The metric set is conversion, NRR, expansion rate, and content production cost.
• Agentic and AI-native product features. AI that does work for the customer inside the product — drafting, summarizing, planning, executing — to the point where the AI becomes the experience rather than an assistant to it. The metric set is feature adoption, usage frequency, retention, and pricing power.

The value mechanic. Experience AI sits at the top of the income statement — it changes revenue, retention, and expansion, and only secondarily affects cost. The order-of-magnitude opportunities are typically:

• 5–15% conversion uplift on inbound traffic where AI now answers questions a static site couldn’t.
• 2–4 point NRR improvement on B2B SaaS through better in-product onboarding, expansion prompting, and churn risk intervention.
• 30–60% deflection of low-complexity support tickets with maintained or higher CSAT, freeing premium service for high-value moments.
• New pricing tiers and ARPU expansion where AI features command standalone premium.

These are operating model bets, not feature releases. The portcos that capture them invest at platform level — the design, evaluation, prompt engineering, and content infrastructure — not as one-off features.

When Experience AI is the right shape. When the portco has sustained customer contact (services, SaaS, marketplaces, consumer) and the customer experience is currently inconsistent, slow, generic, or expensive to deliver. When the leadership team can credibly own brand-facing AI risk. When there is enough customer data and history to build evaluation sets the business actually trusts. When the existing product or service architecture is modular enough that AI features can be introduced without a multi-year platform rewrite.

When it is not the right shape. When the binding constraint is internal productivity rather than customer experience — Workflow AI is faster and lower-risk. When the portco’s brand exposure or regulatory profile makes customer-facing AI a step too far for the operating partner team to support. When the data needed to train and evaluate the model is too thin to produce reliable behaviour.

Talent and capability shape. Experience AI sits closer to product and design than to operations. The capability shape mirrors a consumer-grade product team more than an ops automation team: product managers who can own AI features end-to-end including evaluation; designers who can design for non-deterministic AI behaviour (graceful failure, escalation, transparency); prompt and behaviour engineers — the discipline of shaping AI outputs to brand-consistent, factually-grounded, escalation-ready responses; evaluation engineering — the rigorous building and maintenance of test sets that catch regressions before customers do; and customer experience analytics — qualitative review of AI conversations at sample, not just dashboard metrics. This shape is meaningfully different from Workflow AI’s capability shape (process intelligence, change management) and from Platform AI’s (sensors, MLOps, edge engineering). Hire and develop accordingly.

Distinct risks. Experience AI introduces risks the other patterns do not: brand exposure (every AI conversation with a customer is the brand speaking; one captured screenshot of an AI behaving badly does more damage than thirty good interactions earn back); hallucination at the edge (AI confidently producing wrong information to a customer is uniquely costly — evaluation discipline and grounding to first-party content are not optional); regulatory and consent (transparency that the user is talking to AI, data-use consent, opt-outs, age and capacity considerations in some categories); escalation design (AI features without a credible path to a human in the moment will fail at the high-stakes 5% of interactions and lose the trust of the other 95%); and replication risk (Experience AI features that look unique on launch are increasingly easy to replicate within months — the defensible asset is the data, the evaluation set, and the iteration cadence, not the feature itself).

Governance principles. In addition to v3’s general AI governance principles (Part 8), Experience AI requires pre-launch evaluation against a held-out test set covering the brand-sensitive long tail (not just happy-path examples); a clear escalation path to a human, available within the same surface, for any customer-facing AI deployment; customer-facing transparency about when AI is operating, what it can and cannot do, and how to reach a person; documented behaviour standards (tone, refusal categories, escalation triggers) with periodic review; and brand and legal sign-off on the deployment, not just engineering sign-off.

Cross-pattern combinations. Experience AI almost always rides on top of other patterns. A Decision AI underneath an Experience AI surface is what makes the personalization feel intelligent rather than generic. Workflow AI underneath an Experience AI deployment is what makes the customer-facing employee fast enough to deliver the experience profitably. Platform AI under an Experience AI deployment is what makes the experience defensible — the data and model assets the competition can’t replicate.

Worked example (sketch). A £100m revenue B2B SaaS business with 14% net revenue retention drag from onboarding-stage churn. Diagnostic shows new customers reach time-to-value 3–4 weeks slower than benchmark, primarily because in-product configuration requires a customer success manager hour the business cannot scale. Experience AI build deploys an in-product onboarding agent that handles 70% of configuration questions, recommends next-best-action based on the customer’s recorded goals, and escalates to a human only on the 30% it cannot resolve. Within 12 months NRR improves 6 points and CSM capacity reallocates to expansion conversations. Anneal lens: this is the right Experience AI build because the data exists, the customer experience is the binding constraint, the leadership team can credibly own brand-facing AI risk, and the build is sequenced from a single bounded surface outward rather than as a platform re-architecture.

4.8 Decision AI — improving the decisions the business makes

Purpose. Make the recurring decisions inside the business faster, more consistent, and better — by deploying models that turn the data the business already has into specific, actionable recommendations or autonomous calls within agreed bounds. Decision AI lives in the management cadence: in pricing, in credit, in scheduling, in mix, in capital allocation. It is the lever that converts the analytics layer most mid-market businesses already have into operational reality.

What good looks like. A specific, named set of recurring decisions inside the business — typically five to twelve — where AI moves the decision-maker’s hand-built spreadsheet or judgement-call into a model-supported recommendation with measured before/after performance. Common examples:

• Pricing decisions. Per-customer price recommendations, list-vs-pocket discipline, dynamic pricing for time- and inventory-sensitive offers, contract renewal pricing.
• Demand and capacity decisions. Demand forecasting, capacity planning, staffing recommendations, route optimization, slot allocation.
• Risk decisions. Credit scoring, fraud detection, churn risk identification, service-level risk scoring, supplier risk.
• Sales decisions. Lead scoring, account prioritization, next-best-action recommendations, win-probability scoring, upsell propensity.
• Service decisions. Predictive maintenance scheduling, parts pre-positioning, intervention prioritization, escalation routing.

The value mechanic. Decision AI sits in the middle of the income statement — its effects show up in gross margin, mix, working capital, capital efficiency, and decision cycle time. The mechanism is the same across the examples: replace a high-variance, judgement-driven decision with a model-supported one, and the average decision quality rises while the variance drops. Order-of-magnitude opportunities are typically:

• 200–400bps gross margin improvement from pricing discipline in B2B businesses with material discount-leakage today.
• 5–15% reduction in working capital from better demand and inventory decisions.
• 30–60% reduction in loss rates from improved credit and fraud decisions.
• 10–25% improvement in field service productivity from better scheduling and parts pre-positioning decisions.

These are not technology wins. They are operating model wins enabled by technology. The data has often been there for years; the decision discipline has not.

When Decision AI is the right shape. When the business makes high-volume, high-stakes decisions repeatedly and those decisions are currently driven by inconsistent judgement, hand-built spreadsheets, or static rules-based logic. When the data needed to support the decision exists at meaningful quality and history. When management is willing to commit to acting on the model output, not just receiving it as another dashboard. When the cost of a wrong decision is bounded and reversible enough that model error is recoverable.

When it is not the right shape. When the decision is one-off rather than recurring — Decision AI compounds through repetition, and a once-a-year strategic decision is not the place to deploy it. When the data quality is genuinely too poor and the prerequisite is a data foundation build rather than a model build. When management will not bind themselves to acting on the recommendation — Decision AI becomes shelfware when it sits beside an unchanged decision process.

Talent and capability shape. Decision AI requires a different team shape from Workflow AI (process intelligence + change management) and Experience AI (product + design). Closer to a quant or revenue management function than a product team: decision scientists who can frame a business decision as a model-supported decision, design the experiment, and interpret the output; data scientists with productionisation experience, not just notebook proficiency; MLOps and model-monitoring engineering — model drift detection, retraining schedules, model risk management; business analysts embedded in the function (pricing, credit, ops) who own the model output as part of their day-to-day; and a senior business owner of each decision — the function head who commits to acting on the model. The capability gap that kills Decision AI builds is most often the last one: a model that no business owner has signed up to use. The build sequence anchors on the decision owner, not on the model.

Distinct risks. Decision AI introduces risks beyond those of Workflow AI: model risk and drift (models degrade silently as the underlying conditions change; without active monitoring, a deployment that worked in year one is making materially worse decisions by year three); bias and fairness (decisions that affect customers, suppliers, or employees must be auditable for bias and have an override path; legal and regulatory exposure on this dimension is increasing across jurisdictions); decision rights ambiguity (when the model recommends and the human can override, who owns the outcome? decision rights registers are part of the build, not a follow-up); optimization to the wrong objective (Decision AI optimises ruthlessly against whatever metric it is given — wrong metric, wrong objective; the discipline of specifying the objective function as a business owner is foundational); and self-fulfilling feedback loops (some decisions shape the very data that retrains the model; without thoughtful design, the model entrenches its early bias rather than correcting it).

Governance principles. In addition to v3’s general AI governance, Decision AI requires a documented decision rights register for every deployment (what the model decides, what it recommends, what it escalates); pre-launch and ongoing bias-and-fairness review for customer-, supplier-, and people-affecting decisions; model risk management discipline (validation, monitoring, drift detection, retraining triggers, rollback protocols — treat models as regulated operational infrastructure); a named business owner for each model with accountability for its decisions; and a periodic decision-quality review — not “is the model accurate?” but “are the business outcomes better than before?”

Cross-pattern combinations. Decision AI is the connective tissue under most mature AI portcos. Underneath Experience AI it makes the personalization feel intelligent rather than generic. Alongside Workflow AI it gives the operator a recommendation rather than a blank screen. Under Platform AI it makes the sensor data actionable rather than archival. A Decision AI capability that is good across the function set is one of the most under-priced sources of advantage in mid-market — the data has often been there for years, and the discipline of using it is what unlocks the value.

Worked example (sketch). A £150m revenue B2B distribution business with a 41% gross margin that the sector benchmark suggests should be 47–49%. Diagnostic shows 320bps of pocket-price erosion versus list, concentrated in mid-tier accounts where sales reps grant ad hoc discount without management visibility. Decision AI build deploys a per-quote pricing recommendation model that scores each line against historical win/loss, account behaviour, segment elasticity, and competitive intensity, with a transparent recommended price and discount band. Reps retain override authority but with named approval above a threshold. Within 12 months pocket price recovers 180bps and gross margin moves to 44%. Anneal lens: this is the right Decision AI build because the decisions are high-volume and recurring, the data exists, the upside is bounded and measurable, and pricing discipline is now the binding constraint on margin rather than cost-out.

5.0 The five AI patterns

Before we walk through how AI is built as a capability, it is worth being explicit about the patterns Anneal recognises. v4 names five distinct AI patterns. Four are vertical value patterns — each defined by who uses the AI and which part of the income statement it moves. The fifth, Infrastructure AI, is horizontal — the operational substrate on which the other four scale safely. The patterns are complementary; mature deployments combine several of them, but the relative emphasis depends on the business and the binding constraint.

The four vertical patterns:

1. Workflow AI. AI deployed inside existing workflows to make existing work better. The user is an internal operator. The value mechanic is productivity — capacity released, throughput raised, cycle time compressed. This is the most-deployed pattern in mid-market today and the most fully covered in the toolkit.
2. Decision AI (see §4.8). AI deployed to improve specific recurring decisions inside the business. The user is a decision-maker. The value mechanic is decision quality — better commercial decisions, less wastage, less risk, faster cycles. Decision AI sits inside the management cadence and changes how the business converts data into action.
3. Experience AI (see §4.7). AI deployed at the customer or end-user interface. The user is the customer themselves, or a customer-facing employee operating with AI assistance in real time. The value mechanic is top-line — NRR, conversion, retention, expansion, customer satisfaction, deflection of low-value work, and at the limit, reinvention of the product itself. This is the highest-ceiling pattern in revenue terms and the one most likely to define category winners over the next five years.
4. Platform AI (see §4.6). AI built as new infrastructure-grade capability — sensors, telemetry, image data, edge models, trained patterns. The user is the business itself; the asset is the platform. The value mechanic is moat — capability the competition cannot replicate without making the same multi-year investment.

The horizontal substrate:

5. Infrastructure AI. The operational substrate beneath the other four. Orchestration, observability, MLOps, governance and risk tooling, data fabric, evaluation infrastructure. The defining feature is leverage: a single Infrastructure AI investment makes every Workflow AI, Decision AI, Experience AI, and Platform AI deployment more reliable, faster to ship, and easier to govern. The case for treating it as a first-class pattern, rather than as IT plumbing that emerges by accident, is straightforward: the other four don’t scale without it.

The patterns are not mutually exclusive. The highest-conviction theses combine them. A SaaS business with a Sales archetype may run Workflow AI in the GTM motion, Decision AI in renewals and pricing, Experience AI in the product, and Platform AI in the underlying data layer that powers all three — with Infrastructure AI as the substrate that lets each of the above run safely. The discipline is to identify which pattern is the binding constraint — the one whose absence holds back the others — and to sequence the build accordingly.

Most of Part 2 of this document is written about all three patterns simultaneously. Where the patterns diverge — most notably in Capability, Analyse, and Lead — call-outs are inserted in the relevant SCALER stage. Part 6.5 (Pattern 4 — Platform archetype) walks Platform AI in worked detail; the §2.5 Lead stage and §3.4 Orchestration toolkit walk the substrate that any Infrastructure AI deployment shares.

The rest of this Part addresses the capabilities common to all three patterns; where a capability is specific to one, it is flagged.

The third pattern in detail. Infrastructure AI sits at the operational substrate of the business — the layer beneath the workflows that Workflow AI improves and the layer beneath the products that Platform AI rebuilds. It is the orchestration that routes work between human, system, and AI tasks at scale; the process intelligence that observes how work happens across many workflows; the cross-cutting governance that monitors model health, drift, and compliance; the data and observability fabric that surfaces issues before they become problems downstream.

The defining feature of Infrastructure AI is leverage. A single Infrastructure AI investment can make every Workflow AI deployment and every Platform AI build more reliable, faster to ship, and easier to govern. The case for treating it as a first-class pattern, rather than as IT plumbing that emerges by accident, is straightforward: Workflow AI deployed without Infrastructure AI is fragile — orchestration, observability, and governance get bolted on under load and rarely survive it. Platform AI built without Infrastructure AI is brittle — the platform sits on shaky operational ground and the data and model lineage that should make it durable are absent.

When Infrastructure AI is the right shape. When the portco is scaling AI deployment across many workflows; when the firm is operating across many portcos and needs cross-cutting governance and pattern recognition; when the operating model itself is the value-creation lever (Pattern 2 Capacity, Pattern 4 Platform). When it is not the right shape: a single workflow with no scale ahead of it, where the substrate cost cannot be justified.

Talent and capability shape. Infrastructure AI requires roles distinct from both Workflow AI and Platform AI: SRE and platform engineering, observability and governance engineering, integration architecture, risk and compliance professionals with AI fluency. Building Infrastructure AI capability is its own capability build under §2.3 — and one of the most underpriced ones in mid-market.

Cross-pattern combinations. The three patterns are not mutually exclusive; mature deployments use all three. A platform play (§4.6, Pattern 4) typically requires Infrastructure AI to operate. A capacity play (Pattern 2) typically combines Workflow AI deployment with Infrastructure AI orchestration. The early-stage question is which pattern is the binding constraint, not which to pick exclusively.

5.1 Our point of view

AI in portcos is a capability, not a project. The distinction matters enormously.

A project ends. A capability compounds. Most portco AI initiatives fail because they were scoped as projects — pick a use case, pilot a tool, declare success, stop. Capability is what is left in the building when we exit; it is people, data, governance, tools, and habits, not vendors.

Tools are commodity-like; capability is not. Vendors and models will change rapidly across our hold periods. The data foundations, the governance frame, the deployment patterns, and the people are durable.

AI lives inside SCALER, not beside it. Each stage has explicit AI activity built in (see the Connection to AI sections in Part 2). Treating AI as a separate workstream is a category error.

Sensible structure beats clever ambition. Most portcos do not need to invent AI. They need to apply AI thoughtfully to known constraints, in orchestrated workflows, with measurement and governance. Sensible, structured, repeatable.

5.2 AI readiness assessment

Run as part of Capability assessment in the first 100 days. The five dimensions:

1. Data. Is the operational data clean, accessible, governed, and at sufficient granularity? This is the most common gating constraint.
2. People. Are there people in the business who can scope, deploy, govern, and maintain AI systems? If not, what is the capability build plan?
3. Tooling. What AI tooling is in place, what is in flight, and what is needed for the priority constraints?
4. Governance. Are there policies and processes for AI deployment, model risk, data privacy, vendor risk, and incident response?
5. Sponsorship. Does the management team understand AI well enough to direct it? Where the answer is “no,” the build plan includes board / management upskilling.

5.3 Build vs. buy vs. use

Three pathways, each appropriate in different circumstances.

Use — apply existing AI products (Microsoft Copilot, Google AI products, packaged industry-vertical AI). The default for the long tail of use cases; cheapest, fastest, lowest risk.

Buy — adopt specialised AI products built for specific functions or industries. The default where a strong vendor exists for a high-value use case.

Build — bespoke AI deployments, typically combining LLM APIs, agent frameworks, and orchestrated workflows. The default where the use case is core to differentiation, the data is proprietary, and the value is large.

The default mix in mid-market portcos tends toward 70% Use, 25% Buy, 5% Build. Build-heavy programmes are usually a sign of capability mis-direction.

5.4 Use-case prioritisation

The standard impact-feasibility matrix, run quarterly:

Inputs to the matrix come from Analyse. We do not generate AI use-case lists in workshops; we generate them from observed workflow data.

5.5 AI Agents and orchestration

Agents are the primary deployment pattern for AI work in Execute. Three principles:

1. Agents live inside orchestration. They appear as tasks in workflows, with defined inputs, outputs, and SLAs, alongside human and system tasks.
2. Agents have human oversight by default. Initial deployments include explicit human review of the agent’s output. Oversight relaxes as evidence accrues, deliberately, not by drift.
3. Agents have sunset criteria. Each agent deployment has explicit criteria under which it is suspended or replaced — quality drift, regulatory change, model deprecation, business model change.

5.6 Responsible AI principles

These principles, in addition to the data principles in Part 8, govern how AI is built, deployed, and operated in our portcos:

• Transparency. People affected by AI know they are. The agent’s role and limits are visible.
• Human-in-the-loop by default. Particularly in customer-affecting and people-affecting decisions.
• Bias and fairness review. Every customer-affecting AI deployment has a documented bias and fairness review.
• Auditability. Decisions made or supported by AI are logged, explainable, and reviewable.
• Vendor responsibility. We do due diligence on AI vendors’ own practices, not just their feature lists.

6.1 The four archetypes

Patterns 1–3 are Workflow AI patterns: AI deployed inside existing workflows to make existing work better. Pattern 4 is a Platform AI pattern: AI built as a new capability that reshapes the business itself.

6.2 Pattern 1 — Execution-constrained (Sales archetype)

Situation. A £40–50m revenue B2B services business providing compliance and technical support to enterprise clients. Sixty-person sales organisation operating across five sectors (Financial Services, Healthcare, Energy, Industrial, Public Sector). Revenue growth stalled around 5%. Pipeline coverage approximately 3× but with inconsistent conversion. Sales cycle 90–120 days. The business believed it had a sales effectiveness problem; the root cause was unclear.

Root cause. Four constraints, none of which the management team could see clearly without observed data.

1. Over-segmentation and lack of focus. Sales effort spread across five sectors with uneven performance. The top two sectors delivered ~65% of wins but received under 50% of focus. Low-conversion sectors absorbed disproportionate time.
2. Fragmented sales execution. No consistent definition of pipeline stages. Each team managed deals differently. High dependence on individual behaviour.
3. Hidden delays and manual work. 24–48 hour delays between deal stages. Manual CRM updates and follow-ups. Approval bottlenecks invisible to reporting.
4. Lack of real visibility. Reporting lagging by 2–3 weeks. No clear view of where deals were stalling or why deals were being lost.

SCALER application.

Strategic Alignment. Narrowed focus to where growth was most achievable. Prioritised the top two sectors (Financial Services, Healthcare). Reduced active focus from five sectors to three. Reallocated approximately 30% of sales capacity toward higher-conversion opportunities.

Capability. Introduced structured pipeline management with defined ownership at each stage. Strengthened sales leadership oversight. Introduced a weekly performance cadence.

Analyse (Process Intelligence + AI). Deployed KYP.ai with AI-driven workflow analytics. Identified that 28% of sales time was spent on non-selling admin, with repeated delays at proposal and internal-approval stages. AI surfaced the highest drop-off at the proposal-to-negotiation transition, top performers following 2× faster follow-up patterns, and a strong correlation between response time and win rate.

Lead (Orchestration + AI). Deployed Enate. Defined six standard pipeline stages. Assigned ownership at each stage. Automated task allocation, follow-up reminders, and escalation triggers. AI flagged stalled deals (>48 hrs inactivity), prioritised deals by conversion probability, and recommended next-best actions.

Execute (AI-enabled). Reduced time between stages. Standardised approach across teams. AI supported automated follow-up emails within defined time windows, proposal generation templates, deal scoring and prioritisation, and pricing and positioning guidance. Sales teams shifted admin time into selling time.

Repeat. Rolled out across all regions and teams. Integrated into CRM and reporting. Standard dashboards and AI summaries deployed.

Outcome. Conversion rates improved, particularly in the priority sectors. Sales cycle reduced from ~100 days to ~75–80 days. Sales capacity increased through approximately 20–25% reduction in admin time. Revenue growth accelerated into double digits.

Reusable assets emerging. Standardised pipeline-stage definitions, the AI deal-scoring model, Enate sales workflow templates, and the segmented sales-effectiveness diagnostic — all now part of the Anneal toolkit.

6.3 Pattern 2 — Capacity-constrained (Delivery archetype)

Situation. A £60–70m revenue tech-enabled services business delivering outsourced operational support to enterprise clients. 400+ delivery staff across three service lines (Customer Operations, Back Office Processing, Technical Support). Revenue growth constrained at 6–7%. Client demand increasing. Delivery teams operating at 85–90% utilisation. The business believed it needed to hire to grow; the capacity constraints were not fully understood.

Root cause.

1. Capacity trapped in manual work. 25–30% of delivery time on manual data handling, rework, and low-value admin. Highly repetitive activities not standardised.
2. Fragmented workflows. Processes differed across service lines, teams, and client accounts. No consistent definition of tasks or handoffs.
3. Hidden inefficiencies and rework. Duplication, error correction, and inconsistent quality, only visible after client escalation.
4. Limited operational visibility. No real-time view of workload, task progress, or bottlenecks. Reporting lagging by days or weeks.

SCALER application.

Strategic Alignment. Reframed the problem from cost to scalable growth. Focused on increasing delivery capacity and improving throughput to enable growth without linear hiring. Prioritised the highest-margin service lines.

Capability. Defined clear roles across workflows. Introduced structured team leadership. Improved operational management discipline.

Analyse. KYP.ai + AI identified ~28% of time on non-core tasks, frequent system-switching, and high rework rates in specific process steps. AI surfaced patterns of repeated errors, tasks with highest time variability, and key bottlenecks in workflow transitions. The reality was significantly more complex than documented processes suggested.

Lead. Enate + AI: broke work into standardised task units, defined workflow stages and handoffs, introduced queue-based task management with real-time workload visibility. AI provided intelligent task routing, SLA-driven prioritisation, and early identification of backlog build-up.

Execute. Reduced manual work through automation of repetitive tasks and standardised workflows. AI supported document classification and processing, automated data extraction, quality checks and anomaly detection, and first-pass decision support. Delivery teams shifted from processing work to managing outcomes.

Repeat. Rolled out standard workflows across all teams. Embedded into operational reporting. Shared tooling and dashboards introduced.

Outcome. Effective capacity increased ~20–30%. Reduced need for immediate hiring. Improved quality and consistency. Faster turnaround times. Ability to onboard new clients without scaling headcount linearly.

Reusable assets emerging. Standard task-definition library, queue-management workflow templates, document-processing AI patterns, and the capacity-unlock diagnostic — added to the Anneal toolkit.

6.4 Pattern 3 — Talent-constrained (Expertise archetype)

Situation. A £30–40m revenue professional services business providing specialised regulatory and technical advisory services. ~120 consultants across three core areas (Regulatory Compliance, Risk & Audit Support, Technical Advisory). Strong demand. Pipeline growing >20%. Revenue growth constrained to 6–8%. The business was turning away work due to a shortage of qualified experts.

Root cause.

1. Scarcity of skilled resources. Heavy reliance on highly qualified specialists. Long lead time to hire and train. Senior experts overloaded with both client work and internal support.
2. Inefficient use of expert time. Significant time on research, document preparation, and repeat advisory queries. Experts acting as both knowledge repositories and bottlenecks for delivery.
3. Lack of knowledge leverage. Knowledge not systematically captured. Each engagement treated as bespoke. Limited reuse of prior work.
4. Inconsistent delivery speed. Variable turnaround times, driven by availability of key individuals and manual analysis effort.

SCALER application.

Strategic Alignment. Reframed the problem from hiring to scalability of expertise. Focused on increasing capacity without linear headcount growth, improving speed of delivery, and leveraging existing knowledge.

Capability. Identified tasks requiring deep expertise and tasks suitable for augmentation or automation. Defined new roles: expert oversight and AI-supported delivery.

Analyse. KYP.ai + AI identified ~35% of expert time on repeatable tasks. Common patterns surfaced across advisory engagements. Repeated research and documentation workflows mapped. AI highlighted similarities across client queries and tasks suitable for automation.

Lead. Orchestration + AI Agents. Broke work into research, analysis, drafting, review. AI Agents handled first-pass research, drafted documents and reports, responded to standard client queries. The orchestrated flow ran AI Agent → human expert → final output.

Execute. AI Agents deployed as a core part of the delivery model. Used for initial regulatory and technical research, generation of first-draft reports and client responses, summarisation of complex materials, and comparison across regulations or cases. Human experts reviewed, validated, and added judgement. Experts shifted from doing work to supervising and refining it.

Repeat. Deployed AI Agents across all advisory teams. Built shared knowledge base. Integrated into standard workflows.

Outcome. Effective expert capacity increased ~30–40%. Reduced dependency on hiring. Faster turnaround times. More consistent delivery quality. Ability to take on additional client demand.

Reusable assets emerging. AI Agent templates for research, drafting, and summarisation. Expert-augmentation workflow patterns. Knowledge-base architecture. Sequenced human–AI handoff design. Added to the Anneal toolkit.

6.5 Pattern 4 — Data-rich business (Platform archetype)

Situation. A £80–100m revenue commercial building services business — installs and services HVAC, building management systems, electrical, and plumbing across commercial property estates (offices, retail, healthcare estates, industrial parks). 600+ engineers across the UK and Northern Europe. ~3,000 customer sites with recurring service contracts. Operating model historically a mix of planned preventive maintenance and reactive break-fix. Profitable and growing in line with the sector at ~4–5%, with margins gradually compressing under labour and parts inflation. The business competes on price, engineer availability, and relationships; the value proposition is undifferentiated.

Root cause — and the strategic opportunity. The business has been a service-execution business for 25 years. Its data exhaust — site visit reports, equipment performance logs, fault history, parts replacement patterns, energy data from BMS systems, increasingly visual inspection imagery — has been operationally useful but never aggregated as an asset. Meanwhile the competitive set is starting to include data-led entrants who arrive with platform pitches and SaaS pricing. The defensible position is eroding from underneath.

The strategic opportunity sits inside the data exhaust the business already produces. Properly instrumented and modelled, that data could power a diagnostic and recommendation capability that no individual engineer or site manager possesses — predicting equipment failures weeks in advance, identifying energy inefficiencies invisible to manual inspection, and producing the longitudinal evidence to convert clients from break-fix to outcome-based contracts. The operational service becomes the proof point and the channel; the platform becomes the value.

SCALER application.

Strategic Alignment. The choice was framed deliberately: continue as a labour-intensive services business with gradually declining margins, or build a data-platform capability that repositions the value proposition over 24 months. The second path was chosen, with Anneal and management committing to the build. Priority client sectors narrowed to commercial offices and healthcare estates — highest data quality, highest willingness to pay for predictive value, longest contract durations. The growth thesis: same revenue base, materially better margins, with new platform-led growth on top.

Capability. The most material capability build of any investment in our portfolio. The existing organisation was strong in engineering and operations but had no data engineering, no ML engineering, no product capability. We hired a CTO from a SaaS background; built a data engineering team of six and an ML engineering team of four; added a product manager and a customer success leader. We made a deliberate decision not to attempt to retrain existing field engineers as data engineers — the gap was too large to bridge through training. We did, however, build close pairing between domain experts (senior engineers who knew what failure looked like) and the ML team, with formal labelling and validation processes. Cloud infrastructure and a managed ML stack: Buy. Bespoke models on the proprietary data: Build. Generic productivity AI for engineers: Use.

Analyse. This stage operated entirely differently from a Workflow AI engagement. Rather than a 4–8 week process intelligence study, we instrumented client sites — installed IoT sensors (vibration, thermal, electrical signature, acoustic) on selected equipment classes; exposed existing BMS data through APIs; ingested ten years of historic fault logs and maintenance records; began capturing engineer site-visit imagery as part of the standard work routine. The “Analyse” became a continuous, structural capability rather than a one-off exercise. Initial findings: 70% of unplanned failures had detectable precursor signals 7–30 days in advance; 25% of building energy use was attributable to equipment running outside spec without anyone noticing; specific vibration signature patterns predicted bearing failures with 85% accuracy 14 days out. None of this was visible in the documented processes; all of it was sitting in the data, unexploited.

Lead. Orchestration here required two distinct layers built in parallel. The workflow orchestration layer — built on Enate — coordinated engineer scheduling, parts logistics, and customer communications, as it would for any Workflow AI deployment. The data orchestration layer — built on managed cloud ML infrastructure — handled real-time sensor ingestion, feature engineering, model serving at scale, and ML operations (monitoring, drift detection, retraining, rollback). The engineer’s working day shifted from “respond to break-fix tickets” toward “execute predicted-failure interventions surfaced by the platform.” The platform’s outputs flowed into orchestrated workflows; engineers’ field observations flowed back into the platform as labels and validation. The two layers fed each other.

Execute. The platform deployed in three sequenced layers over 18 months, mapped to the value ladder in Part 4.6:

• Layer 1 — Diagnose. Deployed first. Models flagged anomalies and emerging issues. Engineers used the diagnostics during routine visits, building familiarity and labelled validation data.
• Layer 2 — Recognise. Deployed second. Models classified specific failure modes and equipment states with confidence scores. Recommended specific parts, interventions, and lead times. Used by service planners to schedule proactively.
• Layer 3 — Recommend. Deployed third. Outputs were exposed to clients via a portal — including projected savings, equipment health scores, and longitudinal performance against the sector benchmark generated from the firm-level data.
• A future Layer 4 — Act (automatic equipment adjustments via BMS integration, automated work-order dispatch, autonomous parts ordering) is on the roadmap behind explicit governance gates.

In parallel, the commercial proposition was repositioned. Clients converting to outcome-based contracts (guaranteed uptime, energy performance bands, lifecycle commitments) paid a 15–25% premium, with measured cost-of-ownership reductions of 8–15% in year one — the platform produced the evidence that justified the premium. The proof was the sales tool; the data was the procurement defence.

Repeat. The platform is the most powerful Repeat asset in the firm. Trained models improve with every site instrumented; patterns recognised on offices generalise (with calibration) to healthcare estates and industrial parks; the operations console deployed once is deployable everywhere. The data, federated across the portfolio, drives a sector-benchmarking layer no individual portco could produce alone. We are now exploring whether the platform itself is licensable to other building services businesses outside our portfolio — a portfolio company evolving toward being a platform provider in its own right.

Outcome (24 months).

• Engineer productivity up 22% (data-led routing, predictive scheduling)
• Unplanned downtime at instrumented sites down ~60%
• Outcome-based contracts now 35% of revenue, growing fast
• Gross margin improved 4 points; EBITDA margin improved 6 points
• Revenue growth re-accelerated to 12%
• The business is now valued by buyers and analysts as a tech-enabled platform business, not a services business — material multiple-expansion potential at exit

Reusable assets emerging. Sensor instrumentation patterns by equipment class; the trained model library by failure mode; the Recognise / Recommend confidence-scoring methodology; the engineer-facing operations console; the outcome-based commercial pricing model and contract templates; the data-foundation reference architecture; the make-vs-hire decision logic for data and ML capabilities; the 18-month sequencing of Diagnose → Recognise → Recommend deployment; the portfolio-level federated benchmarking layer.

6.6 What the patterns share

Four observations recur across the four archetypes.

First, the management team’s stated diagnosis was always partially right and substantially incomplete. In every case, the team knew there was a problem; in every case, observed data revealed structural causes that were not visible from inside the business. This is the case for instrumentation and process intelligence as default moves, not exotic ones.

Second, the binding constraint was always upstream of the visible symptom. Sales looked like a sales effectiveness problem; the constraint was strategic focus and orchestration. Delivery looked like a hiring problem; the constraint was workflow standardisation. Expertise looked like a recruitment problem; the constraint was knowledge architecture. Platform looked like competitive pressure on a commodity service; the constraint was an unbuilt data asset. SCALER pushes diagnosis upstream by design.

Third, AI delivered material value only after orchestration — in any of its three forms — was in place. In every Workflow AI case, the early-stage AI deployments that worked were embedded inside orchestrated workflows; standalone deployments produced limited value. In the Platform AI case, the data orchestration layer (pipelines, model serving, MLOps) was as load-bearing as the workflow orchestration layer; underinvesting in either was a failure mode. In every case where multiple AI deployments scaled successfully, an Infrastructure AI substrate — observability, governance, and cross-cutting orchestration — was deliberately built; where it was not, scale stalled around the third or fourth deployment.

Fourth, the most valuable Repeat assets are not documents — they are working capabilities. Patterns 1–3 produced workflow templates, agent libraries, and configuration assets. Pattern 4 produced trained models, instrumentation kits, and a federated data layer. In all four cases, the firm-level value is in the deployable artefact, not in the case study about it.

7.1 The portfolio learning loop

Repeatability is the part of SCALER most likely to be neglected, and the part with the highest long-run firm-level return. Every investment teaches us something; the question is whether the learning is captured, generalised, and re-deployed, or whether each new portco starts from scratch.

The loop:

1. Every Execute outcome is reviewed for transferable patterns.
2. Patterns are codified into reusable assets — tools, templates, playbooks, dashboards, models, case studies.
3. Assets enter the Anneal toolkit and are deployed in next investments where the pattern applies.
4. Adoption and outcome data flow back from each deployment, improving the asset.
5. The compounding effect: each new investment runs SCALER faster than the one before.

The loop fails by default. We engineer it to succeed by ring-fencing time and people for Repeat work, treating it as product work rather than documentation work, and building cross-portfolio fora where pattern recognition happens.

7.2 The Anneal toolkit

The Anneal toolkit is the firm-level inventory of reusable assets. It is structured into four categories.

Diagnostic assets. Process intelligence configurations by archetype, standard analytical libraries, the diagnostic question banks, the impact-feasibility scoring framework, the AI readiness assessment.

Operating model assets. Workflow templates by function (sales pipeline, delivery operations, expert advisory), Enate configuration libraries, governance and cadence templates, KPI dashboards by archetype.

AI assets. Agent templates by use-case category (research, drafting, classification, summarisation, decision support), prompt libraries with version control, governance and review templates, sunset-criterion templates.

Playbooks. End-to-end playbooks for the three archetypal patterns. Function-specific playbooks (pricing, sales effectiveness, working capital). Stage-of-hold playbooks (first 100 days, year-1 priorities, exit prep).

The toolkit is a product. It has a roadmap, an owner, a change-control process, and a quality bar. It is not a SharePoint folder of historical decks.

7.3 Data and portfolio intelligence

Beyond reusable assets, repeatability also lives in data. We are building a portfolio data layer that, with appropriate anonymisation, gives Anneal a view of operations and performance across investments that no individual portco has of itself.

Three uses follow:

• Cross-portco benchmarking. What does good look like for this KPI in this archetype? Answered with real data from comparable portcos, not consultant benchmarks.
• Pattern detection. AI-driven analysis at firm level surfaces patterns no single portco can see — early indicators of underperformance, common failure modes, leading indicators by sector.
• Strategic insight for new investments. Diligence on prospective investments runs against the firm’s accumulated portfolio intelligence, not just public data.

This is a multi-year build. Year one is data layer foundations and a few high-value views; year three onwards is where the compounding really shows.

Where Platform AI is in play, the firm-level data layer becomes more than a benchmarking and pattern-detection tool — it becomes a multi-tenant model improvement engine. With appropriate federated learning architectures and contractual frames, models trained across multiple portcos produce performance for each individual portco that is unattainable from its own data alone. The economics: each portco contributes data, each portco benefits from a better model than its own data could train, and the firm-level model is the long-run moat. This requires deliberate engineering and explicit client consent at investment level; it is not a default capability and should not be retrofitted.

7.4 Knowledge management

Knowledge management at firm level has three components.

Decision logs. Every material investment-level decision is logged with its rationale at the time. This includes investment committee decisions, strategic choices (e.g., management changes, segment focus, M&A pursuits), and major operating decisions. The point is not bureaucracy; it is to be able to look back honestly at how decisions were made.

Case studies. Anonymised, structured case studies of material moves on each investment. Internal first; selectively external for fundraise and LP communication.

Operating partner knowledge. The pattern-recognition that lives in operating partners is the most valuable knowledge in the firm and the most fragile. Deliberate transfer mechanisms — paired engagements, pattern-recognition fora, written debriefs — are essential to making it survive turnover.

8.1 Why this section exists

Process intelligence, AI deployment, and orchestration are powerful precisely because they touch how individual people work. That power has the obvious flip side: deployed without an explicit trust frame, these tools destroy the operating environment they were meant to improve.

We treat trust as a substrate, not an afterthought. The principles in this section are non-negotiable on Anneal investments and we expect management teams to hold us to them.

8.2 The principles

1. Process, not people. Observational data is captured, analysed, and acted on at process level — workflows, tasks, system patterns. Not at individual level.

2. Anonymised by default. Where data must touch individuals (e.g., to trace a workflow end-to-end), it is anonymised before it leaves the capture system. Aggregate views only reach management.

3. Aggregated by default. Findings are reported in aggregate. We do not produce reports that name individuals.

4. Transparent. Every workforce population on which process intelligence is deployed is told clearly, in advance, that it is being deployed; what is captured; what is not; how the data will be used; who will see it; and how long it will be retained.

5. Bounded. Scope is defined, time-bounded, and tied to an explicit transformation question. We do not run process intelligence in perpetuity, and we do not extend scope by drift.

6. Reviewable. The deployment is reviewable by an independent function — typically the portco’s HR or legal function plus an Anneal-side reviewer. Issues are surfaceable without retaliation.

8.3 What we do not do

It is as important to be explicit about what we do not do as about what we do.

• We do not surveil individuals.
• We do not produce productivity scorecards by named employee.
• We do not use process intelligence as evidence in performance management or termination decisions.
• We do not retain raw observational data beyond the scope of the transformation question.
• We do not deploy AI in customer-affecting decisions without human-in-the-loop.
• We do not deploy AI in employment decisions, full stop.

8.4 The conversation we run upfront

On every deployment, the conversation with the management team and the workforce population covers: why we are doing this, what we will capture, what we will not, who will see the data, how it will be anonymised and aggregated, how long it will be retained, and what the management team commits to do (and not do) with the findings. This conversation is run before deployment, in writing, and is repeated when scope changes.

This is not a legal requirement to be discharged; it is the social contract that makes the methodology work. Run it well and the workforce engages with the transformation. Run it poorly, or skip it, and the data is technically captured but operationally useless.

8.5 Additional considerations for Platform AI

Platform AI introduces governance dimensions beyond those covered by the principles in 8.2–8.4. None of these are blockers; all are work items that need to be planned, owned, and reviewed.

Image and sensor data privacy. Visual and sensor capture in client environments raises additional consent and retention questions: people who happen to be in frame in a workplace deployment; sensitive client environments such as healthcare or financial settings; data residency requirements that cross jurisdictions; CCTV-style footage retention regulations. Each Platform AI deployment requires an explicit data-protection assessment and, in many cases, consent at multiple levels (client, end-user, regulator).

Model risk and drift. Models trained on captured data degrade over time as the underlying conditions change — equipment is replaced, customer behaviour shifts, regulations change, sensor calibration drifts. Monitoring, retraining schedules, drift-detection thresholds, and rollback protocols are not optional. Treat the trained model as a regulated piece of operating infrastructure, not as a one-off project deliverable.

Action automation governance. As deployments mature toward “Act” on the value ladder, the controls around what the system can do autonomously, in what conditions, with what human-recovery paths, become safety-critical. Every autonomous action capability requires a documented decision rights register, a fallback plan, and an audit trail. The cost of getting this wrong scales with the action’s reach.

Regulated sectors. Financial services, energy, transport, infrastructure, food, healthcare-adjacent, and other regulated sectors impose specific requirements on AI deployment that are not always obvious to a generalist transformation team. Specialist legal and regulatory input is required early — not after the platform is deployed. EU AI Act risk tiering, UK regulatory guidance, sector-specific frameworks (FCA, MHRA, CAA, Ofgem, FSA) all need to be assessed up front.

Vendor concentration. Platform AI typically introduces deeper dependency on specific cloud providers, MLOps stacks, and model providers. A vendor risk plan covering pricing changes, deprecation, regulatory action against a vendor, and data-portability rights is part of the build, not an afterthought.

Evidence and advocacy responsibilities. Where the platform produces evidence used to make commercial claims to clients (cost savings, uptime, outcome improvements), the evidence must be defensible — methodology disclosed, comparison populations explained, confidence intervals stated, conflicts of interest acknowledged. Platforms that overclaim get found out; the resulting damage to the platform’s credibility is hard to recover.