How to qualify a commerce opportunity inside an ERP deal

You usually spot it before the client says the word "ecommerce", and the tells are operational rather than technical. Someone in the room describes an order desk that keys the same repeat orders every month. Someone mentions a spreadsheet a customer emails in. Someone says a large account has been "asking about their portal". A CSR is copied on every quote. Any of those means there is a channel project attached to your ERP deal, whether or not it has a budget line yet.

Two of those signals are worth more than the rest. The first is a named customer making a demand: a procurement team asking you to appear in Ariba or Coupa, or a retailer asking for EDI. That is a funded requirement with a deadline attached, and it will outrank the client’s own roadmap. The second is order desk volume that scales with revenue, because that is the business case writing itself. A client who has to hire another CSR for every few million in growth is a client who will pay for deflection.

The signal that means the least is a client saying their website looks dated. That is a design project, and it will not survive contact with the ERP budget. Note it and move on.

One practical habit. When you hear any of these, ask what the customer would do on the website that they cannot do today. If the answer is specific, such as check their price, see their stock, reorder from history or download an invoice, you have a real project. If the answer is a general sense that they should have one, you have a conversation, and treating a conversation as a pipeline entry is how partners end up scoping for free.

Three questions separate a configuration project from a development project, and you can ask all three in a discovery call without a technical person present. They are deliberately blunt because their value is that a controller or a sales manager can answer them without preparation.

Ask whether the price of an item depends on who is buying it. If the answer is that some customers get a percentage off a list price, that is a tier, and every platform models tiers. If the answer is that specific customers have specific prices on specific items, often with dates, that is contract pricingContract pricing is a price that applies to one customer or one group of customers rather than to everyone. In B2B it is normal for the same product to have a different price for every account on the book. and it is the single most common reason a native connector fails to deliver what the datasheet implied. Acumatica’s own community, asked directly about syncing the effective sales price to Shopify rather than the stock item Default Price, answered "No. Only Default Price is supported."

Ask whether availability depends on which warehouse serves the customer. A single company-wide number is a configuration. Branch-level or customer-specific availability is a build, and on BigCommerce it is a build regardless of how you feel about it, because BigCommerce has no concept of inventory locations. Acumatica’s own moderator says so in the community thread on multi-warehouse setups.

Ask whether any customer has already required punchout, EDI or a hosted catalogue. This one is binary and it changes the platform shortlist rather than the effort estimate, so asking it late is expensive. It is also the question clients most often answer with "somebody mentioned something", which is worth chasing to a name and a document.

Most of them. That is the honest answer and it is worth stating before the disqualifiers, because a qualification framework that funnels everything to a specialist is a lead generation form with extra steps.

A large share of commerce projects attached to an ERP deal are a native connector, a themed storefront, a catalogue data exercise and a fortnight of order flow testing. You already own the ERP relationship, you already know their item master, you already know how their orders post, and you know which of their processes are fragile. A specialist arriving cold would spend three weeks learning what you know today. On that project you are the better provider, and bringing in a partner adds margin dilution and a coordination cost for nothing.

The keepable shape has a recognisable profile. If a prospect ticks most of the list below, quote it, build it, and treat the commerce work as an extension of the implementation rather than as a different discipline.

The one thing to add even on a simple project is a written statement of what the connector does not do. Acumatica’s marketing page for the Shopify connector advertises customer-specific pricing synchronized to Shopify, and the community answer about Default Price sits alongside it. You do not need to litigate that gap. You do need your scope document to say which prices will appear on the storefront and where they come from, because that sentence is what protects you at user acceptance testing.

These are the ones where keeping the work costs you more than referring it, and the cost usually lands as an over-run rather than as a failure. A project that runs well past its fixed price loses money and occupies your best consultant during the quarter you needed them on ERP delivery.

The first is contract pricing at volume with dates attached. Once the effective price has to be calculated per request, you are building and operating a pricing service, with a cache, an invalidation strategy and a defined behaviour when the ERP is unreachable. That is a different practice from ERP configuration, and the ongoing operational load does not end at go-live.

The second is a punchout or EDI requirement from a named account. It is not that punchout is unusually hard. It is that the buyer’s procurement team sets the specification, the testing cycle runs on their calendar, and a missed date has a revenue number attached to it. Take that on only if you have done one before.

The third is a client who has already bought a platform that cannot do what they need. That project starts with a conversation nobody wants to have, and if you are the one who inherits it you will also inherit the blame for the previous decision. It is deliverable, but scope it as a rescue with its own discovery, not as a build.

The fourth is quieter and it is the one partners most often miss. If the client has no one who owns product data, the project will stall in content rather than in code. A distributor with 40,000 terse manufacturer descriptions and nobody assigned to fix them will launch a storefront where search does not work, and the post-mortem will name the platform. Qualify for a data owner as seriously as you qualify for budget.

The fear is reasonable and it is worth naming: a commerce partner arrives, becomes the client’s favourite supplier, and starts having opinions about the ERP. It happens. It happens less when the shape of the engagement is agreed before anyone is introduced to the client.

Three things settle it, and all three belong in writing before the first joint call. Agree who owns the client relationship and who is on the invoice. Agree the boundary of the work in terms of systems rather than in terms of tasks, because task boundaries blur within a fortnight while system boundaries hold. Agree who the client escalates to when something breaks after go-live, since ambiguity there is what turns a good referral into a bad one.

The boundary that works most often is the ERP-side line. You own everything inside Acumatica or Cin7: the item master, pricing setup, order types, the customer records, the workflow. The commerce partner owns the storefront and the integration layer, and they ask you for ERP changes rather than making them. That keeps your configuration under your control and gives them a clear interface to build against.

On positioning to the client, the sentence that works is not defensive. Something close to: "the ERP side of this is ours, and for the pricing logic we are bringing in a team that does this shape of integration all the time, because it will cost you less than us learning it on your project." Clients respond well to that, because it is what they would want a supplier to do with their money. Partners who try to hide the referral get found out at the first technical call.

Answer the question they asked, which is almost always narrower than the one they voiced. "Will the connector do it" is really "will the connector show my customers their prices and my stock". Answer that specifically and you keep the credibility to be believed on the harder parts.

The formulation that works: the connector will keep products, stock quantities, customers and orders in step reliably, and that is most of the value. What it will not do is calculate a price. Acumatica publishes the stock item Default Price to the storefront, so if a customer has a negotiated price the website will show the list price unless we do something else about it. Then ask how many customers that affects, and let the number make the decision rather than making it for them.

Avoid two moves. Do not tell a client the connector is bad, because it is not and you will be arguing against a product from a vendor you both partner with. And do not promise the gap can be closed with configuration, because it cannot, and that promise gets tested at user acceptance testing with the client’s largest account looking at the screen.

If you want the client to verify it independently rather than take your word for it, tell them to load one real contract customer and one item with a negotiated price into a sandbox and look at the product page while signed in as that customer. That test takes an afternoon, it settles the argument without anyone selling anything, and it makes the scope conversation afterwards much shorter.