Where’s My Order?

Part 7 of 10 – the inside sales desk

The AI writes the words; the ERP owns every fact; a human hits send.

It is 3:50 on a Tuesday, and Marie has four browser tabs, two phone lines, and a customer who wants to know where his order is.

She knows the answer is findable. It always is. The order shipped, or it didn't; it's on a truck, or it's on a hold; the part is on the shelf, or it's three weeks out. Every one of those facts lives in the ERP, exactly one query away. The problem is never that Spiese doesn't know. The problem is that knowing takes Marie ninety seconds of clicking per question, and the questions do not stop.

This is the same desk from Post 2 – Marie, inside sales, keys fast, remembers accounts by heart. Back then the pressure was the 4:00 cutoff and a PDF purchase order she had to get keyed before the trucks left. That was one order, one deadline, a clean finish line. This is the other ninety percent of her day: the steady, formless drip of customers who just want to know something, and want to know it now.

The email in front of her reads, in full: "Any update on our order from last week? Need it by Friday." No PO number. No part number. Just a customer, a rough memory, and a deadline. Marie will find the order – she recognizes the account, she'll pull their recent lines, she'll spot the one that matches, she'll check its status, she'll confirm the ship date, and she'll write back something reassuring and true. Four minutes, maybe five. Then the next one.

The ERP has the answer. It just doesn't have Marie's time.

What it costs today

Spiese has 4,200 active customers and moves about 184 orders a business day. Behind every order is a small trail of questions – before it (can you quote me 40 of these, do you have it in stock, what did we pay last time), during it (has it shipped, when will it ship), and after it (where is it, why is it short). Eight people in customer service and an inside sales desk field all of it.

Call it roughly 130 inbound customer contacts a day across the desk – a plausible ratio to order volume, and the first thing to measure before you build anything (the Monday-morning section comes back to it). A large share of those are not hard. They're lookups. Where's my order, when does it ship, do you have it, what did we pay – questions where the entire job is retrieving a fact the ERP already holds and putting it into a sentence. Say sixty percent of the volume is that kind of pure retrieval – an estimate, not a measurement, and exactly the number the pilot is designed to pin down.

The retrieval questions are individually cheap and collectively expensive. Figure six minutes of average handle time per contact once you count reading it, finding the record, and writing the reply – an assumed figure, worth a stopwatch before you trust it. At 130 contacts, that is about 13 hours of desk time a day just fielding questions, and the majority of that is spent on lookups a machine could assemble in a second.

Here is the arithmetic, kept honest. 130 contacts x 6 minutes is 780 minutes, about 13 hours. Sixty percent of that – the pure-retrieval share – is roughly 7.8 hours a day of a skilled rep's time spent being a search interface to the ERP. At the series' $45.33/hr loaded rate that is around $353 a day, or on the order of $88,000 a year of desk time. Every input to that line except the labor rate is an estimate, so treat the dollar figure as a sizing sketch, not a defended number – measure the desk first, and it becomes real.

But the dollars are the least interesting cost, and I'd rather not lead with a number the workbook can't defend. The real costs are softer and they hurt more. Customers wait – minutes when Marie is free, hours when she isn't, and "I'll get back to you" is where good accounts quietly start shopping. The good reps become the bottleneck: because Marie is fast and remembers the accounts, the hard questions route to Marie, and Marie is one person. And the whole desk runs in a state of permanent context-switching, which is its own tax – every "quick question" is an interruption to whatever actually needed thought.

None of that shows up cleanly on a P&L. All of it is real.

Where the boundary sits

The ERP is the system of record, and every fact the customer wants is already in it – order status, ship date, on-hand quantity, contract price, last price paid, credit hold. Deterministic, current, auditable. Do not ask a model to remember or estimate any of it.

The work that eats Marie's day is one layer up, and it splits cleanly in two. First, understanding a vague, human question – "any update on our order from last week" – well enough to know which records to pull. Second, turning the retrieved facts into a clear, courteous, correct reply. Both halves are language in, language out. Both are exactly what a system of inference is good at, and neither is a place the record belongs.

The AI reads the question and drafts the answer. The ERP supplies every fact. Marie approves and sends. The model chooses the words; it never chooses the numbers, and it never hits send.

What the AI does – and what it must never do

Does: reads the inbound message and works out what the customer is actually asking, including when they're vague or wrong about their own PO number. It issues read-only lookups for the relevant records – the order and its status, the item and its availability, the customer's contract price, their recent history – and it drafts a reply that answers the question in plain language, with each fact carried straight from the record and tagged to where it came from. For a quote request it assembles the line, pulls pricing from the ERP's own contract-and-price logic, and drafts the quote as a proposal. Then it hands the whole thing to Marie, who reads it, fixes what needs fixing, and sends.

Must never do:

