A wholesale portal GoHighLevel could not do on its own

A client of mine sells a product line. Retail is straightforward: somebody wants two of something, they pay on the website, the box goes in the mail. That side has worked for a while.

Then the wholesale orders started. A shop wants fifty. A distributor wants five hundred. And the store, which had been fine the whole time, suddenly could not price the thing it was being asked to price.

The problem is shipping, and it is not small

A standard store checkout charges one flat shipping rate. You set it once. Twenty dollars, say.

Twenty dollars is roughly right for two items. It is wrong for fifty. It is badly wrong for five hundred, because now you are moving freight, and freight depends on weight, on cartons, on where it is going, on whether there is a loading dock at the other end. The number cannot be known before the order exists.

So the flat rate breaks in both directions at once. The small buyer overpays and feels it. The big buyer gets quoted a number the business would have to eat, and eating it on a pallet order is not a rounding error.

You could raise the flat rate. Then retail stops converting. You could add tiers. Tiers are still guesses, and a guess that is wrong on a pallet is expensive. What actually needed to change was not the number. It was the button.

Wholesale does not want a Buy Now button

This is the part worth sitting with, because it is true well beyond this one business.

Retail is a transaction. See it, want it, pay, done. Wholesale is a conversation. The buyer builds a list, the seller prices the freight, an invoice goes out, and often a relationship exists before any of that. Nobody in wholesale is upset about waiting a day for a real number. They expect it.

So the portal does not check anyone out. Trade buyers see trade pricing, add what they want to a list, and press Send request. No card, no payment, no guessed shipping. The owner gets the full order with every line and quantity and the delivery address, works out the real freight, and sends the invoice.

That is not a downgrade from a checkout. For this kind of buyer it is the correct flow, and the flat rate was the thing standing in the way of it.

How it is wired

The one rule I set before building anything: the product list does not get duplicated.

The moment there are two lists, they drift. The owner updates a price in one place, forgets the other, and a trade buyer is looking at last season’s number. So the CRM stays the source of truth for products, prices and photos, exactly where the owner already edits them. The portal is a reader. It asks for the live list and shows what comes back.

A small read API sits in between. The portal page is hosted alongside the rest of the site. When an order comes in, the owner gets an itemised email with a reference number, every line, the quantities and the address, ready to price and invoice.

Retail never changed. The public store still has its normal checkout, its card payments and its flat rate, because for two items the flat rate is correct. Only the trade side behaves differently. One business, two flows, one product list.

Where the AI actually helped

I want to be exact here, because “I built it with AI” is doing a lot of work in most posts and usually means somebody got a code snippet.

What was genuinely useful was connecting Claude to the CRM account directly, through HighLevel’s MCP integration. That meant the assistant could read the actual product library, the real field names, the real structure. Not a guess at what the API probably returns. The actual shape of the actual data.

That is the difference between an assistant that gives you advice and one that can write code that runs first time. Most of the time I lose on integrations is not writing logic. It is finding out what a system really returns versus what its documentation says it returns. Giving the assistant the same view I have collapsed that.

It still needed someone who knew what to ask for. Nothing about “build me a wholesale portal” tells you the list must not be duplicated, or that wholesale wants a quote rather than a checkout. That part is judgement, and it came from the business, not the model.

If this sounds like your business

The general shape: your CRM or your store does ninety percent of what you need, and the last ten percent is the part your business actually runs on. The usual advice is to replace the whole platform for that ten percent. That is almost always the wrong trade. You throw away everything that worked to fix the one thing that did not.

The better move is usually a small custom piece beside the platform, reading from it, writing back to it, with the platform still the system of record. Nobody retypes anything. Nothing drifts.

If you have a version of this, the thing your system cannot quite do, put it in front of me. Comment on the video, send it through the form, or bring it to the HighLevel Canada group where I fix one of these on screen every week.