When the storefront underperforms, the ERP renewal takes the blame

Through the client’s vocabulary, not through their logic. Nobody at the client says "the storefront’s product search is returning poor results because the item descriptions are 40 characters long". They say "we can’t find anything since the new system went in". The new system is the one with your name on the invoice.

Three things make this worse in an ERP-connected build specifically. The ERP is the newest large expense, so it is the salient change. The ERP is where the data comes from, so any data-shaped complaint points at it honestly enough to be believed. And the ERP renewal is an annual decision with a number attached, so it is the moment when accumulated dissatisfaction has somewhere to go.

The mechanism is not that clients are unfair. It is that nobody has given them a way to tell the two apart, and by renewal time the distinction is a year old and nobody kept notes. Giving them that way, before launch, is entirely within your control and costs almost nothing.

Four sentences show up again and again, and each has a diagnosis that has nothing to do with the ERP licence the client is deciding whether to renew.

"The prices are wrong on the website." This is usually a design gap rather than a defect. Acumatica’s own community states that only the stock item Default Price is supported for the Shopify connector, so a contract customer sees the list price unless something else was built. If the scope document did not say which price the storefront would show, the client experiences this as an error rather than as a decision they signed off.

"The stock numbers are wrong." Usually a latency or a calculation-basis question rather than a wrong number. Connector synchronization on Acumatica is prepared and then processed on a scheduler, so a figure on a page is as fresh as the last processing run, and the availability figure the ERP publishes may not be the one a salesperson would quote.

"Nobody can find anything." Almost always product content. The item master was built for people who already know the part number.

"Orders come through wrong." Usually a specific, findable behaviour, such as taxes being recalculated on an imported order, which Acumatica’s community has a thread on. Findable, fixable, and completely invisible to the client as anything other than "the system is wrong".

Six measures. All of them can be produced by the systems you are already installing, none needs an analytics practice, and the value of every one of them is that it exists before launch rather than after the complaint.

The one that does the most work is the first. An order acceptance rate near 100 percent, measured daily, retires the entire class of "the system loses orders" complaints with a chart instead of an argument, and it catches genuine faults early enough to fix them quietly.

Run the same four checks in the same order, every time, in front of the client. The order matters because it moves from cheapest to most expensive, and because the first two answer most complaints.

Start with the record. Take one specific transaction the client is unhappy about and follow it end to end with the correlation identifier: what the storefront sent, when the integration prepared it, when it processed, and what the ERP recorded. A complaint that survives contact with one real transaction record is a genuine defect. Most do not survive.

Then check whether the behaviour matches the design. If the storefront is showing a list price to a contract customer and the scope document says the storefront publishes the stock item Default Price, the system is doing what was agreed and the conversation is about scope rather than about quality. This check is the reason to write that sentence into the scope document in the first place.

Then check timing. Compare the published figure with the ERP figure at the same instant and record the age of the last successful sync. A stock number that was right an hour ago is a latency conversation with a threshold and a cost attached, not a correctness conversation.

Only then look at merchandising and content. Search results, category structure, images, descriptions, and the reorder path. This is where the real answer usually is, and it is the last place anyone looks because it does not feel like a system problem.

Three agreements, in writing, in the go-live document rather than in the contract, so that they read as project hygiene rather than as a partner covering itself.

Agree the definition of success as one number with a date. Something like: storefront order lines as a share of total order lines, reviewed at three, six and 12 months, with a target the client sets themselves. A client who has named the number will argue about the number rather than about the ERP.

Agree the defect ledger and its categories. Every reported issue gets recorded as an integration defect, a configuration item, a data item, or a merchandising item, and the ledger is reviewed monthly with the client in the room. By renewal the ledger is the record of what actually happened, and it will not match anyone’s memory.

Agree who presents the number. It should be someone at the client, not you. A number the client’s own team presents is evidence; the same number presented by the supplier is marketing, and everyone in the room knows the difference.

Say so early and specifically, and be the party that says it first. A partner who arrives with "our order acceptance rate is 99.8 percent, the price mismatch count is zero, and the zero-result search rate is 31 percent, so this is a content problem and here is what it costs to fix" has changed the meeting from a complaint into a plan.

Where the storefront design or platform choice was genuinely wrong, the cheapest honest path is usually not a rebuild in year one. It is to keep the platform for the range it serves and move the specific failing requirement somewhere it can work, then revisit the platform when the contract comes up anyway.

And if the wrong recommendation was yours, own it faster than feels comfortable. The renewal is decided on whether the client trusts your account of reality, and a partner who names their own mistake before the client does keeps that trust. A partner who is still explaining in month 11 does not.