Which of three questions are your customers actually asking?
Put a tally sheet next to the phone for a week or until you’ve twenty calls, whichever comes first. Three boxes, one tick each, plus one note. The three boxes are: can I have it at all, when can I have it, and where is it. The note is what the caller would have needed to see to avoid calling.
These aren’t the same question and they don’t have the same fix. A caller asking whether it exists is served by a stock indicator. A caller asking when is served by a promise date, which requires purchase order and production data your storefront probably doesn’t have. A caller asking which branch is served by location-level availability, which is the one most connectors handle worst.
Twenty calls is enough because the distribution is usually lopsided. If sixteen of your twenty are the first question, you’ve a publishing problem and it’s solvable this quarter.
| Criterion | What the caller asked | What it means | What to do |
|---|---|---|---|
| “Do you have any?” | The caller wants a yes or a no before committing to an order or quoting their own customer. | You’re publishing nothing, or you’re publishing something the caller doesn’t trust. Either way this is the cheapest of the three to fix. | Publish an availability state rather than a raw number: in stock, low, available to order. Banding is easier to be right about and easier to live with. |
| “When can I have it?”This is the row that tells you a stock indicator alone won’t stop the calls. | The caller accepts that it is out of stock and needs a date they can give their own customer or their crew. | A promise date question. Your stock number, however accurate, doesn’t answer it, and neither does any commerce platform on its own. | Publish expected receipt dates from purchase orders or work orders, or say plainly that dates come from a person. Don’t answer a date question with a quantity. |
| “Which branch has it?” | The caller wants to collect today, or wants to know whether it ships from the depot two hours away or the one four provinces away. | A multi-warehouse problem. One aggregate number is actively misleading here, because a total that includes stock in another region reads as a promise you can’t keep. | Decide the display strategy per warehouse before you publish. This is a modelling decision, not a setting. |
| “Is that number right?” | The caller is looking at your website while they phone, which is the worst outcome of publishing. | You already publish and they don’t believe you. Publishing more won’t help until the number is correct. | Run the accuracy check below before touching anything else. This is a data problem wearing an ecommerce problem’s clothes. |
Is the number you would publish actually correct?
Run this before you commit to any project, and run it on your twenty fastest-moving items rather than on a sample chosen for convenience. For each item, write down three figures at the same moment: the on-hand quantity in your ERP, the available quantity after allocations and commitments, and the number your storefront shows or would show.
If the storefront number matches on-hand rather than available, you’re publishing stock you’ve already promised to somebody else, and you’ll oversell. This is a field mapping problem, and Acumatica’s own community has a documented case of the Shopify connector setting the wrong availability because of unassigned commitments, so it’s a known shape rather than a theory.
If the three numbers agree and you still wouldn’t be comfortable putting the figure on a public page, you’ve learned something more useful: the fix is not real-time availability, it’s a safety stock buffer and a banded display. Publishing a band you can defend beats publishing a number you’ve to explain.
And if the item is a kit, a matrix item or a non-stock item, expect all three numbers to disagree, because the availability of an assembled or configured item is a calculation rather than a stored quantity. Handle those separately and don’t let them stall the rest of the catalogue.
Checked against: Acumatica community 30078: connector not setting correct available due to unassigned commitments, Acumatica community 5378: handling a multi-warehouse setup with BigCommerce
What does one aggregate stock number actually cost you?
A single total across every warehouse is the default that most connectors produce, and it’s wrong in both directions at once. It promises stock in a region you won’t ship from economically, and it hides stock that a customer standing at your counter could have collected today.
The commercial cost shows up in three places that rarely get connected to the stock number. Orders that ship from the wrong site and eat their own margin in freight. Will-call customers who phoned rather than driving over, because the site couldn’t tell them the local branch had it. And promise dates given by a rep who trusted the total and then had to phone back.
The Acumatica community thread on multi-warehouse setups with BigCommerce is worth reading before you decide, because the practical answers in it are about how you choose to model the problem rather than about a setting to switch on. There’s also a documented trap in changing a warehouse-to-location mapping after items have already been exported, so decide your model before you publish rather than after.
Checked against: Acumatica community 6261: changing warehouse to location mapping after export, Acumatica community 5378: multi-warehouse setup with BigCommerce
When should you publish nothing at all?
Publishing availability is not always the right answer, and a page that only argued for it would be a sales page. Four cases where the honest move is to publish no quantity.
In every one of those cases the calls don’t stop, and that’s the correct outcome. What you can still do is remove the reason for the call from the other direction: a rep who can answer in ten seconds because the answer is on one screen is a better fix than a website number nobody believes.
You make to order. A quantity is meaningless and a lead time is the real answer, so publish the lead time and say it is indicative.
Your stock accuracy hasn’t been measured in the last year. Publish nothing until you’ve counted, because the first wrong number destroys more trust than the tenth right one builds.
Your competitors would use your quantities. This is a real consideration in some categories, and banding rather than exact counts is the usual compromise.
Your items are lot or serial controlled and customers care which lot. The number is not the question they’re asking, and a quantity answers it misleadingly.
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Should we show an exact quantity or a status like in stock?
- Bands are safer and are what most mid-market distributors settle on. An exact quantity invites the customer to order exactly that amount at the moment your number is stalest, and it exposes information you may not want public. A band such as in stock, low stock, or available to order tolerates a few minutes of latency without ever being wrong. Exact quantities earn their keep mainly when buyers are ordering full pallets and the difference between 40 and 60 changes their decision.
- How fresh does the stock number need to be?
- Freshness matters less than the field being right. A nightly figure of true available stock is more useful than a real-time figure of on-hand stock that ignores allocations, because the second one oversells and the first one doesn’t. Once the field is correct, set the refresh interval by how fast your fastest item moves rather than by what the connector defaults to, and consider a safety buffer on the small number of items that turn several times a day.
- Can Shopify or BigCommerce show stock per warehouse?
- Both model multiple locations, and the constraint is usually what the connector sends rather than what the platform can hold. The question to ask your integrator is which Acumatica or Cin7 warehouses map to which storefront locations, what a customer sees when their assigned warehouse is empty and another is full, and what happens if you change that mapping after items have already been exported. Acumatica community 6261 documents the last one as a real trap.
- Our customers ask for a delivery date, not a quantity. What do we publish?
- Publish the expected receipt date from the purchase order or work order, and label it as expected rather than promised. That data lives in your ERP and is rarely part of a standard connector scope, so treat it as an integration item to be specified rather than a checkbox. If you can’t get the date reliably, saying that dates come from a person is more honest than a calculated date you’ll miss, and it keeps the conversation where you can still win it.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.