The ERP blind spot: why reps promise what the warehouse can't deliver

A rep visiting a fabrication shop outside Rajkot is asked whether forty units can ship by month-end. A rep calling on a distributor in Milwaukee is asked the same thing about a different part. Neither can see the answer. Both say yes.

They are not being reckless. They are being useful, under uncertainty, in a conversation where “let me check and come back to you” costs the momentum of the visit. The cost of that yes appears three weeks later, in someone else’s budget.

What the blind spot looks like from each side

From sales: the CRM knows the customer and the opportunity. It does not know whether the item exists, when it could exist, or whether this account is on credit hold. Those answers live in the ERP, which the rep cannot open — because the license was never bought, because the interface was designed for a planner, or because opening it would expose finance data that sales has no business seeing.

From operations: an order arrives with a promised date nobody in the plant agreed to. The date is now a commitment to a customer, so it gets met the expensive way — expedited freight, a production reshuffle, a partial shipment — or it gets missed.

Neither function is behaving badly. The information architecture forces the outcome.

The costs, in the order finance notices them

Expediting. The most visible and the least important, because it is at least recoverable. A promised date defended with air freight or overtime shows up cleanly in the P&L, which is why it is usually the number that starts the project.

Partial and split shipments. Two deliveries where one was priced, extra handling, extra paperwork, and an invoice query that consumes someone’s week.

Credit surprises. An order taken against an account that was already on hold. The deal is now sitting between sales, finance and the customer, and everyone involved is annoyed.

Credibility. The one that matters and the one nobody books. Industrial buyers plan around your dates. Miss twice and the buyer does not complain — they dual-source. That decision is quiet, permanent, and made without a meeting.

Why “just ask operations” stopped scaling

It works when a territory has ten accounts and the planner sits fifty feet away. It fails when the rep is mobile, the plant is in another state, and the question is one of thirty that day. Each ask is a context switch for the planner and a delay for the customer, so reps ration their questions — and the rationing is exactly where the unverified promises come from.

The pattern is identical to the one that stalls CRM adoption. When the accurate path is slow and the inaccurate path is instant, volume flows to the inaccurate path regardless of what anyone was told in training.

What a fix actually looks like

Read-only, scoped, at the point of conversation. The rep does not need the ERP. They need three fields — available quantity, realistic lead time for this configuration, account credit status — reachable in the moment, from the surface they are already using. In a Microsoft estate that is a Graph connector or a dual-write integration surfacing those fields into Dynamics 365 or into Teams. Elsewhere it is an API-backed layer over whatever ERP is in place.

Honest lead times, not theoretical ones. The number in the master data is frequently the standard lead time, not the current one. A quoted date built on a stale planning parameter is unverified in a more sophisticated way. If the ERP cannot express current reality, exposing it to sales spreads the error faster.

A recorded promise. Whatever date the rep gives should be captured on the opportunity, so the gap between promised and actual can be measured. Without that number the blind spot cannot be argued about with evidence, only anecdote.

The two markets

For US firms on SAP, Business Central or a comparable platform, this is largely an integration and licensing exercise. The APIs exist; the obstacle is usually cost allocation and a security review.

For Indian mid-market manufacturers the estate is messier. Tally or a regional ERP may hold the financials while production reality lives in spreadsheets, and dealer stock — often a large share of what a customer could actually receive — sits outside any system the manufacturer owns. Here the honest first step is narrower: get the rep a reliable answer on factory stock and standard lead time, and stop pretending the dealer layer is visible until it is.

The three fields, precisely

Scoping this narrowly is what makes it approvable. Sales does not need the ERP; it needs three answers, and naming them turns a stalled platform discussion into a small integration.

Available to promise, not on hand. On-hand quantity is the number most projects expose first and it is the wrong one. It ignores what is already allocated to other orders, so a rep sees forty units, promises forty units, and discovers that thirty-two are committed. Expose available-to-promise, or expose on-hand alongside allocated and let the rep see both.

Current lead time, not the master-data default. The lead time held against an item is usually the standard planning parameter, set once and rarely revisited. If the plant is running four weeks behind on a product family, the ERP may still report the standard two. Exposing a stale parameter to sales does not close the blind spot; it industrializes the error and makes it faster. Where current lead time cannot be derived, show the standard figure explicitly labeled as standard, so the rep knows to confirm before committing.

Credit status as a flag, not a balance. Reps do not need the receivables ledger and finance will resist showing it. A three-state flag — clear, approaching limit, on hold — carries almost all the operational value with almost none of the sensitivity, and it is usually the easiest part of the whole request to get signed off.

Notice what is absent from this list: cost, margin, and anything from the finance module. Keeping them out is what lets the security review say yes.

What operations gets out of it

The proposal lands better when it is not framed as sales asking for something.

Operations spends real time answering ad-hoc availability questions — each one a context switch for a planner who was doing something else. A read-only view removes most of that traffic. More importantly, it changes the shape of what arrives: instead of orders carrying dates that were invented in a customer’s office, orders arrive carrying dates the system itself produced.

There is a second-order benefit that planners tend to raise unprompted. When promised dates are captured on the opportunity, demand becomes visible earlier — before the order, at the quote. A pipeline of quotes with dates attached is a forecast signal that most industrial planning functions currently do not receive at all, because it lives in a CRM they cannot see. The integration that lets sales read the ERP is frequently the same integration that lets operations read sales.

That reciprocity is worth putting in the business case explicitly. A request framed as “give sales access to your system” competes for priority. One framed as “stop routing availability questions through a human, and see demand a month earlier” tends not to.

Where to start on Monday

Pull the last quarter’s orders and compare promised ship date with actual ship date. Segment by whether the rep could have verified availability at the time of the promise.

That comparison is the business case. It is usually larger than the integration project it justifies, and unlike most AI-adjacent proposals, both sales and operations will recognize it immediately.