Waiting for parts needs its own place in the work queue

Waiting is a working state

Give waiting work a name that means something in your business. Incoming can suit jobs held for expected goods. Another operation might use Awaiting access or Waiting for approval. Keep the reason visible rather than building a long list of almost identical statuses.

Shopify’s fulfilment guidance makes a related distinction: a hold can block fulfilment while the order and its inventory reservation still exist. Its exact rules belong to Shopify, but the underlying question applies to a bespoke system too: which actions should be blocked while this reason remains unresolved?

Source: Shopify: holding fulfilments

A shared list needs an owner for the next action

Unassigning the delivery work can be sensible if nobody can start it yet. That must not make the follow-up owner disappear as well. Decide who checks the waiting list and how they know a review is due. Otherwise everyone can see it and everyone can assume somebody else is handling it.

Our queue keeps the held-since date visible. For the wider process, I would also agree how the reason and next review are recorded. A goods update, a colleague’s note and the date somebody promised to check again should be easy to find from the job.

• What is the job waiting for, and when did it move here?
• Who is responsible for checking the blocker?
• What evidence will make it ready to resume?
• Does the customer need an update, and who is authorised to send it?

Make resuming the work a deliberate handover

When the item arrives, someone still needs to check that it is the right item and that the rest of the job can go ahead. Moving the job to a person’s active list should make ownership clear. An arrival note alone should not imply the whole job is ready or complete.

The interactive example uses a fictional service job. Its history survives the move. The person taking it back can see why it was waiting and what has now been checked.

Flying PenguinFrom the workshop

Move waiting work back into action

Waiting on goodsReady for an owner

Pause

QueueShared IncomingThe fictional job is still open.

BlockerItem not receivedIts notes and completed checks remain attached.

Next actionReview the waitNo customer arrival message is triggered.

The job remains visible while its blocker is unresolved.

Keep internal moves separate from public promises

An internal queue serves staff. A customer-facing status, stock count and dispatch message each carry a different meaning. Decide explicitly whether a queue move changes any of them. For our recent change, placing work in Incoming does not change stock or send a customer status message.

That separation matters during corrections. Someone may put a job back on hold because the wrong item arrived. They need a truthful internal record without accidentally issuing a second arrival notification or changing a public listing.

• When a spreadsheet needs to become a CRM

Protect the move when two people have the job open

Two people can read the same job and make different decisions. Check that a move is based on the current saved version. If somebody else has changed it, ask the second person to review the newer record before applying their move.

We checked that completed work could not be pushed into the waiting queue and that a stale edit was rejected. Existing jobs were not automatically reclassified just because the new view existed. Those boundaries keep a useful new queue from rewriting history or undoing somebody else’s work.

Start with the blocker people already chase

Look at the jobs staff regularly ask about in chat or meetings. If the same question is “has that part arrived yet?”, there is probably a useful waiting view to build. Map one blocked job from the initial hold through to its eventual handover.

We can add that routine to a bespoke CRM without making staff pretend waiting work is complete. Keep the list small enough to review, keep the history attached and give the next action to an actual person.