Stability is a selection criterion
We ask how long the process has worked the way it works now. If the answer is less than six months, or if two departments are still arguing about it, we will recommend waiting.
Automating a moving target does not settle the argument. It encodes one side of it in software and makes changing your mind expensive.
Configurable rather than coded
- Thresholds, tolerances and limits editable by your team, not by us
- Business rules in configuration where the rule is likely to move
- Routing and approval chains changeable without a deployment
- New product types, categories or sites added without code
The test we apply: which of these will you plausibly want to change in the next two years? Those go in configuration. Everything else can be code, which is simpler and cheaper.
What a change actually costs
| Type of change | Typical effort |
|---|---|
| Adjusting a threshold or rule value | Minutes, by you |
| Adding a category, site or product type | Minutes to hours, by you |
| New field captured and carried through | 1–3 days |
| New intake channel | 1–3 weeks |
| Different decision logic in the core path | 2–6 weeks |
The annual review
We ask, once a year: does this still reflect how you work, is the output still used, what exceptions are being handled manually that could now be automated, and should this still exist at all.
We have recommended switching things off. An automation that no longer matches the business still costs maintenance and still occasionally fails.
The parts we deliberately leave manual
Anything still being argued about, anything with fewer than a handful of instances a week, and anything where the rule genuinely depends on judgement that varies case by case.
Leaving those alone is not incompleteness. It is what keeps the automated part stable enough to trust.