The customer asks for a B2B portal and you send them an Excel: how much revenue you are leaving on the table
The «don’t forward it» pricing Excel
There is a file, in your company, that is worth more than it seems. It’s the pricing Excel. It has a column for the item and a column for the price, maybe one for the discount. When an important customer asks for the price list, you email it to them, maybe with a line: «careful, don’t forward it, these are your prices». And every time you send it, you are gambling two things at once: the confidentiality of your margins and the time you — or a person in your office — spend acting as a switchboard between the customer and the numbers.
Then comes the question that should make you perk up your ears. The customer, the good one, the one who orders every week, writes to you: «but don’t you have an area where I can order by myself?». Or, worse, they don’t write it: they leave for a competitor who has that area. Because the truth is that a B2B customer portal is no longer a luxury for large retail: it has become what your customer expects, because they find it everywhere in their life as a consumer and they don’t understand why in B2B, where they spend ten times as much, they still have to send you an email and wait.
This article is for those who sell to other businesses — resellers, installers, shops, restaurants, workshops, professionals — and still manage orders and price lists with Excel, PDFs and phone calls. Let’s do the real math on how much this way of working costs, in euros and in hours. Then we look at what your customer really wants (it’s not “a website”, it’s something more precise), why shortcuts like Shopify or WooCommerce seem like the way and then smash you against a wall, and how to build an order self service that brings in revenue even when the office is closed.
What the reseller wants at 10 PM
To understand what a portal must do, you have to stop thinking of “an e-commerce” and put yourself in the shoes of the buyer. Your B2B customer is not a consumer browsing to discover. They are a professional who already knows what they want, and they want it in the shortest possible time, often at an odd time of the day.
Think of the shop owner who at ten in the evening, shutters down, starts placing orders for the week. They can’t call you: you’re closed too. They want to review what they ordered last month and redo it with two clicks, because 70% of their order is always the same. They want to see their prices — the ones agreed with you, not the public ones — and they want to know if the goods are there, because if they order and then find out it’s out of stock they’ve wasted time and gotten angry. They want to see the history, the invoices, the shipping status. And they want to do it from their phone, leaning on the counter, without installing anything.
This is the point almost everyone gets wrong: the value of a B2B portal is not “showing the catalog”. It’s removing friction for those who already buy from you. The new customer discovering your products is a marketing problem; the customer buying every week and wanting to do it faster is a product problem — and that’s where the real revenue is, because a customer for whom you make ordering easy orders more often, orders more, and has no reason to look around.
If you think about it, it’s the same principle of internal apps that remove copy-paste: you are not “digitizing” for fashion, you are removing the steps that slow down those who work. Only here the one working is your customer, and every second you save them is one more reason to stay with you.
The math: how much it costs you NOT to have a portal
Let’s put some numbers on it, stated as estimates but reproducible for your company. The cost of not having a B2B portal hides in four items, and none appear on an invoice.
Back-office hours. Every order arriving via email, phone or WhatsApp someone has to transcribe into the ERP. Let’s say you receive 40 orders a day this way, and between reading, understanding, asking for confirmation on an unclear line and re-entering it takes an average of 6 minutes per order. That’s 4 hours a day for one person, every day. With a fully loaded cost of 25 €/hour, that’s about 22,000 € a year just to re-transcribe orders the customer could enter themselves. And I’ve used conservative numbers.
| Item | Annual Estimate |
|---|---|
| Order re-transcription (4 hours/day × 25 €) | ~22,000 € |
| Transcription errors (returns, credit notes, rework) | ~6,000–10,000 € |
| Lost/postponed orders because the office was closed | hard to see, often the largest |
| Phone calls “is there availability?”, “at what price?”, “where is my order?” | ~1–2 hours/day |
Errors. A hand-transcribed order is an order that can go wrong: quantity, code, address, price. Every error is a return, a credit note, an unhappy customer, a shipment to redo. It takes just one error every twenty orders, at an average cost of 40 € between courier and time, to make another 6,000-10,000 € a year.
Orders that don’t arrive. This is the invisible item and often the biggest. The customer who wanted to order at 10 PM and couldn’t, sometimes postpones to tomorrow and tomorrow they forget, or meanwhile they order from the competitor who has the portal. You will never see it in your accounts, because it’s revenue that didn’t come in. But it’s there.
Phone time. “Do you have availability of this?” “How much does it cost me if I take 500?” “Where did my Monday order go?”. These are questions a portal answers on its own, and that today occupy your office for an hour or two a day.
Put these items together and you realize that the absence of a portal is not “zero cost”: it’s a tax you pay every month, only it’s hidden in people’s hours and in the orders you don’t see. Reasoning about this cost of inertia is exactly the same exercise needed to understand why deciding by gut feeling on numbers costs: the cost is there, it doesn’t appear on the balance sheet, and precisely for this reason you never address it.
“But we make a PDF”: why it’s not enough
The first objection, the one I always hear, is this: «okay, but then let’s make a nice PDF of the catalog with the prices, or a sortable Excel, and send it». It seems like the cheap solution. It is instead the problem disguised as a solution, for three reasons.
The first: a PDF doesn’t hold a state. It’s a photograph of a moment. The next day a price changes, a product goes out of production, a new item arrives — and your customer is still looking at the old photograph. They order something that is no longer there, at a price you no longer offer, and when you tell them they get angry. The PDF ages the very moment you send it.
The second: a PDF brings nothing back. The customer looks at it, then writes you an email with the order, and you are back to transcribing. You moved the catalog onto a file, but the work of taking the order is still all yours. You haven’t removed friction, you’ve only moved it.
The third, the most serious: a PDF with prices circulates. That “don’t forward it” file ends up, sooner or later, in the competitor’s inbox, or the customer’s who discovers they pay more than another. Your custom prices — which are a delicate commercial tool of yours — become public. A portal, instead, shows each customer only their prices, behind a login: nobody sees anyone else’s, and you maintain control of your commercial policy. On this specific point — different prices for each customer, the 8,000 codes, the discounts that don’t add up — I wrote a separate piece, because it’s a world in itself: custom B2B price lists.
The PDF, in short, is the answer of someone who wants to spend zero and hope it’s enough. But it removes none of the costs we counted: the hours remain, the errors remain, the lost orders remain. It’s the theater of efficiency, not efficiency.
Why Shopify and WooCommerce seem like the way (and then aren’t)
At this point someone sharper says: «okay, not a PDF, a real e-commerce. Let’s put up Shopify, or WooCommerce, and let customers order there». It’s a better reasoning, and for some situations it’s even the right answer. But in B2B, in the majority of cases, these tools take you to 80% and then smash you against a wall. It’s worth understanding why, because it’s the same wall you’ll hit with almost any “ready-made” solution.
E-commerces are born for B2C: one price for everyone, the customer pays by card, you ship, the end. B2B is another planet, and every difference is a piece where the ready-made tool creaks.
Prices per customer. In B2B there is no “the price”: there is the price of that customer, with their discount, their quantity scale, maybe a net price negotiated on certain items. Shopify inherently shows one price to everyone; to have price lists per customer you have to tack on plugins, and the more you tack on the more fragile and expensive the castle becomes, until you discover that every update risks breaking something.
Tiered discounts and conditions. “Under 500 € order there is a transport contribution”, “from 10 pieces the discount triggers”, “this customer pays at 60 days end of month, this other in advance”. These are the real rules of B2B, and standard e-commerces handle them poorly or not at all.
Honest availability. The B2B customer orders serious quantities and needs to know really if the goods are there, and maybe when they arrive if they aren’t. This requires the portal to know the warehouse balance in real time — meaning it must be connected to the ERP, not to a number copied by hand once a week.
Payment. In B2B often you don’t pay by card at the moment: you order, and pay at the end of the month or invoice due date, according to the agreed credit line. An e-commerce that forces immediate payment doesn’t speak your customers’ language.
The result is that you start with Shopify to save money, and six months later you have a Frankenstein of plugins that costs more in maintenance than you would have spent doing it right, still only does 80% of what you need, and for the remaining 20% — which is precisely the part that distinguishes your company — you have to tell customers “eh, write me an email for that”. You are back to square one, with the addition of a monthly subscription and a pile of plugins to keep standing.
Don’t get me wrong: if you sell few products, at a single price, with advance payment, a ready-made e-commerce can be perfectly sufficient, and it would be stupid to spend more. The right question is not “ready-made or custom” in the abstract: it’s how much of your B2B fits in that 20% that ready-mades don’t do. If the heart of your way of selling — prices per customer, discounts, credit line, ERP integration — fits in there, then the ready-made is a trap you discover late.
What the customer sees: the screens that close the order
Let’s talk about what you really get, concretely, because “portal” is a vague word. A good B2B portal, from the customer’s point of view, is a few essential screens — not fifty — designed to make them close the order in the shortest possible time.
The customer’s home: “redo the last order”. As soon as they enter, your regular customer doesn’t want to browse a catalog: they want to redo what they always buy. The first thing they see is their last order, or their usual products, with a “reorder” button. One click and they already have half a cart full. This single screen, alone, is worth half the project, because it covers the case that happens 80% of the time.
The catalog with their prices. When they search for a product, they see the card with their price — the agreed one, not the public one — real availability (in stock / arriving on such date / out of stock), the discount scale if they have one (“from 10 pieces you save X”), and the add button. The search is fast and forgives typos, because the customer searches by code, by name, sometimes by a piece of description.
The cart that is already an order draft. Before confirming they see the total with their discounts applied, any transport contribution, the estimated delivery date. No surprises on the invoice: what they see is what they will pay. They can save the cart and resume it later, because in B2B an order is built in several moments.
History and status. After ordering, they see at what stage it is: confirmed, in preparation, shipped, with the tracking link. And they see all the history: what they ordered, when, the invoices to download. This is where the “where is my order?” phone calls disappear, because the answer is in the portal, always, without bothering anyone.
From your side, instead, the order enters the ERP already clean: the customer identified themselves, used their prices, chose products that exist. Nobody re-transcribes it. Your back-office person, instead of typing, checks the exceptions — the weird order, the urgent one, the one with the special request — meaning they do the part that requires a brain, not fingers. The revenue that previously only came in during office hours, now also comes in at night, on weekends, while you are on holiday.
The invisible piece: integration with the ERP
Here comes the part no demo shows you, and which decides whether the portal is a tool or a toy: integration with the ERP. A B2B portal is useful to the extent it shows real data and sends it back in without re-transcription. If it’s not connected to where the data really lives — master records, price lists, stock levels, orders — it’s theater.
Think about what must happen for that screen “with their prices and real availability” to be true. The portal must know, for that customer, which price list to apply: it takes it from the ERP, you don’t keep it written twice. It must know how many pieces are in the warehouse right now: it reads it from the ERP, not from a number copied last Monday. And when the customer confirms, the order must re-enter the ERP like any other order, ready to be fulfilled, not as an email to be re-typed.
If this piece is missing, the worst thing happens: the portal and the ERP say different things. The customer orders a price that no longer exists in the ERP, or a quantity that isn’t there. And at that point the portal, instead of removing work, adds it: someone has to check every order because it can’t be trusted. You spent money to make the situation worse.
It’s the same reason why, throughout the guide to portals and restricted areas, I insist on one thing: under every working portal there is a solid data layer — the same foundation I talk about for dashboards and data products. The portal is the interface; the value lies in the fact that the interface is hooked to the truth. And the hook must be built with attention to real cases: what happens if the ERP is slow, if an order leaves twice, if the connection drops halfway. They are the boring details that separate a reliable portal from one that generates a mess every Monday.
Why a single hand is needed: data, backend, interface
This brings me to the point that, after years, I consider the most important when building a portal. A well-made B2B portal is three things together: data (price lists, stock, master records talking to the ERP), backend (the rules — who sees what, which price, which discounts, which credit line) and interface (the fast screens that close the order). And these three things must be born from the same head.
The classic way to fail is dividing them among different suppliers: the web agency does “the beautiful website”, a consultant handles the ERP integration, and the two don’t talk. What happens? The agency makes an interface that assumes data that isn’t there; the consultant exposes data in a way the interface can’t use; and when something doesn’t add up — a wrong price, a ghost stock level — each says it’s the other’s fault. You, in the middle, pay two invoices for a portal that gets orders wrong, and nobody takes responsibility.
A portal is like a car where the engine, gearbox and steering wheel must be designed to fit together. Pricing rules (backend) and how you show them (interface) are the same decision: how do I design the tiered discount screen if I don’t know how the discount is modeled underneath? How do I model the discount if I don’t know how I want to show it? This is why you need someone holding data, logic and frontend together — not three blaming suppliers. It’s not a matter of “having all skills in one person” to boast: it’s that decisions are intertwined, and whoever makes them separately builds a portal that comes unglued at the first real case.
And AI in all this?
A note, because today the question always comes: «and artificial intelligence, where do we put it?». The honest answer is: in a B2B portal, AI is a useful side dish in a few places, not the main course. It can help the customer search better (“I need the spare part for that model there”) interpreting approximate descriptions; it can suggest products they usually order together; it can read an order that still arrives via email or PDF and propose the draft already filled out in the portal, so even lazy customers enter the system effortlessly.
What AI must not do is decide the price, apply a discount or confirm availability: those are precise, deterministic rules, and must be managed by an engine that always gives the same answer, not by a model that “usually” gets it right. A wrong price is real commercial damage. The rule, in a portal, is the same that applies everywhere serious: AI where it helps reading and searching, the engine where it must be exact. Whoever sells you “the portal with AI managing everything” is selling you a risk, not a feature.
A typical case: from human switchboard to self-service
A typical profile, architectural, no names. Distribution company with a few hundred active customers — shops and installers — and a catalog of a few thousand codes. Orders arrived a bit from all channels: email, phone, WhatsApp to the area sales rep, some stubborn faxes. Two people in the office spent a large part of the day transcribing: reading the order, figuring out the right price for that customer (opening the price list Excel), checking availability (asking the warehouse), entering into the ERP. In seasonal peaks they couldn’t keep up, orders slipped, and customers called to know where they were — adding phone calls to the load.
What was done, and in what order. First the pricing chaos was tackled: price lists lived in three different Excels with unwritten rules (“for this one we always do 3 more on the net”), and before exposing them to a customer they had to be made coherent and reliable. Then the portal was built on top of the ERP: customer identity, their price list, the catalog with availability read in real time, the cart becoming an order inside the ERP. Nothing more, initially: the few screens covering the frequent case.
The rollout started with eight trusted customers, those ordering every week. In the first two weeks, exceptions emerged that no meeting had foreseen: the customer ordering on behalf of two sales points, the product selling in pack multiples, the time-limited promotional discount. Once those were fixed, it was expanded by tiers. The result, fully operational, wasn’t “we have a new website”: it was that the two back-office people stopped transcribing and started managing exceptions and acting as real sales reps, orders began coming in even in the evening and on weekends, and the “where is my order” phone calls almost disappeared because the answer was in the portal. With the usual honest note: the first few weeks someone grumbled (“I was faster on the phone”), then nobody ever went back.
Red flags: how to tell if you’re being sold hot air
When evaluating who should build your portal, there are signals telling you in advance if you’ll end up in the Frankenstein of plugins or the portal that detaches from the ERP. Keep them in mind:
- They don’t ask how your pricing world works. If the supplier starts talking about graphic themes and “user experience” without first having price lists, discounts and credit explained, they are selling a storefront, not a portal. The portal lives or dies on pricing rules, and whoever doesn’t investigate them first won’t manage them.
- They gloss over ERP integration. «Then we connect to the ERP» said lightly is a warning bell. Integration is the hard part and must be tackled at the beginning, not “afterwards”. Whoever puts it at the end will discover late that it was 60% of the work.
- They promise “online in a week”. A serious B2B portal requires understanding your case and integrating with your data: it’s not a theme to install. The promise of a week is the promise of a disguised ready-made e-commerce.
- They talk about subscription and not ownership. If to the question “do the code and data remain mine?” the answer is vague, you are about to enter a cage. A portal is your asset, not a lifetime rental.
- “AI manages everything”. AI in a portal helps searching and reading, not deciding prices. Whoever sells it as the engine of everything is selling you a risk.
If the supplier instead starts from your pricing rules, takes integration seriously and talks about gradual rollout and ownership, you are on the right track.
Who pays for the project: you, or the new margin
Let’s talk about money, because the real question behind every portal is: “is it worth it?”. And the right way to look at it isn’t “how much the portal costs”, but “who pays for it”.
A B2B portal is not a marketing expense you hope yields: it’s a tool that has a fairly measurable return. On one hand it cuts costs you pay today: re-transcription hours, errors, phone calls. We estimated earlier that between re-transcription and errors you are easily over 25-30,000 € a year of hidden costs; a portal removing a good slice of that pays for itself with that single item in a reasonable time. On the other hand — and it’s the most beautiful part — a portal brings in orders that previously didn’t enter: the out-of-hours ones, the extra ones a customer places because reordering became easy, the ones you no longer lose to the competitor. This second piece is harder to predict, but in experience it’s the one weighing most in the end.
The right way to reason, therefore, is: the portal is paid for by new margin and removed cost, not by your bank account as a sunk cost. And there’s a second aspect: a well-made portal is your asset — code, data, integration remain your property. You are not paying a lifetime subscription to someone holding your customers hostage inside their platform. It’s the opposite of the ready-made platform logic, which I talk about for a close case — restricted areas with courses and content — in custom customer restricted area, where the issue of “who takes the margin and data” is even more evident.
Honest timeline and rollout by customer tiers
How long does it take? It depends on how complicated your pricing world is and how accessible your ERP is, but let’s try to be honest with qualitative ranges, not with the “online in a week” lie.
The first part of the work isn’t technical: it’s understanding the real rules. How your price lists are structured, how many types of discounts really exist, how credit works, what “available” means in your warehouse. This listening and mapping phase is where the project is won or lost, and shouldn’t be skipped.
Then the core is built — identity, prices per customer, catalog, cart, order entering the ERP — and it is tested on a few pilot customers, not on everyone. This is the point about rollout I want to underline, because it’s where many get it wrong: you don’t turn on the portal for all customers on the same day. You choose a small group of trusted customers — the ones ordering often and who will tell it like it is — and start with them. They use the real portal, on their real orders, and they make the cases emerge that no meeting foresaw: the weird discount, the configured product, the exception. You fix those, and only then you expand, customer tier by customer tier.
This gradual rollout has two advantages. It reduces risk: if something is wrong, it goes wrong with five understanding customers, not with five hundred angry ones. And it builds trust: when pilot customers say “finally, you order in two minutes”, the others want it, and you don’t have to convince anyone. A portal dropped from above on everyone together, without a pilot, is the best way to burn your reputation at the first bug on an important customer.
In total: account for weeks, not days, for a working pilot, and a few months for a complete and stable rollout on a company with complex price lists. Whoever promises less either hasn’t understood your case, or is selling you a ready-made e-commerce disguised as a custom portal.
After go-live: the maintenance that keeps the portal alive
A portal is not a project that “ends”. It’s a piece of software that lives alongside your company, and your company changes: new products, new price lists, new commercial rules, new couriers, a new type of customer. Every change must be reflected in the portal, and if there isn’t anyone doing it in a reasonable time, the portal begins to diverge from reality — and a portal showing old data is worse than no portal, because the customer trusts it and makes mistakes.
For this reason a serious portal includes declared maintenance: who answers when a rule changes, in what time, at what cost. And it provides that you can evolve it: add a function when needed, without redoing everything. The question to ask before signing is simple: «when I launch a new promotion, or change the discount policy, what do I have to do, who does it, in what time?». If the answer is clear, you are fine. If every little change is an estimate and two weeks, the portal will age quickly.
It’s for you if / it’s not for you if
It’s for you if: you sell to other businesses (resellers, shops, installers, restaurants, professionals) who order from you with a certain frequency; you manage different prices per customer, discounts, credit; you spend hours re-transcribing orders arriving via email, phone, WhatsApp; you have customers asking you for “an area to order by themselves” or you risk losing them to competitors who have it; your ERP already contains master records, price lists and stock levels to start from.
It’s not for you if: you sell few products at a single price with advance payment (then a ready-made e-commerce is enough, and spending more would be a waste); you have very few customers that you manage perfectly by voice and have no need for self-service; you are not willing to put your price lists and pricing rules in order — because a portal makes the chaos you currently keep at bay by voice visible, and if you don’t want to face the chaos, the portal amplifies it instead of solving it.
Frequently asked questions
How much does a B2B portal cost? It depends on how complex your price lists are and how accessible the ERP is. It’s not a few-hundred-euro e-commerce, but neither a hundreds-of-thousands ERP. The right way to evaluate it is to compare it with the hidden costs you remove (re-transcription, errors, phone calls: often 25-30,000 € a year) and with the new orders it brings in. On that comparison, a well-made portal pays for itself over a horizon of months, not years.
Isn’t a ready-made e-commerce like Shopify enough? If you sell at a single price with advance payment, it can be enough and it would be right to use it. If your B2B lives on prices per customer, tiered discounts, credit, ERP integration, then those tools take you to 80% and then block you precisely on the part that counts. The criterion is how much of your way of selling fits in that 20% that ready-mades don’t do.
Do my prices remain confidential? Yes, and it’s one of the main advantages. Every customer sees only their prices, behind their login. No PDF circulating, no customer discovering they pay more than another. The portal gives you back control of your commercial policy, which today you entrust to a “don’t forward it” file.
Does it connect to my ERP? It’s the point making the difference between a tool and a toy. A serious portal reads price lists and stock from the ERP and sends orders back in, without re-transcription. If your ERP exposes data (almost all, in some way, do), it integrates. How it integrates — in real time or at intervals — depends on the case, and is one of the first things to evaluate.
Will elderly or non-digital customers use it? If it’s easier than the old method, yes. The secret is the “reorder last order” in one click and a simple interface from the phone. And you can accompany the transition: those who really don’t want to continue ordering via email for a while, maybe with AI transforming their email into a draft in the portal. The gradual rollout serves this too.
What if I have thousands of codes and very complicated prices? It’s exactly the case where a custom portal makes more sense, because it’s the situation where ready-mades fail. The complexity of price lists is not an obstacle to the portal: it’s the reason you need it. On this specific topic I wrote 8,000 SKUs and a different price per customer.
How long does it take to start? Weeks for a working pilot on a group of trusted customers, a few months for a complete and stable rollout on a company with complex price lists. Beware of those promising “online in a week”: either they haven’t understood your case, or they are giving you a disguised ready-made e-commerce.
Does the portal remain mine? Yes, and it must. Code, data and integration are yours: no vendor lock-in, no lifetime subscription holding your customers hostage. If tomorrow you want to change who maintains it, you take everything away. It’s the difference between buying an asset and renting a cage.
In one line
If your customer asks you for a B2B customer portal and you send them an Excel, you are paying a hidden tax — re-transcription hours, errors, phone calls, and above all orders not entering because the office was closed. A true portal is not “a login on the website”: it’s order self service with the right prices for each customer, real availability, and the order entering clean into the ERP without anyone re-typing it. Done well — with data, backend and interface from the same hand — it pays for itself and brings in revenue even while you sleep.
If you want to understand how much you’re leaving on the table and what a portal would be like on your price lists and your ERP, look at the projects I’ve built or drop me a couple of lines: we start from how you sell today and what customers ask you, not from a demo.
Antonio Trento — System Architect & AI Integrator
Is this your problem?
I design and build data, backend, interface and AI agents end-to-end. No slides: systems that run and stay yours.