Does your business need a customer portal?

A business may need a customer portal when ordering depends on an existing commercial relationship: approved company accounts, customer-specific products or prices, several delivery locations, purchase orders, or review by a sales team. Those rules should determine the scope of the system.

A public catalog or conventional online store can be sufficient when buyers share the same product information and ordering process. I start by mapping how the business actually sells and fulfills orders, then identify where an account-based workflow adds value.

Choose the right ordering workflow

Common website and ordering requirements

What the buyer needs	A useful starting point
Research products and contact sales	A public catalog with technical resources and inquiry routes
Buy from a shared catalog with defined prices and delivery rules	A conventional e-commerce storefront
Order under an approved company account with specific purchasing rules	An account-based customer portal
Submit requirements before price or freight is finalized	A quote or purchase-order workflow with staff review

These approaches can coexist. A manufacturer may publish its technical catalog for everyone while reserving ordering for approved customers. The public website and the account experience should have clearly defined responsibilities.

Start with the account model

Write down who buys, who authorizes the purchase, and where the order is delivered. One person may buy for a single location; another may represent several locations within a company. Internal staff and sales representatives may need different views of those same records.

Decide who approves new accounts, how a user is assigned to a company, which ship-to locations they can select, and how access is removed when their role changes. Account ownership and purchasing permissions should be explicit.

WooCommerce provides customer and shop-management roles as part of its foundation. A company-based model with more specific purchasing permissions needs to be assessed against the actual requirements. The WooCommerce role documentation explains the standard roles; additional business rules need their own implementation and verification.

Separate product access, pricing, and order approval

There are several distinct questions to answer. Is a product publicly visible? Can this account order it? Which price applies? Is freight known at checkout? Does submitting an order commit either party to a final total, or does staff review follow?

Write those rules down individually. Hiding a price is different from restricting purchase access. A purchase-order number identifies the customer’s reference, while the order’s review status describes where it sits in the supplier’s process.

The interface should make the next step understandable. Customers need to know what they have submitted, what remains subject to review, and how they will receive an update.

A documented example: ASMG

For All States Materials Group’s commerce portal, I built a custom ordering layer on WordPress and WooCommerce. It connects approved company accounts, purchasing users, ship-to locations, product-access and pricing rules, purchase orders, and delivery requirements.

Industrial delivery introduces requirements beyond a typical parcel shipment. ASMG’s workflow captures different logistics information for less-than-truckload and bulk delivery. Pricing and freight can remain subject to review, with custom order statuses and notifications supporting the progression from submission toward fulfillment.

The project also includes spreadsheet import tools for customer, location, product, pricing, and historical sales data. That is a documented import workflow; a new project requiring continuous synchronization with another system would need separate discovery and scoping.

Review the data before promising an integration

Identify the source of truth for customers, products, prices, inventory, and order status. Ask how each record is identified and who can correct it. A spreadsheet with inconsistent company names or product codes needs attention before it becomes the basis for purchasing rules.

For an ERP or CRM connection, review the available interface, permissions, update frequency, and failure handling. Decide what happens when a record changes in both systems or a transfer is interrupted. Include reconciliation and ongoing ownership in the scope.

The right implementation may combine established platform features, suitable extensions, and custom development. The business requirements and maintainability should guide that choice.

Define acceptance checks around real roles

Review the system as a buyer, an account approver, a sales representative, and the staff responsible for fulfillment. Use agreed test accounts and representative data to check:

• Each buyer sees only the company information, locations, and orders they are permitted to access.
• Product eligibility and pricing rules apply to the intended account and ordering context.
• Purchase-order and delivery details carry through to the staff reviewing the order.
• Confirmation messages describe the actual status, including any pending approval.
• Order updates reach the correct people, and staff can follow the order’s history.
• Imports and integrations report failures clearly enough for someone to act on them.

These checks help define completion before development begins. They also provide useful examples for staff training and future maintenance.

What to bring to the first conversation

Bring a description of your customer types, an example order, delivery requirements, account approval process, and the systems your team uses. Explain where work is repeated, where information goes missing, and what customers currently ask staff to do for them.

A representative sample of the workflow is more useful at this stage than a long feature wish list. It gives us a basis for deciding the first release, identifying dependencies, and preparing a realistic proposal. Explore customer portal development or discuss your ordering process.