Why does a feature-list estimate go wrong?
Because features are roughly constant across clients and data is not. Two distributors can ask for exactly the same storefront, and the one with 60,000 items, 11 price classes and 40,000 customer-item contract prices is a project several times the size of the one with 900 items and a single price list. Nothing on the feature list distinguishes them.
The three lines that blow up a fixed price are catalogue content preparation, pricing architecture, and order data cleanliness. All three are properties of the client’s data. None is visible in a requirements workshop, because the people in the workshop describe the business they intend to run rather than the records they actually hold.
So the estimate splits naturally in two. Everything that depends on your method rather than on their data can be fixed-priced with confidence: connector configuration, storefront build, order flow testing, training, launch. Everything that depends on their data should be a priced discovery with a defined deliverable, and saying so is a credibility move rather than a hedge. Clients have been burned by suppliers who quoted confidently and re-quoted later.
Which six exports should you ask for, and what does each one tell you?
Ask for these before the second meeting. All six can be produced by a competent ERP administrator in an afternoon, none is commercially sensitive in a way an NDA does not cover, and a client who will not produce any of them has told you something useful about how the project will run.
If you only get one, take the third. The count of customer-and-item combinations carrying a negotiated absolute price, and how many of those carry effective or expiry dates, moves the architecture more than every other number combined.
| Criterion | What to count | What it changes |
|---|---|---|
| Stock item export with descriptions and attributes | Item count, how many items have a description shorter than 60 characters, how many have no image, attribute count per item class, and how many item classes exist. | The catalogue content line, which is the most underestimated line on these projects. Also tells you whether a product information tool is needed or whether the ERP can carry the content. |
| Customer export with price class, currency and ship-to countThis is the export that most often changes the platform recommendation rather than the estimate. | Number of distinct price classes, number of selling currencies, and the distribution of ship-to addresses per bill-to customer. | The catalogue and market structure. On Shopify below Plus you can assign up to three active catalogues across all B2B markets, so a client with seven price classes has an architecture problem the day they sign, not the month they launch. |
| Sales price worksheet or customer-item price export | Rows carrying an absolute negotiated price for a customer and item, and how many of those have an effective or expiry date. Then the same count for quantity-break rows. | Everything. This decides whether price is copied or calculated, and a calculated price is a service with a cache, an invalidation strategy and a defined behaviour when the ERP is unreachable. |
| 12 months of sales order lines | Orders per day at peak, lines per order, repeat rate, share of lines that are non-stock items or kits, and the share of orders entered by a customer service representative rather than a customer. | Integration design and the business case. Acumatica’s own Commerce Edition team lead advised that above roughly 500 synchronizations an hour the recommended configuration changes, with real-time sync disabled in favour of batch preparation and hourly processing. |
| Item cross-reference or alternate ID table | Duplicate alternate IDs mapping to more than one inventory item, and how many customers have customer-specific part numbers. | Order import risk and data cleanup scope. Acumatica does not verify the uniqueness of alternate IDs, and a lookup takes the first matching record, so duplicates are silently allowed and become wrong-item orders. |
| Warehouse and location list, with the online range mapped | How many warehouses feed the items intended for the storefront, and whether any customer is served from a specific branch by rule. | The availability design. A single company-wide figure is configuration. Branch-level availability is a build, and on BigCommerce it is a build regardless, because an Acumatica moderator has stated BigCommerce has no concept of inventory locations. |
Checked against: Shopify Help Centre, B2B catalogs: up to three active catalogs across all B2B markets on Basic, Grow and Advanced; unlimited catalogs and direct assignment to companies and locations on Plus. Read 20 August 2026, Shopify changelog, 2 April 2026: key B2B features on non-Plus plans, with the three-catalog limit assigned via Markets, Acumatica community 5435: "The system does not verify the uniqueness of alternate IDs in the system", Acumatica community 5392: synchronization guidance above roughly 500 records per hour, Acumatica community 5378: BigCommerce has no concept of inventory locations, per an Acumatica moderator
What do you do when the client will not send data?
Three fallbacks, in order of preference, and all three are better than guessing.
First, run the queries yourself on a screen share. Ask for 45 minutes with whoever administers the ERP and read the counts off the screen while they drive. Nothing leaves their building, no legal review is triggered, and you get the same six numbers. This works far more often than asking for exports does, because it removes the data-handling question entirely.
Second, ask for a redacted export. Item codes and customer names are the sensitive parts and you do not need either. Row counts, field lengths, distinct value counts and distributions are enough for an estimate, and a client’s IT team can produce those without a policy conversation.
Third, quote the discovery on its own with a fixed price and a named deliverable: the field ownership matrix, the pricing architecture decision, the catalogue readiness assessment, and a build estimate the client can take to any implementer including someone other than you. That last clause is what makes it sellable, and it is also true, which is why it works.
What none of the three is: quoting the build anyway with a long assumptions list. Assumptions lists do not protect anyone. The client reads the number, not the appendix, and the change order conversation happens at the worst possible moment in the project.
What can you honestly say about ranges without the data?
You can say a lot about proportion and almost nothing about absolute cost, and being explicit about that distinction is more persuasive than a confident number would be.
The proportions that hold up. On a distributor with tens of thousands of items and no product content owner, catalogue preparation is commonly the same order of magnitude as the integration build itself, and sometimes larger. A contract-pricing service is not a one-off line at all, because it adds a component with a permanent operational cost after go-live. Order flow testing is a fixed and predictable line that clients always want to cut and that always costs more to skip than to do.
What we are not going to publish is a dollar range. Rates, cost bases and market pricing vary widely between partners and regions, and a number invented on a webpage would be worse than no number, because someone would quote from it. We hold internal figures and they are not ours to publish here.
What you can give a client immediately, without data, is a shape: which lines are fixed, which are data-dependent, what each data-dependent line would need in order to become fixed, and what the discovery costs. That answer sounds like expertise. A single number with an assumptions appendix sounds like a guess, because it is one.
How do you write the estimate so it survives contact with the project?
Five drafting habits. They take an extra hour at quote time and they are the difference between a change order conversation you win and one you absorb.
The trigger conditions matter most. An estimate that says what specifically would cause a re-estimate, in countable terms, converts a later argument into an arithmetic check.
State the counts the estimate assumes: item count, price class count, negotiated price row count, peak orders per day, warehouse count. Put them in the body of the quote, not an appendix.
State the trigger conditions in the same units. "If the negotiated customer-item price rows exceed the stated count by more than 20 percent, the pricing line is re-estimated."
Name the exclusions as behaviours rather than as features. "Prices displayed to a signed-in customer are the stock item Default Price published from the ERP" is a sentence a client understands. "Advanced pricing not included" is not.
Put an expiry date on the quote, and make it shorter than the client’s decision cycle so a stale number is not held against you.
Include the catalogue content effort as a visible, separately priced line even when the client says they will do it themselves. Especially then. A visible zero that the client owns is far better than an invisible assumption you own.
Common questions
- What is the single most useful number to get before quoting a commerce project?
- The count of customer-and-item combinations carrying a negotiated absolute price, plus how many of those carry effective or expiry dates. That pair decides whether the storefront price can be copied from a stored field or has to be calculated per request, and a calculated price is a service with a cache, an invalidation strategy and a defined behaviour when the ERP is unreachable. Both counts can be pulled from Acumatica or Cin7 in an afternoon.
- Can I quote a commerce attach off a demo of the client’s current website?
- You can quote the storefront from it and nothing else. The website shows you what the client sells and how they present it, and tells you nothing about item count in the ERP, price class structure, contract price volume, cross-reference duplicates or order volume, which are the five things that actually move the estimate. Quote the storefront fixed, and quote the rest after a paid discovery or a screen-share data review.
- How do I price a discovery a client will actually buy?
- Fix the price, fix the duration, and name deliverables the client owns and can take elsewhere: a field ownership matrix, a pricing architecture decision, a catalogue readiness assessment, and a build estimate any implementer could quote against. The transferability is what makes it sellable, because it removes the fear of paying for a sales document. It is also what makes it worth buying, which is why the claim survives being tested.
- The client says their data is clean. Should I believe them?
- Believe that they believe it. "Clean" in an ERP context means the records support the operation, and commerce asks a different question of the same records: whether a stranger could identify the product without asking. Ask for the count of items with a description under 60 characters and the count of duplicate alternate IDs. Both are objective, both take minutes, and both usually settle the conversation without anyone having to be wrong out loud.
- Should catalogue content be in my scope at all?
- It should be in the quote as a visible line even if the client owns it. Content is the most common reason these projects slip, and an invisible assumption that the client will handle it becomes your delay when they do not. Price it, show it, and let the client take it out deliberately. A line item the client removed on purpose is a different conversation at month six from an assumption nobody discussed.
- Why not just give a range?
- Give a range for the parts that depend on your method, which is most of the build, and refuse one for the parts that depend on data you have not seen. A range offered without data is anchored to the low end by the client and to the high end by nobody, so you have effectively quoted the low end. Saying "I can price the storefront today and I need two counts before I can price the pricing work" is a stronger position than any range.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.