var framework

How Acumatica VARs qualify a commerce opportunity

Most commerce opportunities don't arrive labelled as commerce. They show up as an ERP complaint: order entry is slow, reps are re-keying, the configurator only produces text, wrong orders keep shipping. Qualifying one means hearing the signal, checking whether native connectors already cover it, and, when they don't, bringing in a commerce specialist instead of stretching into scope you don't staff for. Do that and you keep the ERP relationship you earned.

The client almost never opens with "we need commerce." They open with a complaint about the ERP, and they believe it. A rep spends an afternoon re-keying an order that came in on a spreadsheet, or a configured product ships wrong for the third time this quarter, and the request that lands on your desk is to fix Acumatica. Sometimes that's right. Often the ERP is doing exactly what it was built to do, and the gap is somewhere it was never meant to reach.

The signals a commerce opportunity is hiding in the conversation

Listen for the moment an ERP request is really about how the customer buys, configures, or receives orders. These are the tells:

1. Re-keying and swivel-chair work: someone is entering the same order into two systems, or copying between a storefront, a spreadsheet, and Acumatica.
2. A configurator that produces text, not a validated build: the ERP can capture configured-order data but can't stop an invalid combination, so wrong orders get through.
3. Orders that arrive on paper, by email, or by phone: manual intake at volume means there's no buying experience, just a back office absorbing the work.
4. Pricing the storefront can't show: customer-specific prices, contract pricing, or volume breaks live in Acumatica but the online experience can't surface them per buyer.
5. B2B and B2C on one ERP: multiple domains, company accounts, and buyer hierarchies usually outgrow a packaged storefront's defaults.
6. "We're losing deals on experience": the product is competitive but the buying experience isn't, and customers are choosing on what they can see.

Any one of these is worth a closer look. Two or more, and you're almost certainly looking at commerce work, not an ERP tweak.

The disqualifiers: when it isn't a commerce project yet

Not every signal is an opportunity, and recommending a build the client doesn't need is how you lose trust. It's probably not a commerce project when:

1. A native connector already covers it. If the customer sells in standard ways through BigCommerce, Shopify, or Amazon, Acumatica's built-in connectors may be all they need. Shopify B2B already syncs customer-specific and tiered pricing and captures purchase orders at checkout.
2. The real problem is in the ERP data. If pricing or inventory isn't modelled correctly in Acumatica, fix that first. No storefront rescues pricing the ERP can't calculate.
3. There's no volume and no roadmap. A handful of manual orders a month with no growth plan rarely justifies a build.

Naming these honestly is part of qualifying. It also makes the client trust you when you do say there's a real opportunity.

Qualify before you recommend a platform

Before you put a platform on the table, check the fit. Run the customer's site through Celeste, Acro's architecture diagnostic. It reads the site and flags fit, risks, and integration gaps in minutes, and it's the same diagnostic behind Acro's Acumatica evaluation work. You walk into the conversation with a defensible read instead of a guess, and you avoid recommending a platform the business will outgrow or over-buy.

The play: bring in a commerce specialist, keep the ERP

When the opportunity is real and it's past what a connector can do, you have three options: staff up for commerce, hand the relationship to someone who might not give it back, or refer in a specialist and stay the lead on the ERP. The third grows the account without the risk.

Aktion Associates already ran Lustre Products' Acumatica. Lustre makes custom elevator handrails and safety barricades, and about 85% of orders came in on a 25-column paper worksheet that had been the standard for 35 years. The ordering problem was real, but it wasn't an ERP problem: Acumatica could store the order; it couldn't validate a visual configuration or give customers a buying experience. Aktion didn't stretch into unfamiliar scope or hand off the relationship. They brought Acro Commerce in, stayed the lead on Acumatica, and grew the ERP work the project created: custom tables, two entities for US sales and Canadian manufacturing, and tax across both. Acro built the visual configurator, the headless Shopware storefront, and the Acumatica connector.

What you keep, what you hand off

The model works because the line between ERP and commerce is clean:

1. You own the ERP: the Acumatica data model and customizations, the entities and tax setup, editions, and the ongoing roadmap. Configurators and storefronts tend to create custom tables, entities, and tax work, so the ERP footprint usually grows.
2. The commerce specialist owns commerce: the configurator, the storefront and unified cart, the Acumatica connector, account-based pricing, and self-service order tracking. That's the work you'd otherwise have to hire for.
3. The client gets one outcome: one delivery, one team accountable for commerce, no two vendors pointing at each other.

Frequently Asked Questions

Next step

Get the foundation right before you build.

For readers scoping a platform decision or wanting a full architecture recommendation.