“Add ecommerce” is often interpreted as putting a price and a buy button beside every product. That works when the choice is already clear. It creates expensive ambiguity when customers must identify an installed model, compare compatibility or confirm a delivery arrangement first.
The question is not whether the site has checkout. It is which customer decisions can safely become checkout now, and which need a different next step?
Three visitors, one fictional catalogue
Illustrative case: Mira supplies mechanical countertop label dispensers. Its products, specifications, customers and processes here are fictional, not an Aright project or real compatibility guidance.
Assume the manufacturer's supplied product record says:
- M2 accepts cartridge C2; M3 accepts cartridge C3.
- Both cartridges carry 50 mm-wide labels. Their cassette bodies and latches differ, and the supplied record explicitly says they are not interchangeable.
- The model identifier is on the underside of each dispenser.
- A standard single-cartridge order can use checkout only for an identified compatible model and a supported destination.
- A proposed trade request for 20 dispensers requires configuration, availability and delivery review before quotation. No trade price or delivery date has yet been promised.
A visitor who owns M2 needs C2. A new buyer comparing M2 and M3 needs the actual configuration differences, not an invitation to guess. A retailer considering 20 units needs a feasible offer, not twenty units silently taken from an assumed stock pool.
If the portal routes all three to the same generic product grid, checkout is being asked to compensate for an unfinished explanation.
Build around decisions, not departments
The first version can be small. It does not require a help centre with hundreds of articles or a customer account for every visitor.
| Visitor's task | What the portal must explain | Suitable next step | Evidence of completion |
|---|---|---|---|
| Replace a cartridge in an installed dispenser | Identify M2 or M3; show the corresponding cartridge and the incompatibility clearly | Identified M2 → C2 checkout; identified M3 → C3 checkout, subject to destination/availability | The selected model and cartridge remain correct in cart and order confirmation |
| Choose a first dispenser | Compare the supplied configurations, included parts and operating instructions | Compare the two models or ask a specific unresolved question | Buyer can explain the relevant difference without inventing an unsupported performance benefit |
| Request 20 dispensers for a store | Explain what is fixed, what the team must check and what a request does not reserve | Structured trade enquiry followed by human review | Request reaches its owner; the response establishes a quotation, a missing fact or an honest refusal |
These are different successful outcomes. A correct refusal of an incompatible cartridge can be better than another order. A well-formed trade enquiry can be progress without becoming revenue.
Google's ecommerce guidance recognizes that shoppers can seek more than product pages and describes several kinds of business and product information. It does not prescribe this portal or establish demand. The architecture above follows Mira's supplied product facts and service model.
Finish one useful replacement-part module
A complete customer-facing example could read:
Which cartridge fits your Mira dispenser?
Check the model identifier on the underside before choosing.
M2 → choose C2. C2 is the cartridge specified for M2.
M3 → choose C3. C3 is the cartridge specified for M3.
Both cartridges use 50 mm-wide labels, but their cassette bodies and latches differ. C2 and C3 are not interchangeable. Matching label width is not enough.
Cannot identify the model? Do not select by appearance or force a cartridge into place. Send the model marking and a photograph through the product-support route before ordering.
After identifying the compatible cartridge, confirm availability and delivery to your destination before payment.
The actual portal would need accurate photographs of the markings and a working support route. A dropdown that merely asks the customer to guess “M2 or M3” has not performed the identification task. Nor should a team invent a compatibility answer to eliminate a support contact.
The explanation should travel with the choice. If a buyer selects M2, then sees a cart title saying only “50 mm cartridge,” the confirmation has lost the very distinction the page established. Use the precise item identity in the selection, cart, order message, picking instruction and support history.
Make a quotation request different from a sale
Mira's trade module can be equally concrete:
Considering 20 dispensers? Request a trade review.
Tell us the model, quantity, intended use, delivery country/postal code and required timing. A sales coordinator checks configuration, available quantity and the delivery route before issuing a quotation.
This request does not reserve stock, confirm a price or guarantee a delivery date. We will identify missing information before asking you to accept an offer.
Internally, the coordinator must receive the request with those fields and the relevant product version. The response should not be a generic autoresponder saying “your order is confirmed.” Assign a real owner and an achievable response target before publishing one. An enquiry that sits in an unmonitored inbox is a broken product, even if the form submission event fires correctly.
Shopify's draft-order guidance provides one platform example of handling email or negotiated sales before payment. It distinguishes creating a draft/invoice from a paid regular order. That supports the distinction, not a recommendation to use a particular tool or a claim that Mira has implemented it.
Choose what not to build yet
A full portal, a lightweight decision site and a simple store are genuine alternatives. If a product has one unambiguous configuration and reliable standard fulfilment, a straightforward product page and checkout may be enough. If nearly every sale requires a project-specific assessment, a large public cart may add little value; the first investment should be the explanation and enquiry handoff. If repeat buyers already know their exact part, burying quick reordering behind a long consultation is another avoidable failure.
For Mira, start with the model-identification module, two accurate configuration pages, standard compatible-cartridge checkout and a trade-review route. Defer an elaborate account dashboard until a repeated customer task justifies it.
Test three paths before launch: a known M2 owner, an unidentified owner and a 20-unit trade prospect. Check whether each reaches the right action, whether the team receives enough information to respond, and whether an unsuitable choice is stopped clearly. Watch incorrect selections and unanswered requests as well as purchases. A higher checkout rate is not success if it fills the returns queue with the wrong cartridge.
A portal becomes a commercial asset when it helps both sides make a better decision. The cart is one part of that promise. It should complete a suitable choice, not conceal that the choice was never made.