How an engagement runs
Five phases over roughly ten weeks, then an ongoing operating period. Each phase has a written exit condition, and we do not start the next one until it is met. The first phase can end the engagement — if the workflow does not cost you enough to justify fixing, we say so and stop.
Publishing this is deliberate. You can run most of it yourself, and if you do, that was a good outcome.
Phase 1 — Watch (weeks 1–2)
On site, with the people who do the work. Not the people who describe the work — the difference between those two is usually where the money is.
What happens: we sit with the team, time the steps, follow a job end to end, and read the systems. We ask everyone the same question — “what’s the part of this that makes you want to quit?” — because frustration is a reliable indicator of unmeasured cost.
What we need from you: access to the people, access to the systems, and one senior person who can say out loud that the process is allowed to change.
Exit condition: we can draw the actual workflow on one page and the team agrees that is what really happens.
Phase 2 — Measure (weeks 3–4)
One number: what this workflow costs you a year. Built from observation and your own payroll and system data, never from an estimate in a meeting — including your estimate. Owners routinely guess low by a factor of two on labour and miss leakage entirely.
Three lines:
A. LABOUR people × hours/week × loaded hourly rate × 52
(loaded = salary × ~1.3 for burden — get it from your controller)
B. REWORK incidents/month × hours to fix × loaded rate × 12
C. LEAKAGE quotes lost to slow response, jobs mis-priced, missed follow-ups,
overtime absorbing a peak, penalties, write-offs
Then, conservatively, how much of that number is realistically removable — and that percentage goes in the scope document, because it becomes the thing both sides are judged on later. A number chosen to justify a price is worthless to everyone including us.
Exit condition: you have the number, you believe it, and you would defend it to your CFO.
This is where an engagement can honestly end. If A + B + C is small, the right advice is to buy a tool or leave it alone. You keep the measurement either way — it is yours, and it is useful.
Phase 3 — Build (weeks 5–8)
Into your stack, on your accounts. Your CRM, your ERP, your scheduler, your phone system. Not our platform, not our tenant, not our API keys.
What gets built varies. What is constant:
- It handles the exceptions, because the exceptions are the workflow. A system that works for the clean 80% and dumps the rest on a human has moved the bottleneck, not removed it.
- It fails visibly. Silent failure is worse than no automation — people trust it, it stops, and nobody notices for a fortnight.
- It is documented as it is built, not written up afterwards from memory.
What we need from you: one person from the team who will actually use it, available for about two hours a week. Not a steering committee. One operator.
Exit condition: it runs the real workflow on real data, including the ugly cases.
Phase 4 — Deploy (weeks 9–10)
Standing next to people while they use it for real. This is the phase most vendors have already invoiced past.
Expect the first week to surface things nobody predicted. That is not a failure of the build — it is the first honest contact with production, and it is why we are still in the building for it.
What we need from you: permission to change the process, not just the software. Almost every deployment turns up one step that should stop existing rather than be automated.
Exit condition: the team is doing the work through the new system, unassisted, for a full cycle.
Phase 5 — Run (ongoing)
The six weeks after launch decide whether any of this was worth it.
A system does not usually fail loudly. It gets quietly worked around — someone hits an edge case, goes back to the old way for that one job, tells a colleague, and eight weeks later everybody is back on the spreadsheet and the dashboard still shows green.
So the operating period is about usage, not uptime: watching what people actually do, fixing what makes them avoid it, and handling the seasonal cases that were not visible in week one.
Handover is a real event, not a drift. Documentation, training, credentials in your names, and a written statement of what breaks it. The test we build to: if we stopped answering the phone tomorrow, does this keep running?
What we need from you, in total
Honestly short, and this list is the whole thing:
- Access to the people who do the work and the systems they do it in.
- One senior person who can authorise a change to how the work is done.
- One operator, roughly two hours a week from week five.
- Real numbers — payroll, job records, whatever the measurement needs.
- Tolerance for a hard answer in week four, including “this is not worth fixing.”
What we will not do
- Run a pilot designed to justify a bigger phase.
- Build on our platform so that leaving us is expensive.
- Present a number we did not measure.
- Take a third concurrent engagement. Hard cap of two. Embedded work stops being embedded when it is spread thin, and capacity is the constraint that keeps the work good.
What it costs, and how the number is arrived at → · Start with the measurement →
What it costs · Who we work with · What is a forward deployed engineer?
Get in touch
Email solutions@ikonic303.dev to start with the measurement. ikonic303 is based in Colorado and works with clients nationwide.