Workflow automation that doesn't break in 6 months

This session covers why automated processes decay, and the design choices that keep them running after the team that built them has moved on. Below is a written summary of the material so you can read it now rather than book a slot — the recording is available on request from our team.

Why processes break

Automation rarely fails technically. It fails because the organization it was modelled on changed and the process didn't. Four causes cover most cases:

• Hard-coded people. A process routes to a named user; that user changes role and the queue silently stalls.
• Hard-coded structure. Approval logic encodes the current org chart, which is the least stable thing in a business.
• No exception path. Real work has exceptions; if the process has no legitimate way to handle one, users route around it entirely.
• No owner. Nobody is responsible for the process after go-live, so drift accumulates unnoticed until something visible breaks.

Design principle 1: route to roles, never to people

Every assignment should resolve through a role, team, or rule — 'the account owner's manager', 'the regional finance approver' — so that personnel change becomes a data update rather than a process redeployment.

Design principle 2: put thresholds in configuration

Discount limits, SLA hours, and escalation windows change often and change without warning. They belong in a lookup a business owner can edit, not inside a process diagram that requires a deployment.

Design principle 3: model the exception explicitly

Give every process a documented override path with a reason code and an audit trail. Counter-intuitively, a sanctioned exception route increases compliance: people use the system to do the unusual thing instead of leaving it.

Design principle 4: keep processes small and composed

One enormous diagram that handles the whole order-to-cash lifecycle is unmaintainable. Break it into small sub-processes with clear inputs and outputs, so a change to invoicing doesn't require re-testing qualification.

Design principle 5: instrument from day one

Log every start, completion, and failure. A process you cannot observe is a process you cannot maintain. A weekly view of volumes, average cycle time, and error counts per process makes decay visible while it is still cheap to fix.

The maintenance rhythm

1. 1Monthly: review error and stall counts; fix anything trending upward.
2. 2Quarterly: sit with the process owner and confirm the process still matches how work is done.
3. 3Twice yearly: retire processes with near-zero volume. Dead automation is a liability, not an asset.
4. 4On every org change: re-check role mappings and approval chains before the change takes effect.

Questions from the session

Should we automate a broken process?

No — but don't use that as an excuse for a year of redesign either. Fix the obvious dysfunction, automate the stable core, and iterate. Perfect process design before automation is a stalling tactic.

How much should we automate at go-live?

Enough to make the system visibly faster than what it replaced, and no more. Additional automation lands far better once users trust the platform.

Who should own processes long term?

A named business owner per process, supported by an administrator. Ownership sitting solely in IT is the most reliable predictor of process decay we see.

Automation is not a project deliverable. It is an asset with a maintenance schedule.