The Purchase Request That Gets Split Across Three Emails

Imagine a small engineering workshop handling this situation. A supervisor asks for replacement parts, sends the quantity separately and later changes the delivery location.

The buyer has to reconstruct the request before ordering. In this fictional example, nobody needs a dramatic new platform to understand the frustration. The useful starting point is the gap between what the record appears to say and what the next person needs to know. The first decision concerns the process, before any particular technology is chosen.

The purchase decision is scattered across messages rather than held in one controlled request. Approval may refer to an earlier quantity.

The buyer needs one actionable instruction, not just evidence that somebody approved something. The approved request should make quantities and destination unmistakable.

The request should retain a clear current view alongside its decision history. A buyer needs to see whether a later quantity change has been reviewed, rather than choosing whichever message looks most recent. The supplier-facing order can then be prepared from one checked instruction. The extra work often appears as a correction rather than a scheduled task. Staff search earlier records, ask a colleague and then explain the discrepancy. Because those steps are scattered across the day, the underlying design problem can remain difficult to see.

Keep a purchase request with quantities, delivery details and approval history. Changes affecting the approved commitment should return it to the appropriate reviewer.

Keep exceptions visible with a reason and a named person responsible for resolving them. Each transition should identify the information required and the person authorised to make the decision. Where a connection is needed, investigate the precise actions it supports instead of assuming every status can be transferred. The useful boundary is between preparing the next action and authorising a consequential commitment. The current application may already support suitable forms, approval stages or linked tasks. Changing the workflow should preserve meaningful history rather than simply replacing yesterday's value. Begin with an agreed sequence of business states rather than a chain of emails.

Preparing an order is different from approving expenditure or releasing it to a supplier.

For background relevant to purchase request changes, see The Business Task Everyone Assumes Someone Else Is Doing. The issue here is the narrower workflow described in this example.

Change the delivery address after approval and confirm that the buyer sees the new request without losing the original decision. Use an approved sample to examine the entire sequence, including any linked documents or downstream actions. Decide in advance what should remain unchanged. Reviewing preserved information can be just as important as confirming the new action happened.

For purchase request changes, review the proposed outcome with the staff responsible. The test should show who owns the next action, what evidence supports the current state and which decision remains outstanding. Check that a correction leaves the history understandable and does not silently authorise a later step. Record the decisions made during the trial and assign responsibility for keeping them current. Otherwise the same uncertainty can return after the next staffing, software or process change.

At Software Logic, we explore how workflow automation can support everyday work, including the decisions that should remain with the people responsible. Could your buyer identify exactly what was approved without reading the whole email chain?