Why your inbox becomes your order management system

Why order processing automation has to start in the inbox: the ERP holds the orders, but the shared inbox holds the context, the exceptions and the decisions.

One person working at a laptop in an office while another walks past carrying folders, the daily traffic that order processing automation has to keep track of.

Your inbox becomes your order management system because it is the only place where the whole order exists. The ERP holds the line items, the quantities and the prices. The inbox holds the reason the customer wanted a split delivery, the promise someone made on the phone, and the note saying to bill the new entity from October. One of those is a record. The other is the working memory of the business.

That is the reframe worth sitting with. Nobody decided to run orders out of a shared mailbox. It happened because the mailbox was the only tool flexible enough to hold what the real work needed, and no one has been able to take that job away from it since.

What does it actually mean to say the inbox is the order system?

It means the answer to "what is happening with this order" lives in an email thread rather than in a system.

You can usually tell within a minute of asking. If someone answers a question about an order by searching their mail rather than opening the ERP, the inbox is the system of record for everything except the numbers. The ERP will tell you that order 40118 was entered on Tuesday for 24 units. The inbox is the only place that will tell you the customer asked for 30, that 6 were out of stock, that someone agreed to ship the rest next month, and that this is the second time it has happened to that account this quarter.

How does a company end up here?

Gradually, and for good reasons every time.

A customer sends an order by email because that is how they have always sent it. Someone answers a clarifying question in the thread, because that is where the question was. A price exception gets agreed in a reply, because forwarding it into a system would take longer than typing yes. A colleague is copied so they know. Each of those is the fastest, most sensible thing to do in the moment.

Eighteen months later the mailbox holds the operating history of several hundred accounts, three people know where anything is, and none of it is searchable by anyone else. No one chose that. It accumulated.

Why does the industry not even count these orders?

Because by definition they are not counted.

Distribution Strategy Group runs an annual benchmark on ecommerce in wholesale distribution. In the 2024 State of eCommerce in Distribution, a survey of 401 distributors and manufacturers, they state their definition plainly: ecommerce is transactions that go through the website, mobile or an app, and the data excludes EDI, punchout and email or fax.

Read that again. The industry's own measure of how digital ordering is going leaves email out of the denominator.

The same report shows how much room that leaves. Half of distributors with more than a billion in revenue offer ecommerce at all. For companies between fifty and a hundred million it is about 35 percent, and for those under ten million, 18 percent.

So for most companies, most of the time, the orders arrive somewhere that no benchmark measures and no roadmap mentions. The channel carrying the majority of the work is the one nobody reports on.

What does this look like in a real business?

A building materials supplier, four branches, a customer service desk of three people and one mailbox called orders.

The mailbox works. Orders get entered, customers get answers, and the team is quick. What is not visible is that the mailbox is doing four jobs at once. It is the intake queue. It is the audit trail for every exception anyone agreed to. It is the handoff mechanism between the desk and the branches. And it is the memory of the account, the place someone checks before ringing a customer to see what happened last time.

Then one of the three leaves for a new job. The orders keep getting entered, because entering orders is the easy part. What goes is the fourth job. Nobody notices for about six weeks, until a customer is told something that contradicts what they were promised in March, and the promise is in a thread nobody thought to look for.

The company did not lose an order entry clerk. It lost a quarter of its operating memory, and it had no idea that was the role.

Can you just move everyone onto a portal?

Rarely, and the order entry post covers why in detail.

The short version: a portal changes the intake, not the working memory. Even customers who adopt the portal will email you the moment something is unusual, and unusual is where the real work is. You end up with two systems and the interesting half still lands in the mailbox.

What does order processing automation have to do instead?

Meet the inbox where it is, and pull the context out of it rather than around it.

Read the order where it lands. In the thread, in the PDF, in the spreadsheet with the customer's own part numbers. Anything that requires the customer to change how they order is not order processing automation, it is a migration project wearing a different hat.

Capture the reason, not only the record. When a quantity is changed or a delivery is split, the why belongs with the order in the ERP, not in a reply. Most of the value here is not speed. It is that the next person can see what happened without having to know who to ask.

Make the thread findable by account, not by person. The failure mode is not that the information is missing. It is that it is filed under a colleague's memory.

Put the exception in front of someone, with what it needs. A held order, a price that does not match the contract, a delivery address that changed. Those should arrive as a decision with the history attached, not as a surprise in someone's morning.

Write back into the ERP. It stays the system of record. If the automation becomes a second place to look, you have added a system rather than removed a gap. That is the wider pattern across the whole quote to cash cycle, not just at intake.

What should stay with a person?

The judgment, as always, and one thing more: the relationship.

Whether to hold a shipment, whether to accept a rush, whether to extend terms to an account that has started paying late. Those need someone who knows the customer. Automating them is not ambitious, it is careless.

But also, the reply that says "I know, this is the second time, here is what we are doing about it". No system should send that. The system's job is to make sure the person writing it already knows it is the second time.

The takeaway

The inbox is not a bad habit to be broken. It is the only place your operating layer has ever been allowed to live. The problem is not that people use email. It is that everything they know is stored there in a form only they can read.

That is the part Elentaria works on: reading the order where it arrives, keeping the reason attached to it, and putting the exceptions in front of the person who should decide.