You Do Not Need a Customer Portal. You Need a Faster Reorder.

Your best accounts buy the same things every month. The buyer knows the order. Your rep knows the order. And it still arrives as an email that says "same as last time, but double the 500ml."

Someone on your team then opens the store, finds the account, checks the agreed price list, types the lines in, and replies to confirm.

So the team asks for a customer portal. That request is right about the pain and usually wrong about the fix.

The short answer: Most teams asking for a B2B customer portal want one thing from it: an existing account repeating a known order without emailing a rep. That job is usually solved by a per-account order form, a one-click repeat link, or the B2B features already in the platform you pay for. Build or buy a portal only when self-service, approvals and history require it.

A B2B customer portal is a logged-in area where a business account sees its own prices, places and repeats orders, and looks up its own order, invoice and shipment history.

What are you actually buying when you buy a portal?

Read that definition again and count the parts. A portal is a login and an identity for every buyer at every company. A catalog scoped to what that account is allowed to buy. Account-specific prices. An order flow. Often an approval chain, because the person choosing is rarely the person signing. Documents: invoices, statements, proof of delivery. History, which usually lives in your ERP, or enterprise resource planning system, and has to be exposed safely. Then roles and permissions across all of it.

That list is not a guess. BigCommerce's developer documentation describes its B2B Edition buyer portal as covering user roles, multiple company users, company hierarchy, a shared company address book, shopping lists, quotes, invoice management and quick ordering by SKU or previously purchased item. That is the real scope of the word "portal."

Each part is a surface that can break, and it breaks in front of your customer. A portal is not a project you finish. It is a system you now run, next to the store, the ERP and the warehouse. BigCommerce even splits the hosted portal from a self-hosted custom one, where the hosted version is updated for you and the custom version is yours to maintain. That single choice is the build versus buy question in miniature.

All of it is worth doing when the portal is the product. It is a poor trade when the actual request was "stop making Anna retype the Tuesday order."

What job is the request really asking for?

Ask your operations lead one question: of last month's orders, how many were an existing account buying things it has bought before?

In most wholesale businesses the answer is a large majority. Those orders need no browsing, no discovery and no persuasion. They need a fast, correct, low-friction repeat.

Now split the remainder. New accounts placing a first order, buyers asking for a product they have never taken, and negotiated deals are different jobs with different fixes. Do not let them justify a portal that mainly exists to serve repeat orders. Solve the repeat first. It is the cheapest job and the biggest one.

The reorder ladder: where should you stop?

Climb from the bottom. Stop the moment a rung solves the job you just measured. Each rung costs more to run than the one below it.

Rung 1: A per-account order form with their agreed prices

Solves: a named buyer opens one link, sees the items they actually buy at the price you agreed, enters quantities, submits. No login, no catalog to build, live in a day.

Runs out: it shows no stock, no history and no invoices. Prices now live in a second place, so someone has to keep them current. Past roughly 15 or 20 accounts, maintaining a form each becomes its own manual job.

Rung 2: A one-click repeat of the last order, sent by email

Solves: after each shipment, email the buyer their order back with a "reorder this" link. One click creates a draft order in your store with the same lines at their current agreed price, and your team confirms it. This covers the "same as last time" order, which is often most of them.

Runs out: quantity changes and substitutions. An editable quantity field on the link covers a lot more. It still cannot answer "what did we order in March."

Rung 3: A saved cart, draft order or shareable order link

Solves: a rep or the buyer builds a cart, sends the link, the other side opens it and pays with the account's terms attached. This is already a documented feature rather than a build. Shopify's help center describes B2B draft orders as the way to handle orders customers send by phone or email instead of through the online store, including setting a custom price, adding a purchase order number, and sharing the order with pricing locked by default.

Runs out: it is a per-order artifact, not a place. Nothing persists for the buyer between orders, so every cycle starts with a human again.

Rung 4: The B2B features in the platform you already pay for

Solves: company accounts, several buyers per company, customer-specific price lists, payment terms and a logged-in reorder view. That is a portal. You may already own it. Check your plan before anyone writes a scope.

