You are chasing your own organisation.

Why the definition points inwards

Last week established where a long-lead item is actually lost: not in manufacture, but in the drawing loop before manufacture starts, because lead time is quoted from release.

Follow that through and the expediting job changes shape. When a supplier is waiting, the thing they are waiting for can be something the buyer owes them — a comment closed out, a data sheet approved, a decision on a deviation, a clarification of a specification that reads two ways.

So the call to the factory produces a list, and a good part of that list is addressed to people in your own building. That is the part nobody expects the first time they do it, and it is the part that makes expediting effective when it works: the intervention that moves a delivery can be available inside your own organisation, where you can act on it without anybody's permission.

It also changes who should do the job. Somebody whose instinct is to press a supplier will get status and no movement. Somebody whose instinct is to ask what is missing will come back with three items, two of which are yours, and will have shortened a delivery by acting on the two.

The only forward-looking data in procurement

Consider what else procurement generates, and when each of those things arrives.

A goods receipt says something arrived. An invoice says something was billed. A delivery note says a lorry came. Every one of those is a record of an event that has already happened, and every one is exact and useless for planning.

An expediting report is the only document in the whole chain that describes a future state. It says a thing is on course, or it isn't, and it says so while there is time for the answer to matter. The same literature places expediting alongside inspection as the functions that produce information about supply chain performance, which is the correct framing: it is a measurement function that happens to intervene, rather than an intervention that happens to report.

Which answers mean yes

The quality of that data depends entirely on the question asked, and there is one question — the obvious one — that produces nothing at all.

Asking a supplier whether an item is on schedule invites the answer yes, and the answer costs them nothing to give. It isn't dishonest. It is a statement about intention, made by somebody who hasn't been asked for anything checkable.

What produces information is a named intermediate event with a date against it. Has the material been released from the mill. Has the casting been poured. Has machining started. Has the factory acceptance test been booked, and with whom. Each of those either happened or it didn't, each has a date, and a supplier who is behind will hesitate on one of them rather than on the summary question.

Which means the useful expediting report isn't a status column. It is a short list of events, each present or absent, and it is built once per item type and then reused for the life of the project.

Building that list requires knowing how the item is made, which is the part that looks like it needs a specialist and doesn't. The supplier will describe their own production sequence if asked, once, at the start. Ten minutes on the first call buys the question set for every call afterwards.

Why it gets cut

Expediting has the profile of work that gets removed under pressure, and the profile is worth naming because recognising it is most of the defence.

Four properties, and they compound into an activity that is hard to defend and expensive to lose.

It produces no measurable output. It can't be shown to a visitor. Its successes are invisible — a delivery that arrived on time looks the same whether or not anybody worked to make it happen. And its failures arrive late enough that they get attributed to the supplier rather than to the absence of the function.

So the cost of not doing it doesn't land on the budget line where the saving was made. That is the same structure as several things this track has met, and it has the same defence: a record that exists before the failure, showing what was known and when.

Which is also the honest argument for the function, and it isn't the one that gets made in the meeting where the headcount is decided. Expediting earns its place less by speeding things up than by being the only way anybody finds out early. A project that expedites well and still takes the delay has at least taken it with three months of warning, which is enough time to resequence around it.

System design

Row four is the one that doesn't exist anywhere in this industry as a named document, and it is the cheapest thing in this table. It comes out of a question that takes ten seconds at the end of a call somebody is already making.

Record	Produced by	Required quality	Verified against	Feeds
Expediting plan	Procurement, per order	States the level of attention each item gets, and why that level	The consequence of the item being late	Where effort goes
Intermediate event list	You, once per item type	Events that either happened or didn't, each with a date	The supplier’s own production sequence	Every report afterwards
Expediting report	The expeditor, weekly	Describes a future state, not a status word	The events it claims	The only forward view of supply
Outstanding-with-buyer list	The question at the end of each call	Item, what is outstanding, who owes it, how long it has been outstanding	Your own approval queues	Whether the delay is yours
Exception log	Whoever raises it	Records what was raised and on what date, before the outcome is known	The report it came from	Attribution when the item is late

Row five carries the requirement that makes any of this defensible later: raised and dated before the outcome is known. An exception recorded after an item is late is an explanation. The same exception recorded in advance is a record.

Practical insight

End every expediting contact you make with one question, and write down the answer: what are you waiting on from us?

Your question does three things at once. It gets you the real constraint rather than a status. It puts the supplier where a vague answer is awkward, because they are being offered help rather than challenged. And it produces a list you own, addressed to your own colleagues, with dates on it.

The awkwardness matters more than it sounds. A supplier can decline to admit they are behind. Declining to name what they need is a different kind of refusal, and it has to be made deliberately, in a conversation where help was just offered.

Keep your list as a single running page — item, what is outstanding, who owes it, how long it has been outstanding. Nothing else on your project holds those four facts together, and your fourth column is the one that changes conversations.

Then send it weekly to the people named in it. Not as an escalation, and not with a covering argument — as a list of things suppliers are waiting on. It is short, it is factual, and it will be the only document on the project showing the cost of your own approval queues before that cost turns into a date.

Key takeaways

• Expediting produces no drawing, no work face and no defensible percentage, which is why it disappears from progress reporting.
• Its purpose is to help the supplier meet what they already owe, and the help is moving information along and getting approvals released.
• Helping rather than enforcing, and a good deal of what is being unblocked is the buyer’s own paperwork.
• Since lead time runs from drawing release, a waiting supplier can be waiting on something the buyer owes them — which puts the intervention that moves the delivery inside your own organisation.
• Goods receipts, invoices and delivery notes are all exact records of things that already happened.
• An expediting report is the only document in procurement describing a future state, while the answer can still matter.
• Asking whether an item is on schedule invites a costless yes, which is a statement of intention rather than information.
• Named intermediate events with dates — material released, casting poured, machining started, test booked — are checkable, and a supplier who is behind hesitates on one of them.
• The useful report is a short list of events built once per item type and reused, not a status column.
• Expediting gets cut because its successes are invisible and its failures arrive attributed to somebody else.

Records born here. The expediting plan, and the level of attention chosen per item · the intermediate event list per item type · the expediting report, dated · the outstanding-with-buyer list · the inspection and test booking, with who attends · the exception log, recording what was raised and when.

What is coming next

All of that applies to items ordered in the ordinary course. A few things on every project are ordered long before anybody could reasonably know what is needed, because their lead time is longer than the design that specifies them.

Buying those is a decision to commit money against a drawing that doesn't exist yet, and it is taken by somebody weighing the cost of being wrong against the cost of waiting. What comes next is how that judgement is made, what it commits, and what happens when the design catches up and disagrees.