Skip to content

The method, in full, before you buy any of it

Most agency process pages are four verbs and a diagram. This one carries timelines, a list of what we need from you, the risks we can already name, and the sentence most of this industry will not write: what happens when the test fails.

SIX PHASES QUOTED, NOT PRICED ENGLISH AND SPANISH

  1. 01 SCOPE30 MIN
  2. 02 AUDIT2 TO 3 WKS
  3. 03 PROOF30 DAYS
  4. 04 BUILD4 TO 10 WKS
  5. 05 HANDOVER30 DAYS
  6. 06 RUNNINGMONTHLY

Why this is published

The research on AI adoption keeps landing in the same place. MIT's NANDA work put the share of generative AI pilots producing no measurable return at roughly 95%. RAND's interview research found the failures are organisational rather than technical: the thing got built and nobody changed how they worked. Projects die quietly about three months after launch.

So the method below is built around adoption rather than around the build. Training is a deliverable, not an upsell. The pass or fail test is written down before build money is spent. Every paid step has an exit, and each exit is described here instead of discovered later.

We also publish it so you can read it without talking to us. If you get to the end and decide to do this yourself, or with someone else, the page has done its job.

Industrial infrastructure receding into shadow, hard edges against a pale sky
FIG. 006 Systems that keep running

The six phases

01 SCOPE CALL 30 MINUTES NO FEE

  1. 01 SCOPE 30 MIN
  2. 02 AUDIT 2 TO 3 WKS
  3. 03 PROOF 30 DAYS
  4. 04 BUILD 4 TO 10 WKS
  5. 05 HANDOVER 30 DAYS
  6. 06 RUNNING MONTHLY

  1. Scope call

    We ask what the process is, who runs it, how often it happens, in which language, and what you have already tried. You ask whatever you want. Thirty minutes, with the people who would do the work.

    You leave with a straight answer on whether this is worth doing and which family it sits in: a growth system that brings customers in, or an operations system that takes work off the desk.

    Half an hour, and you leave with the answer either way.

    02 AI VISIBILITY AUDIT TWO TO THREE WEEKS PAID

  2. AI Visibility Audit

    Optional, and most people should take it. Skip it if you already know exactly what you want built.

    • Where you stand in search and in AI answers. What ChatGPT, Perplexity and Google's AI Overviews say about your business when a customer asks.
    • The competitor gap against your three closest rivals.
    • A pass over your operations for the highest value automation opportunities, so the audit serves both families rather than only the marketing side.
    • The three best opportunities scoped with effort, cost and expected outcome, in a format you can take to any supplier, including one that is not us.
    • A 90 day roadmap.
    • A recorded walkthrough in your language, yours to keep and to forward to whoever missed the call.

    The fee is quoted after the scope call, never before. It is credited in full against a Custom AI Build or against either growth setup fee, on any statement of work signed within 90 days of the day the walkthrough is delivered. It is not credited against the operations pilot, because the pilot is a separate decision and delivers its own answer.

    03 PROOF STEP BRANCHES BY FAMILY

  3. The proof step

    Here the two families separate. This step exists because the research says most of what follows it fails.

    Growth systems open with a 30 Day Proof Month. Defined output, and a pass or fail test signed before the month starts. At the end you either start the term or stop with nothing owed, and you keep what was made: the brand voice profile, or the customer profile and the prospect file. There is no notice to serve and no term to buy out, because the term has not started.

    Operations systems open with a scoped paid pilot on one workflow. Two to four weeks. The same kind of test, written down and signed before any build money is spent. The pilot fee is separate and is not credited, because the pilot delivers a real answer either way, and an answer of "do not build this" costs us the same to produce as an answer of "build it".

    04 BUILD FOUR TO TEN WEEKS

  4. Build

    • Process mapping with the people who do the work, not only with the person who signed. This is the phase where the real problem surfaces.
    • Build and integration with the tools you already run.
    • Fixed scope and a fixed fee. Never open ended time and materials.
    • If the scope changes, we requote before we build, not after.

    Four to ten weeks, depending on what was scoped in 03. Growth systems move from the proof month straight into the monthly rhythm in 06 instead.

    05 HANDOVER AND TRAINING 30 DAYS OF SUPPORT

  5. Handover and training

    • Training for the people who have to use it, in their language, built on their own work rather than on generic demos.
    • A written handover at go live, delivered by default and not on request, so you do not depend on us to understand your own system.
    • Thirty days of adoption support after go live.

    This phase is not a formality. It is the one the research says decides whether the previous four mattered.

    06 RUNNING IT MONTHLY

  6. Running it

    A monthly report in plain language: what ran, what it produced, what changed, and what we would change next. Written in the language you work in. The report is the whole interface: reading it is all it takes to know whether you are getting value.

    Custom builds carry an optional care plan, so support is funded rather than absorbed and slowly starved. You can stop. Everything written down in 05 stays yours.