• Never quote a price it made up, remembered, or pulled from anywhere but the ERP's contract-and-price logic. Every number on a quote traces to the record or it does not go on the quote.

• Never promise a ship date or availability the ERP can't back. An unknown date is "let me confirm that for you," surfaced to Marie as a gap – never an optimistic guess dressed up as a commitment.

• Never send anything to a customer on its own. The customer-facing send is the irreversible act, and it stays a human's hand on it, every time.

• Never commit, reserve, or allocate inventory itself. Telling a customer "it's in stock" is not the same as holding it for them, and the AI does neither the holding nor the promising.

• Never expose one customer's data, pricing, or history to another. Contract pricing is confidential per account; the draft for customer A can only ever see customer A.

• Never invent a substitution or a spec it can't source. "You could use this instead" is a claim about fit, and an unsourced claim about fit is how the wrong part ships.

The catastrophic failure mode here is specific and worth naming: a confident, fluent, wrong promise, emailed to a customer in the company's name. Fluent and wrong is worse than obviously broken, because it gets sent.

The plumbing

Most of what this needs already exists. The ERP already answers every one of these questions – order status, availability, pricing, history – the moment you know where to click. What you're building is a layer that knows where to click, and writes up the answer.

Concretely: a read-only interpretation-and-drafting layer that sits beside the desk. It takes the inbound message, maps it to the right read-only queries, retrieves the facts, and produces a draft reply or draft quote with every fact tagged to its record. It has no write path – it cannot change an order, reserve stock, or send mail. Marie's approval is what turns a draft into a sent message, in the same outbound channel the desk uses today.

Who builds it. A layer that reads order status, pricing, and availability through the ERP's own read-only services – and never hits send – sits most naturally with whoever already runs your system of record.

The one genuinely new piece is the grounding discipline: the draft must show its work, so Marie can see at a glance that "ships Thursday" came from order 40318's confirmed date and not from the model's sense of how these things usually go. A draft you can't audit at a glance is a draft you have to redo by hand, which defeats the point.

Failure modes and guardrails

The fabricated fact. The model fills a gap with something plausible – a date, a price, a stock number – because fluent text abhors a blank. Guardrail: the draft may only state facts it retrieved and tagged; a missing fact renders as an explicit "confirm this," never as a confident guess. Sample-audit sent replies against the record weekly and measure the fabrication rate directly.

The stale fact. Availability and status change by the hour; a draft built on a five-minute-old read can already be wrong. Guardrail: retrieve at draft time, timestamp what you retrieved, and re-check anything time-sensitive at send.

The confident substitution. A customer asks "can I use X instead," and the model, wanting to help, says yes. Guardrail: substitutions are surfaced as a question for Marie with the sourcing shown, never asserted as fit in the draft.

The cross-customer leak. Pricing or history from the wrong account bleeds into a draft. Guardrail: scope every lookup to the requesting customer at the query layer, not by asking the model to be careful.

The send button. Every guardrail above collapses if the AI is ever allowed to send on its own. Guardrail: it isn't. Earning the right to remove the human from the customer-facing send is the subject of the final post, and it is not a corner you cut in month three because the drafts got good.

How you'd know it worked

Not messages sent, and not "AI handled it" – those numbers reward volume and hide the miss. Watch three things.

First, response time. How long from a customer's question to a correct answer landing in their inbox? That is the number the customer actually feels, and the one most likely to move.

Second, rep capacity reclaimed. Not to cut the desk – to unclog it. When the lookups draft themselves, how much of Marie's day comes back for the questions that genuinely need Marie? Measure the share of contacts where the draft was sent with only light edits, and the handle time on the rest.

Third, and the one that keeps you honest: accuracy of what went out. Seed a sample, audit sent replies against the record, and track how often a fact in a sent message disagreed with the system. That number needs to be near zero, and you only know it is if you look.

Monday morning

Before any software, measure the desk. For two weeks, have the reps tag each inbound contact: was this a pure lookup, or did it need real judgment? You will get your true retrieval share – the sixty percent I guessed at above becomes a real number – and that ratio is both the business case and the ground truth for everything after.

Then pilot narrow. One rep – Marie is the obvious choice, she'll spot a bad draft in a second – sixty days, draft-only, nothing sends without her hand on it. Watch whether response time falls and whether the drafts are good enough that she sends most with a light edit, or bad enough that she rewrites them all.

If the drafts hold up, widen it one rep at a time. If they don't, you've learned that cheaply and kept it away from customers the whole time. The goal was never to answer more messages. It was to let the person who knows the accounts spend her afternoon on the four customers who need her, instead of being a search box for the other twenty.

Start with the question the customer already asked.

Spiese Fluid Power is fictional – a composite built from published industry benchmarks and anonymized operating ratios. Its full operating profile, with sources, is published separately.