A technology shortlist is a poor place to start an operational change. It tells you what a tool can do, but not which work should change, who can authorise that change or how you will know it has helped. A faster task can still feed a slower queue. A new interface can still leave people reconciling two conflicting records.
Start by describing the operation you want to improve. That means following work across team and system boundaries, including the parts that happen in email, spreadsheets and conversations. The result should be specific enough to guide decisions about technology, rather than a process diagram that everyone recognises but nobody can use.
Follow a piece of work from arrival to completion
Choose a clear starting event and a clear end state. What arrives, what has to be achieved and who receives the result? Trace how a piece of work moves between those points with the people who actually handle it. Record the handovers, waiting time, repeated entry and checks as well as the main processing steps.
Look at several paths through the operation. The straightforward path explains the intended sequence; delayed, incomplete and returned work reveals the conditions the design must handle. Ask what allows each step to begin, what proves it is complete and where responsibility moves next. A handover is unfinished if the sending team thinks it has passed the work on but nobody owns the next action.
Identify the information each decision needs
At each step, distinguish the information received from the information needed. Establish where the authoritative record lives, who can change it and how other systems learn about that change. Two screens showing the same field do not necessarily share the same meaning, freshness or ownership.
Missing, contradictory and late information needs an explicit route. Decide when work should wait, when someone should request clarification and when an authorised person can proceed with a recorded qualification. Automating the movement of incomplete information does not resolve the uncertainty behind it.
Separate a decision from permission to act
Write down the decisions that move the work forward. Which follow a stated policy? Which require interpretation? Which commit money, change a customer record or create an obligation? Record the evidence required and the person or role accountable for the outcome.
A system may be able to suggest the next action without being allowed to take it. Set authority separately: what it may do, within which limits, and when approval is required. Human review also needs a usable design. The reviewer should see the relevant evidence, the proposed action and a clear way to approve, amend or reject it.
Design the exceptions before choosing the mechanism
Exceptions are part of the operation. A request can arrive twice, a dependency can be unavailable, an approval can expire or a record can change while someone is reviewing it. Decide how work is held, who is alerted and what makes it safe to resume.
Recovery deserves the same attention as the normal route. If an action succeeds in one system and fails in another, blindly repeating it may create a duplicate or leave inconsistent records. Define how the outcome is checked, how partial work is reconciled and when a person takes responsibility. These decisions shape integration and workflow design before a platform is selected.
Give each mechanism a clear job
Deterministic rules apply explicit policy to defined inputs. Use them where the decision should be repeatable and explainable from those inputs. They still need an owner, a controlled change process and tests for boundary conditions; encoding an unclear policy does not make it clear.
Workflow automation coordinates sequence, state, ownership and deadlines. It makes the next step visible and enforces the conditions for moving forward. Integrations carry information and actions between systems. Their design must account for permissions, data meaning, failure and reconciliation, as well as the availability of an API.
AI can help interpret variable information, such as documents and communications, or propose a course of action where the input is less structured. Its output needs evaluation against the work it will actually encounter. Define what must be checked, which actions are permitted and how uncertainty or failure reaches a person. The ability to generate a plausible answer is not evidence that it can safely complete the operation.
People provide expertise, judgement and accountability, including decisions where context is incomplete or the consequences call for authority that should remain human. The design should make that contribution effective, rather than leave people supervising a stream of poorly explained exceptions. The useful question is how these mechanisms work together around a piece of work.
Treat the existing estate as a design constraint
List the systems that hold records or carry out essential actions. Understand their interfaces, access controls, operating constraints and planned changes. Decide what should remain authoritative and where a new workflow needs to connect, rather than assuming that every improvement requires a replacement.
An API may provide a suitable integration point. Where it does not, other approaches, including controlled interaction with an application interface, need to be assessed against reliability, permissions and maintenance. Retaining a system is a design choice with responsibilities, just as replacing it is. Neither choice removes the need to plan for failure and change.
Define improvement before measuring delivery
Choose measures that describe the operation, such as elapsed cycle time, throughput, manual touches, rework or service performance. Agree where the baseline comes from and how comparable work will be measured after a change. A shorter processing step may have little effect if the work still waits elsewhere.
Pair the intended benefit with the controls that must remain effective. Faster completion should not depend on skipping necessary checks or shifting unrecorded work to another team. Set an initial scope that can test the end-to-end design, including an exception and its recovery, and use the findings to decide what to extend.
What you should have before a technology shortlist
The output does not need to be a vast specification. It should be a shared account of the workflow and its owners; the information and systems it relies on; the decisions, authority and controls; the exception and recovery paths; and the outcomes against which change will be assessed.
With that in place, a technology discussion becomes more useful. You can ask how a proposed tool fits a defined responsibility, where it creates a dependency and what evidence would demonstrate that it works. Design the operation first, then choose and test the technology against it.
Read more about how we work from discovery through ongoing operation.