What we need from you

This is the half of the method most process pages leave out, and it is the half that decides the timeline.

  1. One named decision maker who can say yes without assembling a committee.
  2. Access to the people who do the work. Process mapping without them produces a map of what management believes happens.
  3. The material we are working from. Existing content, brand assets and how you talk, for a growth system. Logins and a walkthrough of the tools, for an operations build.
  4. A named reviewer who will read what we send, in the language it ships in. Bilingual output that nobody checks is worse than output in one language.
  5. A straight account of what has already been tried and what failed. It saves weeks, and nobody is going to be judged for it.

If access slips, the timeline slips. We put that in the weekly note rather than absorbing it in silence and arriving late with an explanation.

READ

The risks, named now rather than later

  • Nobody uses it

    The most likely way this fails, by a distance. The build works and nobody opens it.

    Our answer: training and thirty days of adoption support sit inside the scope, the process map is built with the people who will use the system, and the interface is designed rather than inherited from whatever the tooling produced by default.

  • The process is the problem, not the software

    Sometimes the right answer after mapping is to reorganise how the work is done and automate less of it than you expected. We will say that even when it is the smaller invoice, because the alternative is billing you to make a bad process faster.

  • The data is messier than anyone thinks

    A system inherits the mess you point it at. Records that disagree, three spellings of the same customer, a spreadsheet that turns out to be the real system of record. We look for this in the audit and again in the pilot, which is part of what the pilot is for.

  • Two languages doubles the review, not the production

    Producing bilingual output is cheap. Checking that both versions say the same thing, in language a native speaker would use, is not. That cost lands on the review gate, and it sits inside the scope rather than surfacing in month two.

  • The calendar

    Your diary is half of the timeline. Two working sessions that take three weeks to arrange move everything behind them by three weeks.

What happens if it does not work

Every paid step has a test written down before that step starts, and the test is written in your terms rather than ours.

If a 30 Day Proof Month misses its test, the term does not start. You stop with nothing owed and you keep the brand voice profile, or the customer profile and the prospect file, depending on which system it was. Those were built for you and they work without us.

If an operations pilot fails its test, no build follows. The pilot fee stands, because the pilot bought the answer and the answer arrived. We will tell you what we would do instead, and that list sometimes ends in doing nothing for now.

If a build goes live and nobody uses it, that is on us, and phase 05 exists to prevent it. The thirty days of adoption support is the mechanism. If it is still unused at the end of them, we would rather have that conversation than sell a care plan on a system nobody opens.

A TEST AGREED IN ADVANCE NOT A GUARANTEE

What we sign is a test, not a guarantee: agreed in advance, on the part we control, covering what gets delivered, by when, in which languages, and who signs it off. It commits us to specific work rather than to a percentage of your revenue, your traffic or your leads. Your market has no baseline to promise a number against, and inventing one is the documented way agencies lose a client in month four.

How you will know what is happening

One report a month, in plain language, in your language. Four things:

  1. What ran.
  2. What it produced, counted.
  3. What changed since last month.
  4. What we would change next, and why.

Every claim in it traces to something you can look at. If a line cannot be traced to a source, it does not go in the report.

Four things we do, every time

  1. We put our name to the work delivered, the compliance around it and the test we signed. That is the part we control, so that is the part we commit to.
  2. We scope, then we price. Every figure we give is a real figure for your business, not a band you have to guess your way into.
  3. We publish what we can show you the source of, which is why this site carries one case study in full, counts and all.
  4. We write the pass or fail test down and sign it before a build starts.

Where this starts

Tell us the process and who runs it. We take it from there.

Book a call

If you would rather write first, the contact page carries a short form. We reply in the language you write in.

Read next