First choose the problemyou keep carrying.Then the technology.
Five steps, in this order, every time. The order is the method: almost every system like this that fails was built before anybody agreed what it was for, and almost every one that works had its thresholds argued over by the person who owns that part of the business.
- Steps
- Five, in a fixed order, on every build
- First system live
- Thirty days, for one system, from the call
- At launch
- Supervised, with you approving what goes out
- Built inside
- The platform you already run, not a replacement for it
Choose, design, build,prove, improve.
What we need from you at each step is on the right, because the most common reason a build like this stalls is that nobody agreed who was producing what.
Choose
Name the thing that keeps costing money. Then look at the tools.
We pick the one moment in your operation where work reliably stops moving, and we check what is actually there: the platform you run, who owns which step today, the boundaries you cannot cross, and the baseline we will measure against later. The order matters. A tool chosen before a problem is a tool you will be talked out of in six months.
- What we need from you
- An honest hour, access to look, and the number you would want moved.
- What you get back
- The problem named in one sentence, and a straight answer on whether it is worth building yet.
Design
Every wait, threshold and branch, agreed with you in writing.
The operating logic gets written down before anything is built: what triggers it, how it classifies, where it branches, what the escalation windows are, who is named at each level, and what happens when nobody responds. Anything consequential is signed off by the person who owns that part of the business, not by us.
- What we need from you
- Decisions on the thresholds, the wording, and who is named where.
- What you get back
- The full logic written out, in your language and against your stages.
Build
Inside the software you already run.
It gets built in your platform rather than beside it. Where a system needs a record your platform does not hold, we add the field to your platform instead of starting a second system your team then has to remember. Existing tools stay when they can carry the path.
- What we need from you
- Access, and a person who can answer a question in a day rather than a week.
- What you get back
- The build, the integrations, the exception logic, and the measurement wired in from the start.
Prove
It runs with a person approving what goes out.
Nothing sends unreviewed on day one. The system runs in supervised mode, with a named person on your side approving each outbound message until you are happy with the tone, and only then does it run on its own. On some systems the first fortnight is worked by hand deliberately, because a backlog is the fastest way to find out whether the logic is right.
- What we need from you
- Somebody to review the first messages, and a straight opinion on the tone.
- What you get back
- The review queue, the corrections, and the sign-off before anything runs unattended.
Improve
Read the exceptions, then decide whether to build the next one.
We look at what the system escalated, what nobody picked up, and whether the measure we agreed at the start actually moved. That conversation decides whether there is a second system worth building. Sometimes the answer is no, and that is a legitimate outcome of this step.
- What we need from you
- Thirty minutes on the numbers, and the truth about what your team ignored.
- What you get back
- The exception review, and a recommendation you are free to decline.
The sequence rule
The first build has to be measurable, safe to operate, and valuable enough on its own to justify the change. If the first one we can find does not clear all three, we say so on the call rather than starting anyway.
Whatthirty daysactually means.
It is a common enough claim in this category that it has stopped meaning anything, so here is exactly what it covers and what it does not.
What the 30 days covers
One system, from the call to it running live in your platform. Not seven, and not a platform migration. The 30 days is a scope commitment as much as a schedule.
What it does not cover
Replacing a CRM, cleaning years of bad data, or anything that depends on a decision only you can make. If scoping finds one of those, we say so before the clock starts rather than after.
What happens on day 31
Usually nothing, deliberately. The system runs, you watch it for a while, and the next one gets built only once this one has moved the measure we agreed. Most firms do not need seven systems.
This is what it lookslike on a real build.
Seventy pages on this site publish the delivery playbook for one system in one trade: the steps, the branches, the escalation windows, the stop rules, and the phase where it still runs with a person approving each message. That is this method, applied.
Pick a trade and read one end to end before you speak to anybody here.
Step one isa conversation.
On the call we do the first step properly: name the thing that keeps costing you money, check what is already there, and work out whether the first system is worth building at all.