Selling a professional use kit to clinics is not ecommerce with a different logo. The buyer is an organization, the price is negotiated, the product is restricted, and the ordering system has to know all three.
Why a consumer cart breaks
A direct to consumer store assumes an anonymous buyer, one shipping address, a published price and a card. A clinic channel violates every one of those assumptions.
The buyer is a practice with several people ordering. The ship-to is often not the bill-to, and there may be six ship-tos. The price depends on an agreement. And for a professional use product, the buyer has to be someone permitted to buy it, which is a gate rather than a checkbox.
Bolting those onto a consumer template produces a store that technically works and operationally leaks. The leaks show up as orders shipped to the wrong site, pricing honored that should not have been, and a service load that eats the margin the channel was supposed to create.
Verification is the front door
If the product is restricted to professional purchasers, account approval is a control and should be documented like one.
Decide in writing what qualifies a buyer. A practice license number, a facility identifier, a named medical director, verification against a public registry. Whatever standard you set, the important part is that a person reviews it, the evidence is retained, and the account cannot transact until it is approved. Auto approval on a form submission is the same as no gate at all.
Two details get missed. Re-verification, because licenses expire and practices close, so accounts need a review interval. And a clean record of who approved what, because if this is ever examined the question will not be whether you had a policy, it will be whether you followed it.
Model the organization, not the user
The account is the practice. Users belong to the account. That single decision prevents most of the downstream mess.
- Multiple users per account, with roles, so an office manager can order and a director can approve
- Multiple ship-to addresses attached to the account, each one validated once and reused
- A bill-to that is independent of the ship-to
- Order history at the account level, so a new hire can see what the practice ordered last time
- The ability to deactivate a user without closing the account
Validate ship-to addresses at the moment they are added rather than at every order. Commercial versus residential classification matters here, and getting it wrong quietly adds a surcharge to every shipment for years.
Pricing behind the login
Professional channel pricing is account specific and should not be visible to anyone who is not logged in. That is not secrecy for its own sake. It is that a published price becomes the ceiling in every negotiation you have afterward, and it invites cross channel comparison against a product sold under different terms.
Practically, that means price lists attached to accounts, a catalog that shows products but not prices to unauthenticated visitors, and a clear rule for what a newly approved account sees before a specific agreement exists.
Payment and terms
Card at checkout should be the default, because it settles immediately and requires no credit decision. Terms are a credit product, and every account on terms is an account you are financing.
Reserve terms for buyers where the volume justifies the credit work, run an actual credit check, set a limit, and enforce the limit in the system rather than in someone’s memory. A portal that lets an account on terms keep ordering past its limit is not offering terms, it is offering an unsecured loan.
Ordering mechanics that clinics actually need
- Case quantities and order minimums enforced at the cart, not corrected afterward by a person
- One click reorder from history, which is how most clinic ordering actually happens
- Standing or scheduled orders for predictable consumption
- Quantity breaks that are visible, so the buyer can see what ordering one more case does
- A quote request path for anything outside the standard catalog
- Purchase order number capture, because most practices need it on the invoice
What the portal owes the warehouse
The portal is a front end to a physical operation, and the integration is where these projects succeed or fail.
Every order needs to arrive at the warehouse with the ship-to validated and classified, the service level chosen, the case configuration resolved, and any account specific handling instruction attached. Every shipment needs to send back tracking, and for a kit program, the lot and kit identifiers that went into that box.
That last item is the one clinics start asking for in year two. When a lot question comes up, the answer is either a query or a warehouse search, and which one you have was decided by whether the portal captured it on day one.
Build or buy
Most of this exists in mature B2B commerce platforms, and for a standard catalog that is the faster route. Custom becomes worth it when the verification workflow, the lot reporting, or the integration with your operations is the actual product rather than a feature.
The honest test is whether what makes your channel work is the storefront or the operation behind it. If it is the operation, buy the storefront and spend the engineering on the integration.
Related reading: Questions to ask before you integrate and Fulfillment API and ecommerce integrations.
Gate the account, model the organization, hide the price, and make the portal tell the warehouse everything it needs. The rest is a normal cart.
