How should you use these twelve questions?
Ask them across two sessions rather than in one block, and ask them of the right people. Questions about price and approvals belong with a sales manager or a controller. Questions about products and warehouses belong with whoever owns the item master. Asking all 12 of one person produces confident answers about half of their business.
Each question maps to one of the 12 requirements that decide whether a native connector carries the client. One requirement holds natively, five strain, and six break. Ask the question, listen for the shape of the answer rather than for the content, and record which of the three columns the answer belongs in. You are not scoring the client. You are working out whether the commerce project you are about to quote is a configuration exercise or an integration programme.
A note on tone. These are blunt questions and they work because they are blunt. Every one of them can be answered by a non-technical person without preparation, which is deliberate: a question that needs the client to go and find out is a question that never gets answered.
The single question that predicts the most is number two. If the client cannot say how many customer-and-item combinations carry a negotiated price, nobody in the room knows how big the project is, including them.
The one requirement that holds natively
A standard catalogue with list pricing shipping from one warehouse is carried by the native Acumatica and Cin7 connectors without help. That client should buy the connector, theme a storefront, fix their product data and spend nothing on architecture. If the answers below come back clean, tell them so plainly. It is the most valuable thing you will say in the meeting and it is the reason they will believe you on the other 11.
Question one. "If I picked 10 of your customers at random and looked at the same item, would they all see the same price, and would that item ship from the same warehouse for every one of them?"
A good answer is an unhesitating yes, or a yes with a small number of percentage-discount tiers attached. That is a A price class is a label on a customer account that decides which set of prices they see. Acumatica and most ERPs use price classes so a seller can maintain one price list for a whole tier of customers instead of one per account. structure and every platform models it.
A bad answer is "mostly, with some exceptions". The exceptions are the project. Do not accept "mostly" and move on; ask how many exceptions there are and write the number down, because you have just been told the project is bigger than the client thinks it is.
The five requirements that strain
These are the ones the connector handles with configuration, rework or a supporting component. None of them is a reason to walk away. All of them are a reason to price differently, and each has a countable follow-up that turns an opinion into an estimate.
| Criterion | The question to ask | What a bad answer sounds like | What the bad answer costs |
|---|---|---|---|
| 2. Customer-specific and contract pricing | "How many customer and item combinations have a specifically negotiated price, and how many of those have a start or end date on them?" | "A fair few." "That is all in the price worksheets." "You would have to ask Dave." | It decides whether the storefront price is copied from a stored field or calculated per request. Acumatica’s community states that only the stock item Default Price is supported for the Shopify connector, so a contract customer sees list price unless a pricing service is built. |
| 3. Multi-warehouse allocation and honest promise dates | "When a customer phones and asks whether they can have 40 by Thursday, who answers that today, and what do they look at to answer it?" | "They ring the warehouse." "Kevin knows." | Availability is currently a person, not a field, so there is no number to publish. Expect a design exercise to define what the storefront may promise, before any integration work starts. |
| 4. Variant and option ceilings | "Take your most configurable product family. How many ways can it vary, and how many finished item codes does that produce?" | "Size, colour, length, and then the customer tells us the mounting." | Four dimensions is one too many for a Shopify template item sync, which fails where a family exceeds three product options, per Acumatica’s own community thread. The fix is product model rework or a platform whose limits fit the catalogue. |
| 5. Multi-currency selling | "Which currencies do you invoice in, and in each one is the price set by your team or converted at a rate?" | "We just convert at whatever the rate is that day." | A converted price is a calculation and a set price is a field. If prices are converted at order time, the storefront will disagree with the invoice unless the conversion is designed deliberately. |
| 6. High-volume order import with cross-reference collisions | "Do any customers order using their own part numbers rather than yours, and how many orders do you take on your busiest day?" | "Yes, and we look them up in a spreadsheet." "No idea, a lot at month end." | Acumatica does not verify the uniqueness of alternate IDs, and a lookup takes the first matching record, so duplicates produce wrong-item orders silently. Volume matters too: above roughly 500 synchronizations an hour, Acumatica’s own Commerce Edition team lead advised changing the connector configuration to batch preparation with hourly processing. |
Checked against: Acumatica community 17608: only Default Price is supported for the Shopify connector, Acumatica community 18873: template item sync fails where a family exceeds three Shopify product options, Acumatica community 5435: alternate ID uniqueness is not verified and a lookup takes the first record, Acumatica community 5392: synchronization configuration guidance above roughly 500 records per hour
The six requirements that break a native connector
A yes on any of these means the native connector alone will not carry the requirement, and that a component has to be built or bought to sit alongside it. That is not a disaster and it is not a reason to change ERP. It is a reason for the commerce project to be scoped as an integration programme with its own architecture, and for the estimate to stop being a storefront estimate.
Two of the six are worth chasing hard in the room, because clients answer them vaguely and the vagueness is expensive. Number 11 needs a customer name and a document. Number 10 needs to be asked about both sides, the client’s approvals and their customers’ approvals, because clients only ever answer about their own.
| Criterion | The question to ask | What a bad answer sounds like | What the bad answer costs |
|---|---|---|---|
| 7. Matrix, tiered and volume-break pricing | "Does the price per unit change with the quantity ordered, and is the break point the same for every customer?" | "Yes, and the big accounts each have their own break table." | Per-customer break tables mean price has to be resolved at request time. This is the single most common reason an ERP-connected storefront needs middleware. |
| 8. Conditional attribute and metafield mapping | "Are there fields that only apply to some product types, and does the same field ever mean different things in different categories?" | "Field 12 is the voltage for electrical and the thread pitch for fasteners." | A transformation layer, plus a governance problem. Reused fields cannot be mapped once; they have to be mapped per category and re-checked whenever a category is added. |
| 9. Multi-store, multi-brand or multi-region storefronts | "How many brands, regions or divisions would eventually need their own storefront, and do any of them share a customer?" | "We would start with one and add the other two next year." | Next year is an architecture decision made today. On Shopify below Plus you can assign up to three active catalogues across all B2B markets, so a client with several price classes and a second brand runs out of catalogues before they run out of ambition. |
| 10. Quote-to-order and approval workflows | "Before an order becomes an order, does anybody have to approve it, either on your side or on the customer’s side?" | "The rep checks it." "Their purchasing manager signs off the big ones." | Both answers describe a workflow that does not exist in any system today. Order approval is a workflow where a buyer builds an order and somebody else at their company authorizes it before it is submitted. The rule is usually a spending threshold, a cost centre, or the buyer’s role. on the buyer’s side needs A company account is a customer record that holds several people, each with their own login and their own permissions. One buyer might place orders, another might only approve them, a third might only look up past invoices. structure and roles; approval on the seller’s side is usually a quote process wearing a different name. |
| 11. Punchout and EDI-driven buyers | "Has any customer asked you to appear inside their procurement system, or to exchange documents rather than emails?" | "Somebody mentioned Ariba once." "It came up in a review meeting." | Chase this to a customer name and a document before the platform shortlist is written. A Punchout is a way for a buyer to shop on a supplier’s website from inside their own procurement system. The buyer clicks out, builds a cart, and the cart is returned to their system as a requisition for approval. or EDI, or electronic data interchange, is a long-established set of standard message formats businesses use to exchange purchase orders, invoices and shipping notices system to system. Large retailers and distributors often require it from their suppliers. requirement changes which platforms qualify, and it is the requirement most often discovered after the platform is signed. |
| 12. Configurable and made-to-order products | "Is there anything you sell that does not exist until somebody orders it?" | "We make to order, but it is all fairly standard really." | A A configurable product is one the buyer specifies rather than picks off a list, such as a machine built to order from a set of options with rules about which options can go together. The final part number and price may not exist until the configuration is finished. needs a configurator and a rules engine tied to the ERP, and the phrase "fairly standard" usually means the rules live with two people and have never been written down. |
Checked against: Shopify Help Centre, B2B catalogs: up to three active catalogs across all B2B markets on Basic, Grow and Advanced; unlimited and directly assignable on Plus. Read 20 August 2026, Shopify changelog, 2 April 2026: key B2B features available on non-Plus plans, with the catalog limit stated
The twelve questions on their own, to lift into your own document
This is the version to paste into your discovery template. No commentary, in the order to ask them, phrased the way to say them out loud.
If I picked 10 of your customers at random and looked at the same item, would they all see the same price, and would it ship from the same warehouse for every one of them?
How many customer and item combinations have a specifically negotiated price, and how many of those have a start or end date on them?
When a customer asks whether they can have 40 by Thursday, who answers that today, and what do they look at to answer it?
Take your most configurable product family. How many ways can it vary, and how many finished item codes does that produce?
Which currencies do you invoice in, and in each one is the price set by your team or converted at a rate?
Do any customers order using their own part numbers rather than yours, and how many orders do you take on your busiest day?
Does the price per unit change with the quantity ordered, and is the break point the same for every customer?
Are there fields that only apply to some product types, and does the same field ever mean different things in different categories?
How many brands, regions or divisions would eventually need their own storefront, and do any of them share a customer?
Before an order becomes an order, does anybody have to approve it, either on your side or on the customer’s side?
Has any customer asked you to appear inside their procurement system, or to exchange documents rather than emails?
Is there anything you sell that does not exist until somebody orders it?
What do you do with the answers?
Count them, in two columns. Column one is strains, questions two to six. Column two is breaks, questions seven to 12.
No breaks and no more than one strain means the native connector carries the client. Quote a connector configuration, a themed storefront, a catalogue data exercise and order flow testing, and keep the work. This is the most common outcome and it should be the most common outcome, because if your framework never produces it then your framework is a sales tool.
No breaks and two or more strains means the connector still carries it with a supporting piece: configuration work on pricing, a product model rework, or a queue in front of the order import. Keep it, and price the supporting piece as its own line rather than folding it into the storefront number.
One break means the project needs one designed component and someone who has built that component before. Whether you keep it depends on whether that someone works for you. Two or more breaks means the commerce project is an integration programme, the platform decision is subordinate to the architecture decision, and quoting it as a storefront build is how partners lose a quarter.
Whatever the count, the countable follow-ups are what turn this into an estimate. Get the number of negotiated price rows, the number of price classes, the peak orders per day, the item count and the count of duplicate cross-references. Five numbers, an afternoon of somebody’s time, and the difference between a quote and a guess.
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Which of the twelve questions matters most?
- Question two: how many customer and item combinations carry a specifically negotiated price, and how many of those have dates on them. It decides whether the storefront price can be copied from a stored ERP field or has to be calculated when the page loads, and a calculated price is a service with a cache, an invalidation strategy and a defined behaviour when the ERP is unreachable. Every other answer changes the estimate; this one changes the architecture.
- Can I ask all twelve in one discovery call?
- You can, and you will get confident answers about half the business. Pricing and approvals belong with a sales manager or a controller, products and warehouses belong with whoever owns the item master, and procurement demands belong with whoever handles the largest accounts. Two shorter sessions with the right people produce better answers than one long session with whoever was free.
- What if the client answers "mostly" to the first question?
- Then the exceptions are the project, and the next question is how many exceptions there are. "Mostly standard, with some exceptions" is the single most reliable signal that a commerce project is larger than the client believes, because the exceptions are the part nobody has counted. Ask for a count of customer-and-item combinations with a negotiated absolute price before you agree to anything else.
- How do I ask about punchout without teaching the client to want it?
- Ask it as a question about their customers rather than about technology: has any customer asked you to appear inside their procurement system, or to exchange documents rather than emails. That phrasing catches Ariba, Coupa, SAP and EDI without naming any of them, and it does not plant a requirement. Then chase any vague yes to a customer name and a document, because vague punchout answers become firm punchout deadlines after the platform is signed.
- Do these questions work for a Cin7 client as well as an Acumatica one?
- All twelve do. The evidence differs, because the limits differ: on Cin7 Core the pricing questions run into up to 10 price points per product plus custom pricing per customer, and the multi-store question runs into what the B2B portal presents. The requirements themselves are properties of how the client sells, not of the ERP, which is why the same script works and why the answers point to different solutions.
- What should I do if the answers say the client does not need a commerce project at all?
- Tell them, and be specific about why. A client whose customers phone because they like phoning, whose catalogue is small and whose pricing is a list with two tiers, does not have a deflection problem worth solving with a storefront. Saying so costs you a quote and buys you the position of the supplier who tells the truth, which is worth more at the next renewal than the quote was.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.