Most automation projects do not fail in the build. They fail after the demo, when nobody owns the workflow, the edge cases arrive and the model changes. This is the method we use to prevent that, step by step, with what you receive at each stage.
The method
Ten steps, in the order they happen
- Discover. We watch the process as it really happens, not as the org chart describes it. Who receives the input, what they check, where it waits, what goes wrong. We count volume, hours, errors and response time for two to four weeks of real data and write them into a baseline sheet.
- Prioritise. Every candidate workflow is scored on frequency, time, rule clarity, exception rate, business value and risk. The one with the best ratio of value to risk goes first. In a pilot this is a single decision; in Team or Business scope it becomes an impact/effort matrix.
- Design. We define inputs, outputs, every branch, the approval points, the fallback when a system or model fails and who owns the workflow afterwards. The result is a one-page scope card with written acceptance criteria: the test cases that must pass before you pay the final instalment.
- Build. Built on the simplest platform that is reliable for your volume and data rules, inside accounts you own. Secrets go in a vault, not in workflow notes. Development and production use separate credentials from the first day.
- Test. Normal cases, edge cases, failure cases (API down, empty field, duplicate input), privacy cases (personal data where it should not be) and adversarial cases (a customer trying to talk the assistant into a refund). AI steps get a labelled test set and a confidence threshold.
- User acceptance. You run the workflow yourself on a staging demo with realistic data and tick off the acceptance criteria. Anything that fails is fixed before launch, not after.
- Launch. Gradual rollout: a subset of inputs first, then everything. Monitoring, cost caps and a kill switch are live before the first real run. Someone on your side knows how to stop it in under a minute.
- Train and document. A recorded handover session, a runbook (what it does, what to do when it alerts, how to change a template) and an ownership map naming who on your team is responsible for what. You could hand all of it to another provider tomorrow.
- Measure. At 30, 60 and 90 days we compare time, speed, error and cost metrics against the baseline sheet from step one. The same numbers, the same method, so the comparison is honest.
- Improve. Expand only once the first workflow has proved useful. Adjust thresholds, remove a step that nobody uses, add the next workflow from the priority list. Under a care plan this is a standing monthly review.
Deliverables
What you hold in your hands at each stage
| Stage | Deliverable | Why it matters |
|---|---|---|
| Discover | Baseline sheet | Volume, hours, errors and response time before anything changes. Without it, “it feels faster” is all you will ever have. |
| Design | Scope card and acceptance criteria | One page that says what is in, what is out, where humans approve and which tests define “done”. |
| Build and test | Test log | Which scenarios were run, what failed, what was fixed. AI steps include the test set and threshold used. |
| User acceptance | Staging demo and sign-off | You have used it with your data before it touches production. |
| Launch | Monitoring view, cost caps, kill switch | You can see runs and errors and stop the workflow without calling us. |
| Train and document | Runbook, recorded handover, ownership map | Your team can operate, change and if necessary migrate the workflow without us. |
| Measure | 30/60/90-day comparison | The baseline metrics measured again, the same way, with the differences and the caveats. |
Timelines by package
| Package | Delivery | Support window |
|---|---|---|
| One Workflow Pilot | 10–15 business days | 14 days |
| Solo | 2–3 weeks | 30 days |
| Team | 3–6 weeks | 45 days |
| Business | 6–12 weeks | 60 days |
| Enterprise | 10–24+ weeks, staged | Agreed in the SOW |
Timelines assume prompt access to systems and a decision-maker who can answer questions within a business day. The most common delay is waiting for an API key. See pricing for what each package includes.
Who does what
| Role | Responsibility |
|---|---|
| Your process owner | Explains how the work really happens, answers edge-case questions, signs off acceptance |
| Your admin or IT contact | Creates accounts, grants least-privilege access, approves connectors |
| Azikiel lead | Discovery, design, scope card, build, testing, handover, measurement |
| Your workflow owner (after launch) | Watches alerts, approves queued items, requests changes |
| Your legal or data-protection adviser | Reviews the points we flag for sensitive data or regulated decisions |
In a small company, the process owner, admin and workflow owner are often the same person. That is fine, as long as it is written down.
Lessons
Why projects fail after the demo
The demo works because it uses clean data, one happy path and the person who built it at the keyboard. Production has none of those.
- No baseline. Nobody measured before, so nobody can prove it helped, so nobody defends it when it needs attention.
- No owner. The workflow alerts, the alert goes to a shared inbox, and the exception queue quietly grows for three weeks.
- Untested edge cases. The one supplier who sends invoices as photographs, the customer who writes in two languages, the empty field.
- Model changes. A vendor updates the model; the classification that was 96% accurate drifts, and nobody has a test set to notice.
- Agency-owned accounts. The provider leaves, the subscription lapses and the workflow stops with it.
- No kill switch. Something goes wrong at 17:45 on a Friday and the only person who can stop it is on a train.
Each of these has a step above that exists to prevent it. The controls behind them are described on the security and governance page.
Want to see the method applied to a specific process? The example workflows show the trigger, steps, human checkpoint and measurements for each one.