Design the operating model before you automate the workflow.

Reframe

Automation is the late step, not the first one.

A workflow can be technically elegant and still make work harder. The usual cause is not the platform. It is an unresolved operating question that has been encoded as a routing rule: who owns the request, who can make the decision, and what happens when the standard path does not fit?

Teams often begin with the visible process because it is easy to diagram. The more valuable starting point is the agreement underneath it. That agreement defines the service boundary, the roles that carry accountability and the evidence that proves the work reached a useful outcome.

Before build

Five questions to answer before Flow Designer opens.

A short operating-model workshop can remove weeks of later rework. The output does not need to be a large governance pack. It needs to be a set of decisions that a product owner, process owner and implementation team can all use.

• What outcome is the requester actually buying from this service?
• Which team owns the request from acknowledgement to closure?
• Where can the standard path stop, and who owns each exception?
• Which system remains authoritative for the record at each boundary?
• What baseline will show whether the change improved the service?

The artefact

Create a minimum operating record.

For each workflow, keep one compact record containing the service promise, entry conditions, ownership map, exception paths, data boundaries and measures. That record becomes the bridge between discovery, configuration, acceptance and ongoing improvement.

This is also how teams avoid a familiar failure: a successful go-live followed by slow drift. When the operating intent is explicit, changes can be tested against the reason the workflow exists rather than against configuration history alone.

Evidence

Measure behaviour after release, not only delivery at release.

Deployment measures tell you whether the project shipped. Operating measures tell you whether work improved. Look for avoidable reassignment, ageing at decision points, reopened requests, exception volume and the distance between reported completion and the requester’s actual outcome.

The platform makes those signals available. The operating model gives them meaning — and gives someone the responsibility to act when the signal changes.