Why should every quote request land in one queue, whatever…

Why should every quote request land in one queue, whatever channel it arrived on?

Because the thing that loses the order is almost never a misread line. It is a request nobody could see.

A distributor taking work by email, by attachment, by portal and occasionally by photograph does not have one inbox with four kinds of message in it. They have four queues, each checked by a different person at a different rhythm, and no single answer to the only question that matters on a Tuesday morning: what have we not replied to yet?

For the owner or sales lead deciding what to fix first. 6 minute read.

Four channels is four queues, and nobody owns the gap

The failure has a shape. Each channel is fine on its own — somebody watches the shared mailbox, somebody else knows to check the portal, the photographs go to whoever the customer has a phone number for.

The gap is between them. A request that arrives on the quietest channel waits longest, and nothing in the system knows it is waiting. There is no list where it sits alongside everything else, ageing in public. It surfaces when the customer chases, which is also the moment they mention they have had two other quotes back already.

This is why "we need to quote faster" is usually the wrong diagnosis. The typing is not what took the time.

The delay is mostly waiting, and that changes what you build

Here is a piece of arithmetic worth doing on your own numbers rather than ours.

Take the elapsed time from a request landing to a quote going out. Then take how many requests one person is carrying at once. Multiply them. If the answer is more hours than a person has in a day — and it usually is — then most of that elapsed time is not somebody typing. It is the request sitting in a queue, or waiting on an answer from a supplier.

That distinction decides what the software is for:

What you remove — If it were working time: hours of labour per quote · If it is waiting time: the delay
What you sell internally — If it were working time: fewer staff hours · If it is waiting time: being first back
How you would prove it — If it were working time: a wage calculation · If it is waiting time: win rate on fast quotes against slow ones

We think it is waiting time, and we say so as a reading of the arithmetic rather than as a measured finding — we have not measured it in anyone's business and no number in this article claims otherwise.

Two things follow. Do not build for headcount reduction, because on this reading there is no labour argument to make. And measure win rate against response time from the first week, per customer, because that is the only number that tests whether any of this was worth doing.

What one queue actually has to show

A single list is not the point. A single list with a clock on every row is the point.

Company and person, always. A quote gets answered by someone who recognises the name.
Elapsed time on every row. A queue that does not display its own age quietly rebuilds the problem it was bought to solve.
The unrecognised sender, shown rather than hidden. A request that did not resolve to a customer is the one most needing a human, not the one to tuck away — chapter 2.

That third point catches people out. The instinct is to hide what the system could not work out. The instinct is exactly backwards, because an unidentified sender is either a new customer worth having or a contact writing from an address nobody recorded.

And the clock has to include our own delay. A line flagged for a person, sitting for two hours because nobody looked, has rebuilt the original problem inside the new system.

What can arrive inside one request

Worth being concrete, because "unstructured inbound" is a phrase that hides how much variety a real morning contains. Any one of these is enough on its own, and a single thread often carries three:

A list of your own item numbers — Almost nothing. Look them up
Product names in prose — "pipe insulation 22 mm, 40 m" — Resolve against description and attributes
A spreadsheet attachment — Read the right columns, keep the row number against every line
An invoice or a previous order document — Read somebody else's layout, which changes per customer
A photograph of a written list — Read handwriting, then everything above
A pointer to a past order — "same as the Kelso site" — Answerable only from that customer's order history

The last row is the one that decides architecture. It cannot be answered from the message at all — the answer is in the ERP, which is why a quoting system that does not read the order history will keep handing that request back to a person forever.

And the mailbox should be a shared one. A sales@ or orders@ address rather than a named employee's personal inbox: reading somebody's personal mail is a permissions problem in every jurisdiction, and a shared box is better practice for the distributor anyway — the work does not stop when one person is on holiday.

EDI belongs in the queue too, even though nothing needs reading

This is the case people argue with, so it is worth making plainly.

Structured traffic — EDI, a portal, a web form — arrives already resolved. There is nothing to interpret, no line to match, no judgement to apply. On the question "where does software earn its keep?" it sits at the bottom.

That is a statement about the reading, not about the queue. A distributor with structured traffic and unstructured traffic still has two places to look and two answers to "what is outstanding?" The clock applies to every request regardless of how it arrived, and one place to answer from is worth having whether or not anything had to be worked out on the way in.

Microsoft's agent watches one mailbox, and says so

Business Central's own Sales Order Agent [GA] is explicit about its intake, and the bound is worth reading before assuming it covers your inbound:

"The agent reads inbound emails via a shared inbox on Microsoft Exchange… Other ways to receive email aren't supported."

It handles the email body plus attachments, and Microsoft bounds those too: "The agent processes the email body and any PDF or image files attached to emails to get the details of the request. PDF attachments must be 20 MB or smaller and contain a maximum of 10 pages."

There is a second bound most people miss, and it is a queue behaviour rather than a reading one:

"The agent uses the activation date as the starting point for retrieving emails. It doesn't process emails received before this date."

Requests already sitting in the mailbox on the day you switch it on are invisible to it. Microsoft documents the way round it — forwarding creates a new message with a current received date — and also documents what forwarding costs you: "the agent identifies the sender from the forwarded message's From field (your address, not the original sender)."

None of that is a criticism. It is a well-drawn boundary around one channel, and knowing where it sits is how you work out what is left over.

The channel that arrives with its own clock

If any part of your inbound comes through WhatsApp, that channel carries a timer set by Meta rather than by you: once a customer messages, there is a 24-hour window for free-form replies, after which a business-initiated message must use a pre-approved template.

And the economics change on 1 October 2026, when Meta begins charging per delivered message for service replies inside that window — messages that are free under the policy in force as this is written. Meta committed to publishing per-country service rates by 1 September 2026.

The practical consequence is not the cost. It is that a clarifying question stops being free, which is an argument for asking one good question rather than three vague ones — chapter 3.

About Cognilium Cognilium builds AI systems that work in tandem with Microsoft Dynamics 365 — the decisions the ERP records but does not make. Business Central and Finance & Operations, on your own governed stack. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Want to know how many of your quote requests are waiting rather than being worked on? Book a 15-minute call and we will walk your channels and where the clock actually runs. No deck.

Why should every quote request land in one queue, whatever channel it arrived on?