.png)
What Authority Looks Like on a Sales Order
One of our clients started using the order parser on a new customer last month. The PDF came through in the usual way, the extraction ran, the line items came out clean. The order didn't get created.
The customer match had failed.
The parser checks an incoming order against the existing customer records in four ways. An exact match on the customer name. A match on the email domain. A trigram match on the name — a fuzzy match that catches typos and small formatting differences. And an embedding match on the name, confirmed by trigram, which catches the cases where the names are conceptually the same but written differently enough that a fuzzy match alone wouldn't see it. The four passes produce a combined score, and there's a threshold. Below the threshold, the order doesn't get created. It gets held, and an operator resolves the customer attachment by hand.
This was the first order our client had processed from this particular customer through the parser. The customer record existed on their side from earlier work, with a name and an email domain. The new order arrived with the company name written in a slightly different form — close, but not an exact match — and from an email on a different domain than the one on the record. It turned out the customer had moved to a new domain since the last contact, and our client hadn't captured that. The exact name pass failed. The domain pass failed. The trigram match got the name close. The embedding passagreed. But the combined score, with the domain failing entirely and the name not matching cleanly, came in below the threshold.
The order was held.
Our client wasn't pleased. From their side the match was obvious — they knew the customer, they knew the order was real, and the parser had refused on the first one. They asked us to loosen the threshold. There was nothing structurally wrong with the order, it looked the same as many that have processed cleanly. From the client's perspective, the parser had failed arbitrarily.
The threshold isn't where it is because we don't trust the matching to be accurate on any given order. It's where it is because it has tobe the same threshold next month, on every order, from every customer the client processes. The trouble with moving it once is that it doesn't move once. The next conversation comes along, with its own fair reason, and the threshold moves a bit further. After a few rounds of this nobody can say what the rule is any more, because the rule is the most recent decision, and the most recent decision was made under whatever pressure was in the room that day.
Wrong-customer matches don't show up the day they happen. They show up weeks later, when a delivery goes short, or an invoice goes to the wrong place, or stock is allocated against a customer who didn't order it. By then the match that caused it is buried, and the threshold that let it through has been adjusted half a dozen more times for half a dozen more reasons that all sounded sensible at the time.
So the gate refuses some orders that, if a person looked at them, would match correctly. This one did. An operator looked at the heldorder, confirmed the customer was real, updated the record with the new domain and the cleaner version of the name, and the order went in attached to the right customer. The next order from this customer will go straight through, because the record now has the signals the parser is checking against.
The operator's job, on this part of the system, is to work the held queue. Resolve the cases the gate refused, and update the data so the next refusal is one worth having.
What we get from this, in exchange for the held orders and the awkward conversations, is something we can say plainly: no sales order in Workhorse is attached to a customer the system wasn't confident enough about.The threshold doesn't move, the rule applies the same way every time, and attached-to-the-wrong-customer isn't a thing that happens here.
A few things this gate doesn't do. It doesn't say anything about whether the line items are correct — that's a different decision with different failure modes, and the gate on that decision isn't as strong yet. We're still working through it. It doesn't say anything about whether the quantities are right, or whether the products requested are ones the customer has actually ordered before. The work we've done on customer matching doesn't carry over to any of that.
The shape of this gate works because of what's true about the decision it's making. Customer matching has a finite set of candidates to check against and a clear way to score them. Plenty of the other decisions on the surface don't, and the same shape won't carry. We've got one decision we can stand on, and a list of others we're still working out.