Workflow design defines how tasks, decisions, evidence and responsibility should move from a trigger to a required result. Automating an unclear workflow can make waste and confusion move faster. Marketways redesigns handovers, exceptions and controls around the complete outcome before deciding what people or technology should execute. The client gains a process that is clearer to operate, govern and improve.
The decision this method supports
We use Workflow Design & Redesign to help clients answer: How should work move in the future, and who or what should act at each point?
How the method works
Workflow design specifies how work should move in the future. It defines tasks, decisions, information, handoffs, exceptions, controls and measures. Redesign begins with the required result and removes avoidable work while preserving necessary authority and safeguards.
A business example
A customer-onboarding workflow may combine automated checks with human review. The design should specify which evidence automation can accept, which cases require judgement and how unresolved cases are escalated.
How the client uses the result
Workflow design turns an improvement idea into a practical sequence of work. The benefit is clearer ownership, fewer avoidable handoffs, defined exceptions and a process that people and technology can carry out consistently.
What we deliver
We produce a current-state map, evidence about losses, a future workflow, architecture choices or control requirements. The result make ownership, handoffs, exceptions and implementation dependencies explicit.
Limits and complementary methods
A sound design clarifies future work, but benefits appear only after implementation, adoption, measurement and revision.
Selected methods and techniques
We select from these established methods according to the decision, evidence and operating conditions.
- Agentic-AI workflow decomposition: Break a proposed AI-enabled workflow into bounded tasks, inputs, outputs, decisions, tool actions, stored state, human handoffs and exception paths. For each element, identify whether it follows a fixed rule or requires model judgement, what authority is needed, what could fail, what evidence must be logged and when the workflow must stop, ask for help or fall back to a manual route. The method designs and screens the work allocation before or during redesign. It does not establish that a particular agent is accurate, secure or safe for deployment; those claims require system-specific AI and model-risk testing.
- Automation feasibility analysis: Assess whether a defined task or task group can be automated with acceptable reliability, cost and control. Examine input quality, rule stability, frequency, variability, integration needs, exception rates, required judgement, error consequences, human authority, fallback, implementation effort and expected economic benefit. Compare full automation with partial assistance and leaving the work unchanged. The method screens whether automation is worth developing and under what conditions. It does not validate a built system, prove realised savings or imply that every activity in a role should be automated.
- Automation-bias assessment: Assess whether people accept, follow or fail to monitor automated advice too readily, especially when it is plausible but wrong or outside its supported use. Compare behaviour with and without advice, challenge quality, time pressure, interface cues and error outcomes. Agreement alone does not prove automation bias because the recommendation may be correct.
- Automation-level assessment: Assess the appropriate level of automation for each function, from full human control through decision support and supervised automation to full automation, taking account of reliability, consequences of error, oversight capacity and accountability. It distinguishes whether something can be automated from how far it should be.
- Control-point design: Decide where in a system performance, quality, security or risk should be checked or regulated, what is checked, by whom or what, against which standard, and what happens when a check fails. Control points are placed where they prevent or detect material problems at acceptable cost. Too many controls can slow a system without adding protection.
- Escalation-path design: Design how exceptional, uncertain or high-risk cases are routed to the right person or team, with the information, authority and time needed to act, including what happens if the escalation is not picked up. It designs the path; escalation-path testing checks whether it works.
- Escalation-path testing: Trigger cases that should leave the normal automated path and test whether the correct escalation rule, route, priority, time limit, recipient capacity and fallback are activated. Include missed, late and unnecessary escalations and unavailable control owners. This method tests whether the escalation path operates; handover testing separately checks whether the transferred case state is sufficient for safe continuation.
- Handover / escalation testing: Test whether a system recognises when it cannot or must not continue, transfers the case to the correct human or agent and preserves facts, constraints, evidence, attempted actions and unresolved issues. Verify timing, acknowledgement, ownership, fallback and the recipient's ability to act. For multiple agents, introduce conflicting findings, concurrent assignments and failed handoffs; check reconciliation, duplicate actions and final responsibility. Include cases requiring no escalation to measure unnecessary intervention. Sending a notification does not establish an accepted or completed handover.
- RACI / handoff analysis: Apply the Responsible, Accountable, Consulted and Informed role structure to process steps and handoffs, then compare the stated allocation with actual authority and practice. Identify work with no responsible role, unclear or competing accountability, unnecessary consultation, missing information and transfers where acceptance is not confirmed. RACI is the reusable responsibility format; RACI / handoff analysis is the performed review; a Handoff / Ownership Map is the populated result. The labels clarify roles but do not create authority, capability or cooperation by themselves.
Parent method family
Process, Workflow & Systems explains how this method connects to adjacent methods and relevant services.
Related service families
These service families contain business questions supported by this method. Service pages link to the wider method family so readers can understand the complete analytical approach.