Skip to main content

How we decide

Most of what you're about to automate shouldn't be

Anyone can build what you ask for. The useful part is knowing what not to build, which of your tools already does the job, and where AI has no business being.

That judgement is not a methodology. It comes from having sat on both sides: having carried a revenue number, and having built the systems underneath one. A firm that only knows the commercial side cannot tell you what is cheap to build. A firm that only knows the technical side cannot tell you what is worth building.

Delete it

Use what you pay for

Connect what you have

Build something new

§1Two words we use, defined before we use them

What it will and won't do.

Every system we build has conditions under which it refuses to act. That is designed, not accidental.

What happens when it goes wrong.

Where the odd case goes, and who gets told.

§2The four responses

Every request gets checked against these, in this order.

  1. Delete it

    A quote takes two days because it needs an approval, and the only thing being checked is whether the discount is under twenty percent. Actual decision time: ninety seconds. That is a rule, not a judgement, and the approval step should not exist. Automating it would have made a pointless step permanent, and a permanent one never gets challenged.

  2. Use what you already pay for

    A three-hour Monday report reconciling a spreadsheet against HubSpot. The spreadsheet predates a field that now holds the same number. Switching the field on and retiring the spreadsheet takes an afternoon and no build at all.

    Sometimes the honest answer is a subscription. If the category has solved this and a tool does it well, buy the tool.

  3. Connect what you have

    A prospect replies to a human in a shared inbox. Instantly never hears, and keeps sending for two more weeks. Nothing new needs building. Two things you already own need to talk to each other, with a rule that holds the send.

    Sometimes the honest answer is your own team. If you have the people and the clarity, keep it in-house. Design exists for exactly that.

  4. Build something new

    Only when the first three genuinely do not answer it. Then we build it properly, with the limits, the failure path and the owner designed in from the start.

Fig. 1One queued send, one question, two exits. The held branch names a person.
QUEUEDA follow-upDID THEDEALCHANGE?NOIt sendsYESIt stopsThe owner is told what changed

Scroll the diagram

Fig. 2The same four responses, in order. Three of them stop before the boundary.
ONE REQUEST1Delete itNO BUILD2Use what you already pay forNO BUILD3Connect what you haveSMALL BUILD4Build something newBUILDTHREE OF FOUR STOP BEFORE HERE

Scroll the diagram

Three of those four end without a build. We check them first, because the most expensive thing we could sell you is something that shouldn't exist

§3And inside each

How much AI, if any.

AI is not a fifth step. It is a question asked inside every one of the four, and the answer is often none.

Where an agent earns its place

Drafting a proposal from a call transcript, reading forty past ads to draft against what worked, pulling structure out of unstructured input that rules cannot parse.

Where it does not belong

Deciding whether to hold a sequence. “Has this deal changed since we enrolled it?” is a comparison. A comparison is faster, cheaper and predictable, and when it is wrong you can see why. Never ask a model to make a decision a comparison can make.

We'll tell you where AI doesn't belong

This is also why “add AI” is not a brief. Every tool revenue teams were given before this one made the work faster. This is the first that can do the work, which is exactly why it matters what it can see. An agent put on top of context that never arrived produces confident, wrong output at scale, which is worse than the manual process it replaced.

§4The guard

Anyone can build the happy path. The engineering is in the stop.

A sequence that holds when the deal changed. A draft that flags low confidence instead of guessing. A write-back that preserves the previous state when it fails. This is the difference between an automation people trust and one they quietly work around after it has been wrong twice.

How you know it's still right

A system that worked at launch is not the same as a system that works. Anything with an AI step gets a set of known cases it is checked against on a schedule, so degradation is caught while it is small rather than when a customer notices. If you want us to keep doing that, that is Keep it running.

The three guards we build most

  • A sequence that holds when the deal changed since enrolment

  • A draft that flags itself when confidence is low, instead of guessing

  • A write-back that reverts to the previous state when it fails

§5When the answer is no

Some of the most useful conversations end without a project.

Buy a tool.

See response 2.

Do it internally.

See response 3.

Hire a person.

If the work is genuinely different every time, or it needs someone in the room building relationships, that is a hire and no system replaces it.

Wait.

Pre-product-market-fit, systematising this locks in an answer you have not found yet.

Do nothing.

If the cost of the problem is smaller than the cost of the fix, that is the correct decision.

§6What we need from you

Four things, on every engagement.

And we will ask for them early rather than politely.

Every engagement

  • Get us to the people who actually do the work, and into the systems, when we ask. Not eventually. Most delays on projects like this are access delays.
  • You make the commercial, legal and privacy calls. We will tell you when one is needed and what turns on it. We will not make it for you.
  • You confirm the rules are right. We can build exactly what you describe. We cannot know whether your business has been described correctly.
  • Someone on your side runs it afterwards. We name that person at the start, not at handover, and they are involved before it goes live.

§7Handover

Handed over is not the same as finished.

Something you own still needs somebody who understands it.

So the person who will run it does not meet it on the last day. They are in the room while it is built, and by the time we leave they can say what it does, what it refuses to do, what the odd case looks like, and who to call when it does something surprising.

The accounts, the data, the configuration and the write-up are yours. Nothing is hosted somewhere you cannot reach, and nothing depends on us being reachable. If you would rather we kept an eye on it, that is Keep it running. If not, you are not tied to us.