Build
AI Implementation
Targeted automation, integrations, AI assistants and custom applications, built against an approved baseline so the result can be measured.
The buyer problem
Someone in your company has already tried this.
There is a pilot that impressed everybody in the demo and is now used by two people. There is an automation that works beautifully on the clean cases and quietly drops the awkward ones into a folder nobody opens. There is a tool you pay for monthly that solved a problem you no longer have. And there may be an agency that built something clever on top of a process that still has no owner, so when it drifts, nothing catches it.
The pattern underneath all of those is the same. The build was aimed at a task rather than at a workflow, it was measured against nothing, and no human was made accountable for the thing it now runs. Automation without an owner degrades quietly. The queue fills, the exception rate creeps, and the discovery event is a customer complaint.
The second pattern is scope. The demo automates the ninety seconds everyone hates. The money is in the four hours of rework that ninety seconds causes downstream, and nobody scoped that because nobody measured it.
Conditions for fit
This is for you if
- A baseline exists. Ours, from the Operating Diagnostic, or yours if it holds up to inspection -- we will tell you honestly if it does.
- The process has a named owner who will still be there in six months.
- The quantified opportunity clears our 3-to-1 hurdle. A $75,000 build plus $20,000 a month for a year is $315,000, which needs about $945,000 of addressable annual value behind it. At the entry tier it is $100,000 of fees against $300,000 of value.
- The data the automation will act on is fit to act on. Cleaning it is Map work, and it comes first.
- You can accept a staged rollout. Switching everything over on one Monday makes the result unmeasurable and the rollback expensive.
This is not for you if
- What you want is a chatbot on the website by Friday.
- The process is still being redesigned.
- The honest answer is that a form field and a rule would fix it. We would rather tell you that and charge you nothing for it.
We decline work that cannot clear its own benefit hurdle. If the arithmetic on your workflow does not show a return worth the fee, the answer is no, and you get that answer before you spend anything.
The questions we ask first
The diagnostic opens on these, in this order, before anything is proposed. If the answers do not exist, that is itself the finding.
- What does this process do today, and what is the measured baseline we are building against?
- Which step actually holds the money -- the visible one, or the rework it causes?
- What share of volume is an exception, and what does an exception cost?
- Who owns the process after we deploy, and what do they see every morning?
- What must never be automated without a human pressing yes?
- Which system is the authority when two disagree, and who reconciles them today?
- What is the rollback if this goes wrong on a Tuesday afternoon?
- What does the person doing this work think? Have they been asked?
- Which regulations, contracts or client agreements constrain where this data can go?
- How will we know in month six that it is still working?
Deliverables
A build scoped to one or two workflow families
Not to the whole company.
Working automation and integrations
Across the systems that already hold your data, with the failure paths built rather than assumed. Every automation ships with what happens when it fails, not only what happens when it works.
AI assistants and models only where they earn it
A deterministic rule is cheaper, faster and more auditable than a model, and we will use one whenever it will do. Where a model is genuinely the right tool -- classifying free text, summarising a long thread, drafting something a human then approves -- we say what it is doing, what it costs to run, and what it does when it is unsure.
Human approval gates
On payments, payroll, HR decisions, refunds beyond an agreed limit, and any significant customer commitment. We start read-only and earn write access.
Monitoring and alerting
On the workflow, not only on the server. Queue depth, exception rate, throughput and time-in-stage, each with a threshold and a named person who is told when it is crossed.
Documentation and training
For the people who now work alongside the thing: what it does, what it does not do, how to pause it, and who to tell.
A measurement plan agreed before we build
So the argument about whether it worked is settled by evidence rather than by opinion.
Clear rights
Your data is yours. Our shared platform is licensed to you. Reusable non-confidential components stay ours. Ownership of bespoke code is negotiated rather than assumed. Data export is guaranteed and exit assistance is defined and priced up front. We will never make renewal depend on holding your operation hostage.
Implementation steps
- Confirm the baseline
Re-check the measurements before anything is built. If the process changed since the diagnostic, the baseline moves with it and we say so in writing.
- Design the target workflow with the people who run it
Redesign first, automation second. Of the organisational practices McKinsey surveyed in March 2025, redesigning workflows showed the strongest association with reported EBIT impact from generative AI. That is a self-reported association from a survey, not proof of cause, and not a study of the American middle market -- but it is the order we work in regardless.
- Pick the smallest thing that moves the number
Build that first. A narrow piece running in production teaches more than a broad piece in a demo.
- Build, with the exceptions in scope
The awkward cases are the work. If they are out of scope, the automation moves the cost rather than removing it.
- Test against real history
Replay the automation over past cases, including the ones that went wrong, and compare what it would have done to what happened.
- Roll out in stages
A share of volume, or one team, or one region, with the rest running as the comparison. Staged rollout is the only cheap way to make the result attributable.
- Hand over ownership
The named owner gets a view, a threshold, an alert and an escalation path before we consider it deployed.
- Measure, then report
First benefits report at the end of the first full period, in the four separate buckets.
Example measures
Examples of what gets instrumented. Each row is a definition: what gets counted, the unit and the period it is counted over, and the system that holds the authoritative figure. A number without those three is not a measure. The figures come from your baseline, measured on your data.
| Measure | Unit and period | Authoritative source |
|---|---|---|
| Cycle time before and after | Median and 90th percentile, on matched case types | Status-transition timestamps, same definition as the baseline |
| Share of volume handled end to end without a human touch, and the share correctly escalated | Percent of volume | Execution and escalation events emitted by the workflow |
| Exception rate, and whether exceptions fell or simply moved | Share of volume, before and after | Exception events, classified against the specification |
| Rework hours removed | Hours, per period | Rework transitions against the baseline |
| First-response time on inbound and the share breaching target | Median; percent breaching | Inbound timestamp to first outbound on the same case |
| Error rate on the automated step against the human baseline | Percent of cases, per cohort | Quality sampling against the baseline. Sometimes it is worse, and that is a finding we report rather than bury. |
| Running cost of the automation, including third-party consumption, subtracted from benefit | Dollars, per month | Vendor usage records, reconciled to the invoice |
| Days sales outstanding attributable to process delay | Days | Billing platform against the ledger |
| Adoption: are people using it, or working around it? | Share of cases handled in the workflow versus around it | Execution events against case volume. A workaround is a design defect, not a training problem. |
Dependencies
What has to be true on your side. If one of these is missing, the engagement stalls and we will say so before it starts.
- A named process owner with the authority to change how the work is done.
- System access with the right permissions, including a non-production environment where one exists.
- Someone technical on your side for a few hours a week, even if it is your MSP. We will work with them rather than around them.
- A decision on the approval gates -- which actions a machine may take alone, and which it may not.
- Your legal and compliance view on where data may go and what may be processed, early rather than at go-live.
- Willingness to change the process, not only to automate it. If the redesign is off the table, most of the value is too.
- Third-party consumption costs. Model, API and platform usage is yours and is specified in the agreement with overage terms.
Limitations
What this work does not do. On the page, not in a footnote.
- It will not deliver a number we can promise in advance. We guarantee a measured baseline and a benefit calculation your CFO can audit. Anyone guaranteeing a result before a baseline exists is guessing, and you should treat that the same way we do.
- Attribution has limits and we state them. When your numbers improve, other things changed too. We normalise the obvious confounders, use staged rollout where feasible, and write down what remains uncertain. A before-and-after comparison on its own does not establish cause.
- Capacity released is reported as hours. It becomes a dollar saving only when a role was actually eliminated or a hire was actually avoided -- your decision, recorded, not ours to assume.
- We use the NIST AI Risk Management Framework as a governance reference. That is not certification, by NIST or anyone else. The security controls we describe to you are the ones we run.
- Model behaviour is not fully predictable, and retention and processing terms are set by the vendors whose models are used. We will tell you which vendor, what their published retention terms are, and what we have configured. We will not promise zero retention for data we do not control.
The engagement path
- Implementation follows a baseline. If you have one that holds up, bring it and we will scope directly.
- If you do not, the Operating Diagnostic is $12,500 over three weeks and comes off the implementation price in full.
- Foundation and Deployment runs $75,000 to $150,000 over 8 to 16 weeks.
- A single workflow at the entry tier is $25,000 to $40,000.