Follow a request through its corrections
A straight-through demonstration can make a workflow appear complete. The customer enters the correct details, staff accept them and every response arrives in order. A corrected request is often a better way to find where the system loses meaning.
Choose a fictional example with one change that the real business needs to support. Keep the rest ordinary so that the review can follow the consequence of that change.
Record the first version before introducing the correction
Suppose a customer asks for six units of item M-7, then explains that they meant six packs. The original request is not meaningless; it records what staff first received. The correction changes the quantity interpretation and may affect availability or price review.
List the places that contain this information: the customer receipt, staff queue, working notes and any connected system. Identify which one is authoritative for the approved current request and how the original submission remains available where needed.
The aim is not to preserve every draft forever. It is to agree which history the business requires and how staff distinguish a superseded detail from the current one.
Follow who is allowed to make the change
Can a customer amend directly, or does staff record the change after a conversation? Does another person approve it? What happens if the request has already reached a later stage? Those are business decisions with different implementation consequences.
A screen that lets anyone overwrite a number may be simple to build but difficult to trust. Equally, requiring a new request for every small correction can fragment the conversation. The appropriate boundary depends on the process and the effect of the change.
Inspect the messages that still describe the old request
An existing notification may remain useful as a record of the earlier event, but it should not be mistaken for the latest instruction. A new message should identify the correction clearly enough for the recipient to relate it to the same request.
If a staff member returns through an old link, what do they see? If a queued action was prepared using the old quantity, does it need review before it proceeds? The test should expose these consequences before acceptance is signed off.
End with a clear current position
Ask a colleague to explain the requested item, the current quantity meaning, who approved the correction and what remains to be checked. If they must reconstruct the answer from conflicting messages, the workflow still has an information gap.
Record the gap as a concrete requirement. It might be a missing relationship, an unclear state or a permission decision rather than a new page. The order request service can develop the agreed correction process; the project brief turns the finding into a useful development question.