This is the rung teams skip most often, so here is a documented example to check against. Shopify publishes a B2B features by plan page stating that companies, company locations, location-level permissions, quantity rules, quantity price breaks, net terms, payment reminders, draft orders, easy reorders, purchase order numbers, sales staff permissions and quick order lists are available across plans, while unlimited catalogs and catalogs assigned directly to a company or company location are Plus-only. Its catalogs page adds that Basic, Grow and Advanced plans allow up to 3 active catalogs across all B2B markets, and that when two catalogs price the same product, the lower price is shown. Its payment terms page lists net 7, 15, 30, 45, 60 and 90, all starting the day the order is placed, and notes that payments are not automatically captured when terms expire.

Read that as a checklist, not an endorsement. If most of the portal you are scoping is already on that list, you are scoping a subscription you own.

Runs out: pricing rules the platform's model cannot express, history that lives in the ERP, and approval chains on the buyer side. See customer-specific pricing for where those rules usually break.

Rung 5: A bought portal product

Solves: roles, approvals, documents and account history out of the box, with connectors to common platforms and ERPs. You pay a subscription plus setup, and someone else ships the bug fixes. Adobe Commerce, for example, documents requisition lists that a logged-in company buyer maintains for frequently ordered items, up to 999 lists per buyer account depending on configuration, and unlike a wish list the requisition list is not cleared when its items go to the cart. That behavior is exactly the reorder job, already built and documented.

Runs out: when your pricing or your ERP does not match the product's model. Then you pay for the product and for the workarounds around it, which is the worst of both columns below.

Rung 6: A custom build

Solves: exactly your rules, exactly your data, no compromise on pricing logic or ERP shape.

Runs out: never, and that is the problem. You own every future change, every dependency upgrade and every 7am outage. Take this rung only after the five below it have been tried and honestly ruled out.

When is a real portal the honest answer?

Four conditions. If two or more are true, a portal is a reasonable build. If none are, you are buying a login page.

• Many accounts self-serving. Enough buyers that per-account handholding does not scale, and enough order frequency that they will learn the tool.
• Approval chains on the buyer's side. The person who picks is not the person who signs. A portal can hold a basket in "awaiting approval" for three days. Email cannot.
• History that must be exposed from another system. Invoices, statements, proof of delivery and open balances that live in the ERP or accounting system, and that buyers currently get by asking your team.
• Roles and permissions. Site managers who order but cannot see pricing, head office that sees everything, a finance user who only wants documents. This is why platform documentation lists user roles and company hierarchy as core portal features rather than extras.

Build or buy: how do the options compare?

Three columns, because the first one is the option teams forget they have paid for.

Dimension	Platform B2B features you already pay for	Bought portal product	Custom build
Time to first real order	Days, if the plan includes it	Weeks, mostly data and mapping	Months
Ongoing cost shape	Inside your existing plan	Subscription plus per-change work	Your own maintenance, forever
Fit to unusual pricing rules	Only what the price list model allows	Good until your rules leave its model	Exact, at a price
Who fixes it at 7am	Your platform vendor	The vendor, at their pace	You, or the agency that built it
Exit cost	Low, it is a setting	Medium, data export and rebuild	High, nothing transfers

A worked example, illustrative

Use your own numbers. This arithmetic is here to be redone, not believed.

• 40 accounts that reorder regularly
• 3 reorders each per month, so 120 reorders
• 7 minutes of staff time per reorder to read, price and enter it

That is 840 minutes, 14 hours a month. At €35 an hour, about €490 a month, or €5,880 a year.

Now price rung 2 against rung 5. Say a repeat-order link handles 70 of those 120 orders with no human touch. That recovers 490 minutes, about 8 hours, or €286 a month, for a few days of work.

A bought portal at €300 a month plus €4,000 of setup would have to remove all 14 hours to leave €190 a month of margin, which pays back the setup in about 21 months. On time alone, the cheap rung wins clearly.

The real case for a portal is rarely the €490. It is the orders you never see because reordering was annoying, and the rep hours that go to service instead of selling. Those are worth more, and neither of us can put a number on yours. Estimate it yourself, and see what B2B automation actually costs for the cost side.

When should you not climb the ladder at all?

