What do you record for one week, and why that and nothing else?
Five fields per order, on paper or in a shared sheet. Your team will resist a sixth, and five is enough to separate the four causes. Run it for a full week including a Monday, because Monday is not like Thursday in a distribution business.
The field that does the work is the last one. Everything else tells you volume; the reason code tells you what to build. Insist on one reason per order rather than a list, because the point is to find what dominates, not to be complete.
Do not let anyone estimate this from memory. Every operations leader we have asked believed their team spent most of its time keying orders, and the tally usually shows most of the time going to the questions that surround an order rather than to the keystrokes.
How the order arrived: phone, emailed PDF, emailed free text, fax, EDI, existing portal, walk-in.
Number of order lines.
Whether the customer buys on contract pricing or at list.
Minutes from opening the order to saving it in the ERP, including interruptions.
The one reason it took longer than two minutes: price lookup, stock check, part number translation, missing purchase order or ship-to detail, credit or terms question, product question, or none.
What does the dominant reason code mean?
Total the minutes by reason code, not the order count. A reason that appears on ten per cent of orders and adds twelve minutes each time outranks one that appears on half your orders and adds ninety seconds.
Then read the row that matches. Each of the four rows points at a different project with a different cost, and picking the wrong one is how a company spends a year building a storefront that removes fifteen per cent of the work.
| Criterion | What the tally shows | What it means | What to do |
|---|---|---|---|
| Most minutes go to keying, on orders with no reason codeIf this is your dominant row, your project is smaller and more certain than you think. | High line counts, repeat items, the same customers weekly, and nothing unusual about any of it. | You have a self-service problem and nothing more. This is the case a portal actually solves. | Reorder from history and a quick order pad, in that order. These two features remove more order entry hours than the rest of a storefront combined. |
| Most minutes go to price lookups | Reps checking what this customer pays, calling the office, or waiting for someone to confirm a contract price. | Your effective prices are not visible where the order is taken. A storefront that cannot show the contract price will not fix this either. | Solve pricing visibility first, for reps and customers together. Building a portal on top of unresolved pricing produces a portal nobody trusts. |
| Most minutes go to stock checks | Calls to the warehouse, promise dates negotiated per line, orders parked waiting for an answer. | An availability problem, which may be a publishing problem or a data problem. Those need different fixes. | Find out whether your ERP availability figure is one you would be willing to publish. If it is not, publishing is not the first job. |
| Most minutes go to part number translation or missing information | Customers ordering by their own part number, purchase order numbers missing, ship-to addresses ambiguous. | A data and intake problem. Cheap to fix and almost never scoped, because it is nobody’s project. | Load customer part number cross-references and make the missing fields mandatory at intake. Neither requires a platform decision. |
Checked against: Acumatica community 17608: the effective contract price does not reach the storefront, Acumatica community 5378: multi-warehouse availability, the usual source of stock-check calls
How do you turn the tally into a number your CFO will act on?
Do the arithmetic in front of them rather than in a slide. Take the total minutes recorded in the week, multiply by 52, divide by 60 to get annual hours, and multiply by your fully loaded hourly cost for an inside sales role, which your finance team can give you and which we are not going to invent for you.
Then split that annual figure by reason code, because the split is the argument. A number that says order entry costs the business a certain amount is interesting. A number that says a specific share of it is repeat keying with no exceptions, and that share is what a portal removes, is a business case.
One caution that keeps this honest. The tally measures the cost of the current process, not the saving. A portal moves work rather than deleting it: somebody maintains the catalogue, somebody answers the emails that used to be phone calls, and somebody handles the orders that arrive wrong in a new way. Take a discount against your gross figure and say what the discount is, because the person who approves the budget will apply one anyway and it is better if it is yours.
What share of your orders can actually move online?
This is the ceiling test, and it is the number that decides whether the project is worth doing. Go back through the week and count the orders that meet all of these conditions: the customer is set up with a price they can see, every item is in the published catalogue, nothing on the order needed a stock promise, and no exception was raised.
That count divided by total orders is your realistic ceiling for online adoption in the first year. Not your target, your ceiling. Anything above it needs a second project.
We have seen this number land anywhere from a fifth to two thirds depending on how much of the catalogue is stocked and how many customers are on contract pricing, and we are describing the shape of the calculation rather than publishing a benchmark, because a distributor’s ceiling depends on facts only they have.
If your ceiling is low, that is not a reason to abandon the project. It is a reason to change the order of it. The thing blocking the ceiling, usually pricing visibility or catalogue completeness, is the first phase, and the storefront is the second.
Checked against: The range quoted here is an Acro Commerce project observation rather than a published benchmark. We are describing the calculation rather than asking you to adopt the number.
When is the answer not a platform at all?
Three situations where a commerce project is the wrong response to a drowning order desk, and where saying so will save you a year.
The most uncomfortable one is the third. If the tally shows your team spends its time on exceptions rather than on keying, a self-service channel adds a new source of exceptions and removes very little. Fix the exception rate first, then automate what is left.
The volume is genuinely seasonal and the desk is fine for nine months of the year. Temporary help is cheaper than a platform and available in weeks.
The orders arrive as structured files from a handful of large customers. That is an EDI or import problem, and building a storefront to solve it is an expensive detour.
Most minutes go to exceptions rather than to keying: substitutions, credit questions, delivery negotiations. Self-service does not remove exception handling, it changes who raises them.
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- How long should we run the tally before we trust it?
- One full week including a Monday, and repeat it in a different month before you commit budget. A week is enough to find the dominant reason code, which is what the decision turns on, and it is short enough that your team will actually complete it. A month of data collected badly is worth less than a week collected properly, so favour compliance over duration.
- Which two features remove the most order entry hours?
- Reorder from a customer’s own order history, and a quick order pad that accepts a list of part numbers and quantities or a pasted spreadsheet. Between them they cover the repeat business that makes up the bulk of a distributor’s line volume, and neither depends on beautiful product content or search. If your first phase does nothing else, do these two and the pricing they need to be correct.
- Our reps say customers will never order online. Are they right?
- Sometimes, and the tally tells you rather than the argument. Count how many of last week’s orders came from customers who already send structured emails or spreadsheets, because those customers have already demonstrated they will use a system rather than a phone. Rep scepticism is also frequently about commission and account ownership rather than about customer behaviour, and that is a compensation question you should settle before launch rather than after.
- Will a portal reduce headcount on the order desk?
- Plan on redeployment rather than reduction, and say so out loud when you present the business case. The hours come back as capacity, and in most distributors that capacity gets absorbed by growth, by the exceptions that were previously being rushed, and by the catalogue maintenance the new channel creates. A business case built on headcount removal tends to fail its own audit twelve months later even when the project succeeded.
- What if the tally shows no single dominant cause?
- Then your problem is volume rather than friction, and the answer is either capacity or a channel change for your largest customers. An evenly spread tally with high totals usually means the process is working and there is simply more of it than the team can carry. In that case look at which customers generate the most lines and whether those specific accounts belong on EDI, a portal, or a scheduled replenishment arrangement.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.