What was missing when the work came back?

An order goes to scheduling. Scheduling sends it back with a question. Someone finds the answer in an email, adds a note, and sends the order again.

The question may be perfectly reasonable. The return trip is still worth examining. Did the answer already exist when the order left? Could the next person find it, trust it, and know what to do with it?

Those are different problems. Treating all of them as “too much manual work” makes it easy to fix the wrong thing.

Three reasons a handoff can fail

The source didn’t travel with the work. The order says “use the revised address,” but doesn’t identify which revision. A number has been copied into a worksheet without its source. The receiver can see an answer but cannot tell whether it is current.

Adding another required field may not help. The useful change might be a reference to the agreed source, with the revision or date that matters. Check that the receiver can actually access it. A link to a folder they cannot open is not a completed handoff.

The decision or its owner is unclear. “Please review” doesn’t say what someone needs to decide. Is the delivery date acceptable? Is an exception allowed? Does this need approval at all?

A full document can still leave someone unable to proceed. State the decision needed, who can make it, and what happens if that person is unavailable. More background will not substitute for authority.

The checks keep changing. One reviewer asks for a reference. Another asks for a different attachment. The sender learns the requirements only after submitting the work.

Ask the people receiving it to agree what they need before accepting it. Separate checks that apply every time from checks triggered by an exception. Otherwise a checklist can become a growing collection of everything anyone has ever requested.

These causes can overlap. Start with the question that actually stopped the last item, rather than redesigning the whole process at once.

Not every return trip is a mistake

Review can uncover a changed requirement, a genuine error, or a risk that needs judgment. That is useful work. A person asking for evidence before approving an exception may be doing exactly what they should.

A different situation is asking the sender to recover an answer that was already agreed but never included. The review may still be necessary; reconstructing its starting point may not be.

Ask: “Did this check discover something new, or did it have to recover something we already knew?” Sometimes it did both. Keep the valuable check and improve what reaches it. Fewer returns is not a good result if people simply stop asking necessary questions.

An illustrative example: the delivery note

This is a made-up example, not a customer account or a measured result.

An order reaches scheduling with “delivery agreed” in the notes. The scheduler returns it because the requested date is unclear. The sender replies with a date copied from an email.

That reply answers one question, but leaves another: was this the customer's request or a date the business committed to?

A better handoff could identify the dated source message, distinguish the requested date from the confirmed date, and name the person who can approve a change. If nothing has been confirmed, it should say so rather than filling the gap with a guess.

Scheduling may still need to send the order for a decision. That is not evidence the change failed. The aim is to make the real decision visible, not to make every item appear ready.

Try it on paper before changing software

Choose one recent returned item. Remove confidential details, or make a plain substitute that preserves the same missing information. Sit with someone who sends this work and someone who receives it.

On a sheet of paper, write:

• What was handed over, and what was the receiver meant to do next?
• What exact question caused it to come back?
• Was the answer already known? Where was the agreed source?
• Could the receiver access that source and tell which version mattered?
• Was a decision needed? Who could make it?
• Which check should apply every time, and which only for this exception?
• What must still be reviewed by a person?

Now rewrite just that handoff. Give it to the receiver without explaining it aloud. Ask them to point to what they would use and say what they would do next. If they need your spoken explanation, write down what was missing. Don't count your presence as part of the solution.

Try an ordinary case and an exception. Keep the change small enough to test in real work, where permitted. Note why the next item returns, not just whether it does. This is a diagnosis exercise, not proof of savings.

Then decide what, if anything, to automate

If the source is agreed, the decision is clear, and the checks are stable, moving information automatically may be worth investigating. You still need to establish access, permissions, error handling, and who owns corrections.

If those basics are unsettled, automation can carry an incomplete handoff faster. An agreed note or a manual checkpoint may be the more useful first change.

You can stop with the paper test. If a prompt would help, LumeVest's optional local return-trips guide offers prepared suggestions based on your choices. It does not interpret your description or assess automation feasibility. No account or contact details are required.

Or, where you're reading this in a conversation, reply with the question that sent the work back—without names or confidential details. That's enough to start; no booking needed.