What wholesale customers want from a portal
A contractor, retailer or installer who buys from you every week usually wants three things:
- To know whether you have it. How much is free to sell, and when more is coming.
- To see their own price. The price agreed for their account, not the list price.
- To order without a phone call. Send a purchase order with their own PO number, see what they ordered last time and check where an open order stands.
Today most of those questions reach your staff by phone or email, and someone looks up the answer in your system. A portal lets the customer do the lookup. The answer is only as good as the records it reads.
What the portal has to read
| The customer asks | The portal reads | If the record is missing or out of date |
|---|---|---|
| Do you have it? | Stock in each warehouse, stock held for other orders, stock on order and in transit | It offers stock already promised to someone else |
| What's my price? | The price level on the customer's account and any price saved for that customer | It shows list price, or last month's price |
| What did I order last time? | Past orders, linked to the products on them | The customer has to call to reorder |
| Where is my order? | Open orders and the supplier purchase orders that will fill them | Your staff still take the call |
The stock figure is the one most portals get wrong. The number a customer needs is the stock that is free to sell: what is on the shelf minus what is already held for other orders. If 1,150 of the 1,200 sq ft in your warehouse are held for jobs your reps have already sold, the customer can have 50. A portal that shows 1,200 will take an order you cannot fill.
To show the right number, your system has to record two separate things about the goods: where they are, and which order, if any, they are held for. One B2B job from quote to purchase order shows how CommerceServer records both, from the moment a purchase order to a supplier is placed until the goods are received into stock.
Why portals fail: copies and undefined data
Most portals that disappoint fail for one of two reasons.
The portal reads a copy. Many portals are separate applications with their own database. A sync or export copies stock and prices into it on a schedule, often overnight, and orders come back through an import or an email to your sales inbox. Between syncs the portal is out of date. Someone has to check or re-key every order placed through it, and someone has to keep the sync working each time either system changes.
The data was never defined. A portal can only read what is recorded as data. If stock held for an order lives in a note, a customer's agreed price lives in a custom field someone updates by hand, or the link between a customer order and the purchase order filling it is typed in when somebody remembers, the portal has nothing reliable to read. Connecting a portal directly to that system shows the same gaps to your customers.
Both problems are fixed underneath the portal. Describe the business as a data model first: customers, products, stock, holds, prices, orders and purchase orders, and the links between them. Then build the portal on the records that model defines. Don't copy your old database: design the data model first explains the method. If those records are spread across XLS spreadsheets, CSV exports, PDFs, database backups, Dropbox folders and raw web pages, they have to be brought into the model first. Moving off Zoho without losing your history shows how that works for a business leaving Zoho.
A worked example: one purchase order sent at 9:00 p.m.
The numbers here are illustrative. A flooring contractor needs 400 sq ft of a grey carpet tile for a job that starts Monday. At 9:00 p.m. the contractor logs in to the distributor's portal. The warehouse holds 1,200 sq ft of the tile. Reps have already sold 900 sq ft to earlier orders and 250 sq ft to orders placed today, so 50 sq ft are free. Another 2,000 sq ft are in transit from the mill. The contractor's account price is $3.65 per sq ft, and the list price is $4.20.
On a portal that reads a nightly copy, the contractor sees 1,200 sq ft in stock at $4.20 and submits a purchase order for 400 sq ft. The order waits overnight. At 8:30 a.m. a rep re-keys it, finds only 50 sq ft free and corrects the price. At 9:15 a.m. the rep calls the contractor, who has already booked Monday's crew. Even a copy that subtracted holds would have shown 300 sq ft, the figure from before today's orders.
On a portal that reads the live records, the contractor sees 50 sq ft free, 2,000 sq ft in transit and a price of $3.65. The contractor picks another tile or moves the start date, and at 9:15 p.m. sends the purchase order with their own PO number. At 8:30 a.m. the order is already in the list your staff work from, at the contractor's price.
What happens behind a submitted purchase order
Once your staff accept a portal order, it should follow the same path as an order taken by phone. It becomes a sales order that keeps the customer's PO number, stock is held for it, and anything you don't have is ordered from suppliers on purchase orders linked back to it. Then the invoice goes out. One B2B job from quote to purchase order follows a job through each of those steps in CommerceServer.
Each of those steps writes records the portal reads next. The hold reduces the stock the next customer sees, and the supplier purchase order tells the customer when more is coming. A portal on a copy sees none of it until the next sync.
Example: the flooring wholesaler that left Zoho
A flooring wholesaler that had run its business on customized Zoho for 15 years moved to CommerceServer in one month. One of the new pieces it gained was a B2B web portal. Its business customers log in, check inventory and submit purchase orders themselves.
The portal runs on the same CommerceServer data the staff use. Nothing is copied or synced, so the stock a customer sees is the stock recorded in CommerceServer, and a submitted purchase order arrives in the system the staff already work in. From there it is handled like any other order.
The portal could be built that way because of the work that came before it. The business was described as a data model before any data moved, and 15 years of records were imported into that model and checked: 293,986 fields compared with a backup, with zero differences at the end. What a distributor got by leaving Zoho covers the portal and the wholesaler's other results, and How a flooring wholesaler left 15 years of Zoho patches in one month covers the move itself.
A checklist for evaluating a portal
Ask these questions about any portal you are offered, including one you plan to build yourself.
- Does it read your live records or a copy? If it reads a copy, ask how often the copy is refreshed and what customers see between refreshes.
- Does the stock figure subtract stock held for other orders? Ask whether it also shows stock on order and in transit.
- Does each customer see their own price? Ask where that price comes from and what the portal shows when a rep changes it.
- Where does a submitted purchase order land? If someone has to re-key or import it, your staff are still typing every order.
- Can customers see their past and open orders? That is what stops the "where is my order?" calls.
- Who changes the portal when your business changes, and what does each change cost?
Then run one test before you sign anything. Change a price or a stock figure in the system your staff use, and look at the portal straight away. If the portal still shows the old figure, your customers will see it too.
Customers still calling to check stock?
If your customers phone to ask what you have and what it costs them, start with the records behind those answers. We describe your business as a data model, move your records into it, and build CommerceServer around it, including a portal that runs on the same data your staff use. Changes are included in the subscription. Tell us what your customers call to ask about, or read how full service works.