Implementation playbooks
90-Day AI Implementation Playbook: move from pilot to repeatable operating system
A 90-day plan for scaling connected AI execution after the first outcome is proven.
Executive summary
Measure the operating outcome, not the AI activity.
Ninety days is the horizon at which an implementation stops being a project and becomes an operating capability. This plan is about repeatability: a standard way to add workflows, a governance model that scales past its first reviewer, cost and reliability visibility, ownership that outlives the original team, and a portfolio view showing where the next constraint sits.
The problem
What 90-Day AI Implementation Playbook is trying to fix.
By the third month the technical question is usually settled and an organisational one replaces it. Workflows exist and run, but each was built slightly differently, each is understood by the person who built it, and the request queue from other teams is growing faster than the team can serve it. Without a repeatable method, the implementation becomes a bottleneck shaped exactly like the two or three people who know how it works.
Governance hits the same wall. A single reviewer can hold the standard in their head for three workflows and cannot for fifteen. The permission decisions, human-review boundaries, and escalation rules that were made case by case need to become defaults that a new builder inherits automatically, or they will be re-litigated inconsistently every time and diverge until an incident makes the divergence visible.
The third pressure is economic. Consumption grows quietly, reliability varies between workflows, and nobody has a portfolio view showing which workflows deliver value, which consume disproportionate cost or intervention, and which should be retired. Ninety days is when a team either builds the standards, ownership, and visibility that let this scale, or accumulates a set of individually working workflows that collectively nobody can manage.
By this stage a second-order problem appears: the platform starts to have a reputation. Teams that had a workflow delivered quickly advocate for it; teams whose requests were deferred describe it as inaccessible; teams that experienced an early failure remember that instead of the fix. None of this is captured in delivery metrics, and it substantially determines how much work the implementation is allowed to take on next. Making the intake, the queue, and the reasons for prioritisation visible is as much a reputational control as an operational one.
There is also a cost dynamic that emerges around the third month and rarely before it. Consumption grows across more workflows, some of them running far more often than anticipated, and the first meaningful bill arrives without anyone having attributed spend to outcomes. Because usage-based costs are estimated rather than exact in most tooling, teams either over-react to a projection or ignore it until it is material. Establishing attribution and reconciling against canonical spend truth before the number is large is considerably easier than doing it afterwards.
Architecture
How UbiVibe supports this implementation.
Each stage below is something the platform does during delivery, not a suggested project phase to staff separately.
Step 01
A standard workflow definition pattern
Codify how a workflow is specified: trigger, end state, required sources, permitted actions, exception routes, owner, and acceptance evidence. A new workflow starting from this template inherits the decisions already made, which is what turns implementation speed into a property of the platform rather than of an individual.
Step 02
Inherited governance defaults
Permission scoping, tenant isolation, human-review boundaries for consequential decisions, and escalation paths become defaults applied to every new workflow rather than per-case judgements. Governance that must be re-derived each time will diverge, and divergence is usually discovered through an incident.
Step 03
Portfolio measurement
Completion, cycle time, intervention, exception rate, and consumption are visible per workflow in one place. The portfolio view is what makes retirement possible: without comparison, a workflow that costs more than it returns simply continues, because nothing ever surfaces it.
Step 04
Named ownership and handover
Every production workflow has a business owner accountable for its outcome and a documented runbook, so it survives the original builder moving on. Unowned workflows are the main source of the third-month drift where things still run but nobody can say whether they are still correct.
Step 05
Intake and prioritisation
Requests from other teams enter a defined intake with a stated outcome, an owner, and a constraint it addresses, rather than arriving as ad hoc asks. This is the mechanism that keeps the implementation targeted at business constraints instead of at whoever asks most persistently.
Step 06
Constraint review cadence
On a regular cycle, review where workflows actually stop -- context reach, permissions, data quality, exception handling, or adoption -- and direct the next increment there. Reviewing the constraint rather than the roadmap is what keeps the third month from becoming a feature backlog.
Step 07
Cost attribution per workflow
Consumption is attributed to workflows and reconciled against canonical spend truth rather than relying on estimated per-call figures. Establishing this while the numbers are small makes the eventual conversation about a workflow's value straightforward rather than adversarial.
Step 08
Visible queue and prioritisation reasons
The intake queue, its ordering, and the reason each item sits where it does are visible to requesting teams. This is a reputational control as much as an operational one: deferred teams accept a stated constraint far more readily than an unexplained silence.
Methodology
Rule 1
Define the target outcome and owner.
Rule 2
Document the current workflow and baseline.
Rule 3
Connect only the authoritative systems required for the first outcome.
Rule 4
Implement bounded permissions and exception paths.
Rule 5
Run acceptance evidence before expanding scope.
Measurement framework
Five dimensions worth measuring repeatedly.
Outcome completion
Qualified intents that reach the expected business outcome
Activity counts do not prove that the workflow delivered value.
Cycle time
Elapsed time from trigger to completed outcome
Faster completion is one of the clearest benefits of connected execution.
Human intervention
Manual touches, approvals, retries, and escalations per completed outcome
Automation should reduce avoidable work without removing appropriate oversight.
Exception rate
Runs that leave the expected path or require recovery
Exception frequency exposes brittle workflows and poor context.
Data provenance
Share of material decisions supported by current authoritative sources
AI output quality depends on trusted operating context.
Examples
90-Day AI Implementation Playbook in practice.
Concrete situations this framework is designed to resolve. Scenarios are illustrative operating patterns, not customer case studies.
Three workflows, three different shapes
Each was built by a different person with different exception handling and permission scoping. Nobody could safely maintain another's work. Codifying one definition pattern and retrofitting the existing three took under two weeks and reduced the fourth workflow's build time substantially.
A workflow nobody owned any more
The builder changed roles and a quarterly reconciliation workflow kept running against a rule that had become outdated. It failed quietly for six weeks. Named ownership with a runbook is the direct control, and it is cheap relative to the reconciliation the incident required.
Portfolio view triggers a retirement
Comparing workflows side by side showed one consuming disproportionate cost and intervention for a low-value outcome that a process change had made largely unnecessary. Retiring it freed capacity, and it had been invisible for months precisely because nothing compared workflows against each other.
Intake replaces the loudest-requester queue
Requests had been served in order of persistence. A defined intake requiring a stated outcome and owner reordered the queue toward two revenue-constraining workflows that had been waiting behind convenience requests, without adding any delivery capacity.
A workflow running ten times more than expected
A summarisation step fired on every record update rather than on state change. Cost attribution surfaced it as an outlier before the quarterly bill did, and the fix was a trigger condition rather than a budget conversation.
A deferred team that became an advocate
A department was told explicitly why its request sat behind two revenue-constraining workflows, with a date for review. It became a supporter rather than a critic. The same decision communicated as silence had previously produced the opposite result with another team.
An early failure that outlived its fix
A workflow failed visibly in its first week and was corrected within days. Eighteen months later the affected team still cited it as a reason to avoid the platform. Recording incidents and their resolutions publicly is the only mechanism that lets a reputation update with the facts.
Estimated spend that was materially wrong
Per-call cost estimates suggested one workflow was the most expensive in the portfolio. Reconciliation against canonical spend truth showed a different workflow was, by a wide margin. A retirement decision based on the estimate would have removed the wrong workflow.
What to do next
Recommended actions.
Action 01
Start with the smallest useful outcome.
Action 02
Keep rollback and export paths explicit.
Action 03
Instrument completion, cycle time, exceptions, and intervention.
Action 04
Expand only after the first workflow remains healthy without recurring manual rescue.
Limitations and evidence standard
What this playbook does not claim.
- Ninety days establishes repeatability, not completeness. Most organisations will still have a small number of production workflows at this point, and presenting the phase as broad transformation overstates it.
- Standardisation has a cost. A defined pattern makes the fourth workflow much faster and the immediate next one slightly slower, and teams that abandon the pattern during that dip usually never recover it.
- Portfolio cost visibility depends on the accuracy of consumption attribution. Estimated figures should be labelled as estimates and reconciled against canonical spend truth before being used for retirement decisions.
- Ownership models require organisational agreement that a technical team cannot grant itself. Where business owners will not be named, that is a real limitation to state rather than a gap to paper over with documentation.
- A constraint review is only as good as the evidence behind it. Without per-workflow measurement in place from the earlier phases, the review reverts to opinion, which is precisely what it exists to replace.
- Cost attribution is only as accurate as the underlying spend data. Estimated per-call figures should be labelled as estimates and reconciled against canonical truth before informing a retirement or expansion decision.
- A visible queue exposes prioritisation to challenge, which is the point and is also uncomfortable. Teams unwilling to defend their ordering in public will tend to revert to an invisible queue, which reliably damages the platform's standing over time.
- Reputation effects lag reality in both directions. A platform that has become reliable will still carry the memory of early failures for some time, and no measurement shortens that period on its own.
FAQ
Questions about 90-Day AI Implementation Playbook.
What distinguishes a repeatable capability from a successful project?
A new workflow can be added by someone who did not build the previous ones, using inherited standards, with governance applied by default and measurement available from day one. If adding a workflow still requires the original builders, it is a project regardless of how many workflows exist.
Why does governance need to become defaults rather than reviews?
Because a single reviewer scales to a handful of workflows and no further. Once decisions are re-derived case by case they diverge, and divergence in permission scoping or human-review boundaries typically becomes visible through an incident rather than through an audit.
What belongs in a portfolio view?
Per workflow: completion against its defined end state, cycle time, human intervention per outcome, exception rate, consumption, and named owner. The purpose is comparison, which is what makes both prioritisation and retirement possible instead of purely additive growth.
How many workflows should be running by day ninety?
Fewer than most plans assume. A small number running reliably, with a documented pattern for adding more, is a stronger position than a dozen fragile ones. The output of this phase is the ability to add workflows predictably, not the count itself.
When should cost attribution be established?
Before consumption is material, which in practice means the third month. Attribution built while the numbers are small is straightforward; built after a surprising bill it becomes an adversarial exercise conducted under pressure, usually with worse data than would have been available earlier.
Why make the prioritisation queue visible?
Because deferred teams accept a stated constraint far more readily than silence. Invisible prioritisation is read as favouritism regardless of how carefully it was reasoned, and the resulting reputational cost limits how much work the implementation is permitted to take on later.
How do you recover from an early visible failure?
Record the incident and its resolution somewhere the affected team can see, and reference it when the concern resurfaces. Reputations do not update on their own, and a fix that was never announced continues to cost the platform credibility long after the defect has gone.
Start with ARIA
Ask ARIA to act on 90-Day AI Implementation Playbook.
Reading it is one thing; running it is another. Tell ARIA the outcome you want from this and it works out which capabilities, systems, and data the work needs — then executes inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Continue
Turn 90-Day AI Implementation Playbook into a working result.
ARIA can take this from framework to running work — building the surface, connecting the systems that stay authoritative, and operating the loop afterwards.