• Low order frequency. Ten accounts ordering twice a year will keep emailing. Let them.
• Every order is negotiated. If price, quantity and delivery are decided in a conversation, self-service has nothing to repeat.
• Your prices are not settled. A portal shows a price to a customer. If agreed prices still live in a spreadsheet nobody trusts, fix that first.
• Nobody owns it. A portal with no owner becomes a stale catalog with wrong stock, which is worse than no portal.
• You have not measured today. Without a baseline you cannot tell a win from a habit change.

How do you measure whether it worked?

Two numbers decide whether any rung worked. Write both down before you change anything.

Touchless reorders. Count the reorders placed in a month where no staff member opened, edited or typed the order. Divide by all reorders that month. If no report gives you this, tally it by hand for two weeks. A number you collected by hand beats a dashboard you do not trust.

Time from buyer intent to confirmed order. Start the clock at the buyer's email or click. Stop it at the order confirmation. Track the median and the worst case, because your accounts remember the worst case.

Two supporting numbers are worth keeping: orders that needed a price correction after entry, and reorder emails still landing in the shared inbox. If touchless reorders rise but the inbox does not empty, buyers are using both channels and you have added work instead of removing it. That pattern is the same one described in the B2B e-commerce automation guide.

Do this next week

1. Count last month's orders that were an existing account rebuying known items. That is your portal's real audience.
2. Time the manual reorder end to end, three times. Use the median.
3. Open your platform's own B2B feature and plan documentation and mark what you already pay for.
4. Ship rung 1 or rung 2 for your five busiest reorder accounts.
5. Measure touchless reorders and time to confirmed for four normal weeks, then decide about rungs 5 and 6 with evidence.

If the answer really is a portal, connect it in the right order. That sequence is in the B2B integration checklist, and the connection work itself is software integrations, not a new product.

FAQ

Do I need a B2B customer portal?

Only if buyers must serve themselves at a scale your team cannot cover by hand, or they need approvals, history and documents exposed from another system. If the real request is faster reordering by known accounts, a per-account order form, a repeat-order link or your platform's built-in B2B features usually solve it for far less.

What is the difference between a customer portal and a reorder link?

A reorder link does one job: it turns a past order into a new one in a click, with no login. A portal is a logged-in place that also holds identity, catalog access, prices, approvals, documents and history. The link solves the common case in days. The portal solves the whole surface, and you maintain that surface forever.

Should I build or buy a B2B portal?

Buy when your pricing, roles and documents fit a product's model, because you get approvals and fixes without owning code. Build only when your pricing rules or ERP shape cannot be expressed in any product you tried, and the value is large enough to justify owning the maintenance. Check your existing platform's B2B features before either.

Can I use my existing e-commerce platform for B2B self service?

Often yes. Platform documentation is the place to check. Shopify, for example, publishes a B2B features by plan page covering companies, company locations, net terms, draft orders, easy reorders and quick order lists, with unlimited catalogs and company-level catalogs reserved for Plus. Read your own plan's page before you scope anything new.

How much does a B2B customer portal cost to run?

Count three things, not one: the subscription or build cost, the setup and data mapping, and the ongoing work when prices, accounts or the connected ERP change. A bought product moves fixes to the vendor at their pace. A custom build keeps every fix, upgrade and outage with you.

What should stay manual even with a portal?

Negotiated pricing, credit limits, payment terms and refunds. Keep first orders from new accounts under human review too, because that is where wrong terms and wrong prices get set and then repeat quietly for a year.

Sources

• Shopify B2B features by plan: which features are on every plan, which are Plus-only.
• Shopify B2B catalogs and pricing: the 3 active catalog limit, quantity rules and volume pricing.
• Shopify B2B payment terms: net 7 to net 90, and payment not captured automatically at term end.
• Shopify B2B draft orders: phone and email orders, custom prices, PO numbers, shareable orders with locked pricing.
• Adobe Commerce requisition lists: documented reorder lists, up to 999 per buyer account, persisting after checkout.
• BigCommerce B2B Edition buyer portal introduction: the feature list that makes up a portal, from user roles to quick order by SKU.
• BigCommerce buyer portal overview: hosted versus self-hosted portal, and who maintains which.