Define the record.
Start with the unit of work. Is it a request, an invoice, an asset movement or a customer case? Give it a durable identifier and decide which information belongs to it. Supporting files should remain connected to that record rather than depending on a subject line or someone's folder naming convention.
A request with several documents should still be one identifiable item. A revised document should not accidentally become a separate request unless the process explicitly treats it that way.
Define the state and the owner.
For each stage, identify who is responsible and what allows the item to move forward. “In progress” is often too broad to explain whether someone is actively working, waiting for information or waiting for a decision.
You do not need dozens of statuses. You need a small set that distinguishes meaningful operating conditions. A reviewer should be able to see the next action without reconstructing the email history.
Design the exceptions before automating notifications.
What happens when an attachment is missing? Can an approver return an item? Who can reassign it? What happens when a decision changes? These are normal parts of the operation, not edge cases to leave outside the system.
A returned request should keep the reason for return. A reopened item should preserve its earlier closure. A failed notification should not erase the business decision or make the system pretend that follow-through succeeded.
Agree what the clock measures.
Turnaround time needs a start, an end and a rule for interruptions. Calendar time and business time answer different questions. Time since assignment does not prove a person actively worked for that entire interval.
Suppose an item takes three days to close but spends two days waiting for additional information. A single elapsed-time measure is useful for the overall experience, but it does not explain the bottleneck. Separating stage events gives the team a more defensible basis for improvement.
Decide what should stay in the existing tools.
A workflow does not have to own every document or replace every enterprise application. It may reference a file repository, synchronize an approved status or retrieve reference values from a database. Define which system remains authoritative and what happens when information conflicts.
The goal is not to create another copy that people must reconcile. It is to make the relationship between records visible and reliable enough for the process.
Start with a testable scope.
Choose one request type, the key roles and a small set of realistic examples. Include an incomplete submission, a returned item and a failed integration, not just the happy path. Agree what users should be able to explain from the record alone.
That gives a prototype or pilot a useful purpose: demonstrate whether the process is clearer, whether ownership is visible and whether exceptions can be handled without abandoning the system.
At Xyloquent, this is the starting point for workflow engineering: define the work and its handoffs, then choose the software that supports them.
Explore the design in practice.
The example request example preserves the original mismatch, blocks approval while an exception is open and records notification failure separately from the decision.
Work through the request example