B2B portal: six people retyping by hand the orders customers repeat unchanged every month

The sales director of a plumbing and heating wholesaler, sixty eight employees and thirty two million in revenue, showed me the sales back office inbox one Monday at a quarter past nine. One hundred and fourteen unread messages. Orders as PDFs, orders typed into the body of an email, photos of a handwritten sheet, three voice messages transcribed by a colleague, two requests for "same order as last week". Six people spent the morning copying those lines into the ERP, and the afternoon answering the phone to installers asking for the net price of a valve and whether it was in stock. A year earlier they had launched a B2B portal. Forty one customers out of fourteen hundred used it.

If the scene sounds familiar, this article gives you the real cost of receiving customer orders the way they arrive today, the single number that tells you whether a B2B portal will take work off your back office or remain a shop window nobody opens, why the price list is the hard part of the project and not the design, where the connection with the ERP really breaks, how to get a customer to actually use it, the difference between a portal and B2B ecommerce, the real price ranges between the module of the ERP you already own, a subscription platform and a custom system, and the threshold in euro beyond which the maths changes.

I have been writing software since 1999 and I have seen orders between companies travel in every possible way: wholesalers with forty thousand codes and customers ordering from the van, manufacturers selling to dealers with nine discount bands and a different net price for every important customer, component makers where every order is a quotation that becomes a confirmation, distributors who must tell a hardware shop at seven in the evening whether the part ships tomorrow. I have also built and sold a software product used by many companies, and from the seller's side I learned that a customer uses a tool only if it saves time for them, not for you.

What I learned, and what no vendor says during the demo, is this: the number that decides is not how many customers you manage to register on the portal, it is how many of the orders your back office retypes by hand are reorders of codes that customer has already bought. A B2B portal is excellent at removing repetitive work and terrible at replacing a negotiation. If your orders are almost all reorders, the portal pays for itself. If they are almost all new requests, quotations and configurations, you are buying the solution to someone else's problem.

What a B2B portal is, and what it is not

A B2B portal is the place where your trade customers do on their own what they ask your back office or your sales rep for today: they see the catalogue with their net price, check real availability, put the codes they always buy into a basket, send the order without anyone copying it, follow where the shipment is, download the delivery note and the invoice, and perhaps open a return without phoning. The word that matters is "their": their price, their delivery addresses, their history, their credit limit.

On the market you find it under different names, and the confusion suits the people selling it. Customer portal, B2B ecommerce, B2B platform, dealer area, order portal, online catalogue for sales reps, B2B commerce. They overlap only partly, cost very different amounts and solve different problems. A browsable catalogue with the public price list knows nothing about the net price agreed with your biggest customer, and an online shop with a basket does not know that customer has been blocked by accounts for a three month overdue invoice.

B2B portal or B2B ecommerce: the difference that matters

In everyday language they are synonyms, and Google searches use them that way. In the practice of a project the difference is a single one, and it is worth keeping in mind because it decides where you start. B2B ecommerce is born to sell: it helps products get found, presents them well, pushes promotions, looks for new customers or gets existing ones to buy more. A B2B portal is born to serve: it takes work off the back office and the reps, makes the customer autonomous on the questions they always ask, and brings the order into the ERP without manual steps.

The two live together, but the return is different. B2B ecommerce is measured on extra revenue, and that revenue is hard to attribute: would the customer who ordered online have ordered anyway? The portal is measured on hours and errors saved, and those can be counted precisely. That is why, in the SMEs that write to me, I almost always advise starting from service and not from selling: the numbers add up sooner, and a customer who got used to ordering on their own becomes a customer you can offer something more.

There is also a third thing sold under the same name, the electronic exchange of documents with large customers, where the order arrives as a file from their ERP into yours. It is useful, and with the four or five customers who have a structured purchasing department it is almost always the right route. But it is not a portal: the customer sees nothing, the two systems simply talk. Keep it separate in your head, because the two are designed differently.

The three families of companies looking for one, and looking for different things

Those distributing a wide catalogue to many small customers. Electrical, plumbing and heating, hardware, spare parts, building supplies and catering wholesalers. Tens of thousands of codes, customers ordering often and little, installers and tradespeople who ask the price on the phone because they have no other way of knowing it. Here the value lies in fast reordering, real availability and a visible net price. It is the family where the portal pays most, because it has the highest share of repetitive orders.

Those manufacturing and selling to dealers. Companies making a product and selling it through shops, authorised dealers, regional distributors. Fewer customers, bigger orders, price lists with discount bands, year end rebates, seasonal campaigns with dedicated terms, pre orders. The value lies in honouring commercial terms and ending the war of PDF price list versions. Here B2B ecommerce weighs more, because campaigns also have to be sold.

Those selling components and products that must be configured. Subassembly builders, companies making custom variants, window, switchboard and plant manufacturers. The order is almost always a quotation that becomes a confirmation, and the customer does not buy a code but a combination of choices. Here a portal built like a shop is almost useless: you first need a system that turns choices into a sellable code and a price, which I covered at length in product configurator. The portal comes later, and brings spare parts and reorders into it.

The three families buy products with the same name and use different parts of them. Before looking at any demo, decide which one you are in, even though you are often in two. Most of what follows applies to all of them; where something changes I will point it out.

The real bill: what receiving orders the way they arrive today costs you

This is the bill almost nobody adds up in full, because none of these costs has a line in the accounts: the back office is a payroll cost that looks necessary, errors end up inside returns and credit notes, wrong discounts are margin that never came in, and lost orders leave no trace. As a reference I take the Monday morning wholesaler: thirty two million in revenue, sixty eight employees, fourteen hundred active customers among installers, dealers and small firms, thirty eight thousand catalogue codes of which nine thousand moved during the year, twenty one thousand orders a year averaging seven lines, so about one hundred and forty seven thousand order lines, six people in the sales back office and twelve sales reps. It is a very common size among the people who write to me, and the numbers scale reasonably well with order lines.

How those lines arrive, in a company like this, you already know without measuring: sixty two per cent is retyped by hand by the back office from emails, PDFs, messages and phone calls; twenty three per cent is entered by the reps with their app; fifteen per cent arrives as a file from the four largest customers. The bill that follows concerns that sixty two per cent, and I keep it low on purpose.

The back office retyping orders and answering the phone

It is the largest cost and the most accepted, because it looks like the normal work of a sales office. Six people at one thousand six hundred and fifty hours a year make almost ten thousand hours. In my experience, in a wholesaler without a portal, between forty and fifty per cent of that time goes into two activities that add nothing: copying order lines into the ERP and answering questions the customer could solve alone, meaning how much is it, is it in stock, when does it arrive, can you resend the delivery note. That is about four thousand five hundred hours, which at a full cost of thirty two euro an hour makes one hundred and forty four thousand euro.

Not all that time disappears with a portal, and whoever tells you otherwise has never seen a real back office: some customers will keep sending the email, and some phone calls are a relationship worth keeping. The part really recovered, within eighteen months, is half: up to seventy thousand euro a year. It does not mean firing anyone. It means the same six people stop copying and start doing what you pay them for, following the customers who matter and winning back those buying elsewhere.

The errors in retyped orders

Whoever copies makes mistakes, and not out of carelessness: they make mistakes because the customer writes "the usual three quarter fitting", because the customer's code is not your code, because the unit in the email is the pack and in the ERP it is the piece. On ninety one thousand lines retyped by hand, an error rate of two and a half per cent is normal, and optimistic when the back office is under pressure on a Monday: about two thousand two hundred wrong lines a year.

Each wrong line costs between fifteen and forty euro across return, second shipment, credit note, phone call and warehouse time, and now and then it costs a customer, the one who received the wrong thing on the day the site was open. Up to fifty five thousand euro a year. It is the cost that falls most easily, because when reordering from history the customer writes nothing: they pick a line they have already bought, and the code is right by construction.

Discounts applied by hand

It is the most invisible cost and often the largest. When commercial terms live partly in the ERP, partly in the sales office spreadsheet and partly in the reps' heads, the price that ends up on the invoice depends on who entered the order. The band discount applied twice, the promotion that expired three weeks ago still granted on the phone, the net price reserved for an important customer also given to their neighbour on site because "it's the same anyway", shipping not charged below the minimum order. Each of these, on its own, is a few euro.

Taken together, in a wholesaler with these characteristics, they make between zero point two and zero point three per cent of revenue, and a distributor's margin often sits between six and ten per cent. On the reference thirty two million that is up to ninety five thousand euro a year, which does not appear as a cost but as margin that never came in. It is found only by comparing, line by line, the invoiced price with what written rules would have produced: nobody does it, and that is why this cost does not exist.

The orders that never arrive

The installer finishes work at half past six in the evening, opens the van and realises four parts are missing for tomorrow morning. Your back office closes at six. Your competitor has a portal where price and availability are visible and ordering from the phone takes two minutes, with same day delivery. They did not betray you: they did what was easiest. If it happens three times, that customer starts looking there even before calling you.

This cost has no precise measure, and I will not invent one. What you see, in companies that opened a well built portal, is growth in lines ordered out of hours to between eight and fifteen per cent of portal volume, and some of those lines used to go elsewhere. On the reference wholesaler, estimating eight hundred thousand euro of revenue lost in a year for this reason and a ten per cent margin, that is up to eighty thousand euro. Treat it as the most uncertain cost in the bill, and never use it alone to justify a project.

Sales reps acting as a switchboard

Twelve reps, and part of their week is not selling: it is entering orders the customer dictates, answering "where are my goods", resending invoice copies, checking the credit limit before closing a sale. In my experience it weighs between fifteen and twenty per cent of their time. A rep is not paid by the hour but on commission, and you pay for that time twice: in the visits they do not make and in the new customers they do not look for.

Translated into margin, for twelve reps, up to thirty thousand euro a year. It is also the cost that resists most, and I will come back to it: if the rep thinks the portal takes their customers away, they will sabotage it, and they are right to think so if nobody has explained how they will be paid on the orders the customer places alone.

The total, for a thirty two million wholesaler with twenty one thousand orders a year, sits between sixty thousand and three hundred and thirty thousand euro a year, and no company takes all five costs at the maximum. The range is wide because the real variable is not how many orders you receive: it is how much of those orders is repetitive work the customer would gladly do alone, if you let them do it well. Run the bill with your own numbers, even roughly, on a single sheet. If your total is below twenty five thousand euro a year, the portal is not your most urgent problem, and further on I will tell you what is.

The share of retyped reorders: the number that decides

If I had to keep a single number from the whole article, I would keep this one: of the order lines your back office retyped by hand over the last twelve months, how many were codes that same customer had already bought in the previous twelve months. I call it the share of retyped reorders. It decides everything, because the portal feature that pays most, reordering from history with the net price already calculated, works exactly on that number, and if you do not know its value you cannot know how much work the portal will really take off you.

The reason this number matters more than the number of customers, the number of codes or revenue is that it tells you whether your back office is doing a job a system can do better, or a job that needs a person. The number of customers alone deceives: fourteen hundred customers who order different things every time, perhaps on quotation, will never use a basket. The number of orders deceives too, because a hundred three line orders of consumables are different from a hundred forty line orders for a building site. The share of reorders instead is hard to fake: either that customer had already bought that code, or they had not.

How to measure it, in one day

You need two things, and the good news is that both are almost always there. The first is the archive of customer order lines over the last two years, with customer, date, item, quantity and price. It lives in the ERP, because orders become delivery notes and invoices. The second is how the order arrived, and this is where you find the first interesting thing: in many companies the channel is not recorded anywhere. It is not a problem: use the user who entered the order. If it is a back office person, the order was retyped; if it is the technical user of the connection with reps or large customers, it was not.

If the data lives in a database, the measurement is a query. This is the form I use on SQL Server. Table names in your system will differ, the substance will not:

-- Share of retyped reorders: lines entered by hand by the back office for codes
-- the same customer had already bought in the twelve months before the order
WITH righe AS (
    SELECT o.IdOrdine,
           o.CodiceCliente,
           o.DataOrdine,
           o.Canale,
           r.CodiceArticolo,
           r.Quantita * r.PrezzoNetto AS Valore
    FROM RigaOrdineCliente r
        INNER JOIN OrdineCliente o ON o.IdOrdine = r.IdOrdine
    WHERE o.DataOrdine >= DATEADD(MONTH, -12, CAST(GETDATE() AS date))
),
classificate AS (
    SELECT r.*,
           CASE WHEN EXISTS (
                    SELECT 1
                    FROM RigaOrdineCliente pr
                        INNER JOIN OrdineCliente po ON po.IdOrdine = pr.IdOrdine
                    WHERE po.CodiceCliente = r.CodiceCliente
                      AND pr.CodiceArticolo = r.CodiceArticolo
                      AND po.DataOrdine < r.DataOrdine
                      AND po.DataOrdine >= DATEADD(MONTH, -12, r.DataOrdine))
                THEN 1 ELSE 0 END AS Riordino
    FROM righe r
)
SELECT COUNT(*) AS RigheTotali,
       SUM(CASE WHEN Canale = 'MANUALE' THEN 1 ELSE 0 END) AS RigheRibattute,
       SUM(CASE WHEN Canale = 'MANUALE' AND Riordino = 1 THEN 1 ELSE 0 END) AS RiordiniRibattuti,
       SUM(CASE WHEN Canale = 'MANUALE' AND Riordino = 1 THEN 1 ELSE 0 END) * 100.0
         / NULLIF(SUM(CASE WHEN Canale = 'MANUALE' THEN 1 ELSE 0 END), 0) AS QuotaRiordiniPercento
FROM classificate;

If the channel does not exist, replace the channel condition with the one on the user who entered the order. On two years of lines the query takes a few seconds with an index on customer, item and date, a few minutes without. Run it in the evening, or on a copy.

Then do the second pass, which is the one that tells the truth: group the same measure by customer and sort customers by number of retyped lines. You will almost always find that twenty per cent of customers generate between sixty and seventy per cent of the back office workload. That is the scope of the first release, and I come back to it later: the portal is not opened to fourteen hundred customers, it is opened to the hundred who make you work the most.

And there is a third calculation, the most convincing when you have to explain the project to a partner: take fifty random retyped orders from last month, open the email or message they came from and time how long it takes to enter them again. Multiply by the orders of the year. It is not a guaranteed saving, because not all will go through the portal, but it is the most concrete figure you can put on the table, and it is built with your data rather than the portal vendor's.

Three clarifications, because the measure is easy to distort without meaning to. Do not count as a reorder a code bought once three years ago: twelve months is the right window for almost every sector, eighteen if you sell seasonal goods. Do not exclude small orders because they are small change: they are exactly the ones where the cost of entry exceeds the margin of the line, and the ones a portal absorbs best. And measure the three customer families separately, if you have them: installers, dealers and contractors have very different shares, and mixing them produces an average that describes nobody.

In wholesalers that have never measured it, the result often sits between fifty and seventy five per cent. In manufacturers selling to dealers it is somewhat lower, and for those selling configured products it drops below thirty.

The four thresholds, and what you can do at each

Below thirty per cent: your orders are not repetitive. Every order is a new choice, often a quotation turning into a confirmation. A portal built like a basket pays little on orders here, and pays instead on information: shipment status, documents, availability, spare parts. If you sell configured products, the piece you need first is the configurator, and the portal comes later as a channel for spare part reorders.

From thirty to fifty five per cent: the portal pays if you focus it. It is the most common band among manufacturers selling to dealers. The average hides very repetitive customers next to customers who always order different things. With a first release opened to customers whose share exceeds sixty per cent, reorder from history and visible net price, the portal pays back, and the others come when they see it works.

Above fifty five per cent: the back office is doing the job of a software feature. It is not the people's inefficiency: the customer simply has no other way to say "same as last time". Here the portal almost always pays, and the risk is not return but adoption: the project fails if customers do not use it, and customers do not use it if the price they see is not theirs or availability is wrong.

Never measured: you do not know. It is the most common case, and it is no fault: nobody asks for that number, neither the accountant nor whoever sells you the portal, who in fact prefers not to know. And it is also the best case, because the measurement costs one day and tells you, before spending a euro, whether you have a thirty thousand or a three hundred thousand euro a year problem.

The price list is the project, not the design

Every B2B portal I have seen fail failed for the same reason, and it was not the look: the customer saw a price that was not theirs. They saw it higher, and phoned to ask. They saw it lower, ordered, and then found a different figure on the invoice. After two times they stop trusting it, and a customer who does not trust the online price goes back to email, this time with one more reason. The basket, the photos, the family filters are the part you see in demos. The right net price is the part that decides whether the project exists.

The problem is that in companies selling to other companies the price is not a number, it is a calculation. There is the base price list, sometimes two, one for installers and one for dealers. There are discount bands, often by product family rather than by customer. There are net prices agreed with important customers on certain codes. There are quantity breaks, timed promotions, campaigns for a group of customers, year end rebates that are not on the invoice, free shipping above a minimum order. And there is the part not written anywhere: the extra discount the rep grants verbally to close.

One rule, written, the same for every channel

The first question is not which portal to buy, but whether today the price of an order line is the same when the back office enters it, when the rep enters it and when the ERP calculates it on the invoice. In more than half the companies I look at the answer is no, and nobody knows until someone puts two channels side by side. A portal connected to that chaos makes it visible to the customer, which makes it worse.

The solution is not sophisticated, it is disciplined: a single function decides the price, with a written order of precedence, and every channel calls it. In the ERP, if the ERP does it well; in a separate service, if the ERP cannot or the rules are too many. This is the form I use when I build it, reduced to the essentials:

using System;
using System.Collections.Generic;
using System.Linq;

public enum Origine { NettoCliente, Promozione, ScontoFascia, Listino }

public sealed record RegolaPrezzo(
    Origine Origine,
    string? CodiceCliente,
    string? FasciaCliente,
    string? Famiglia,
    string? CodiceArticolo,
    decimal QuantitaMinima,
    DateOnly ValidaDa,
    DateOnly ValidaA,
    decimal? PrezzoNetto,
    decimal? ScontoPercento);

public sealed record PrezzoCalcolato(decimal Prezzo, Origine Origine, RegolaPrezzo? Regola);

public static class MotorePrezzi
{
    // A single function decides the price, and the portal, the reps and the back office all call it
    public static PrezzoCalcolato Calcola(
        string codiceCliente, string fasciaCliente, string codiceArticolo, string famiglia,
        decimal prezzoListino, decimal quantita, DateOnly data, IEnumerable<RegolaPrezzo> regole)
    {
        var candidati = regole
            .Where(r => r.ValidaDa <= data && data <= r.ValidaA && quantita >= r.QuantitaMinima)
            .Where(r => r.CodiceCliente is null || r.CodiceCliente == codiceCliente)
            .Where(r => r.FasciaCliente is null || r.FasciaCliente == fasciaCliente)
            .Where(r => r.CodiceArticolo is null || r.CodiceArticolo == codiceArticolo)
            .Where(r => r.Famiglia is null || r.Famiglia == famiglia)
            .Select(r => new PrezzoCalcolato(Applica(r, prezzoListino), r.Origine, r))
            .ToList();

        // The net price agreed with the customer wins even over a lower promotion:
        // it is a written agreement, and the customer must find it unchanged on the invoice
        var netto = candidati
            .Where(c => c.Origine == Origine.NettoCliente)
            .OrderByDescending(c => c.Regola!.QuantitaMinima)
            .FirstOrDefault();

        if (netto is not null)
        {
            return netto;
        }

        return candidati
            .Append(new PrezzoCalcolato(prezzoListino, Origine.Listino, null))
            .OrderBy(c => c.Prezzo)
            .ThenBy(c => c.Origine)
            .First();
    }

    private static decimal Applica(RegolaPrezzo regola, decimal prezzoListino) =>
        regola.PrezzoNetto
        ?? Math.Round(prezzoListino * (1 - (regola.ScontoPercento ?? 0m) / 100m), 4, MidpointRounding.AwayFromZero);
}

The code is not the interesting part; the rule it contains is. Take a ball valve with a list price of twelve euro fifty. A band B installer has thirty eight per cent off the valve family, and pays seven seventy five. This month there is a promotion at seven ten above ten pieces, and if they order twenty they pay seven ten. The big customer in the area has an agreed net price of seven forty, and pays seven forty even though the promotion is lower, because that net price is a yearly agreement and not a race to the bottom. You may decide the rule should be different, for instance that the lowest price always wins. What you cannot do is let the rule change depending on who enters the order.

And the function also returns where the price comes from. It looks like a detail and it is what saves the most phone calls: if the customer sees "agreed net price" or "promotion until 7 October" next to the price, they do not call to ask why it cost more last week.

The rep's verbal discount

What remains is the unwritten part, and it is a commercial decision before a technical one. Companies with a working portal solved it in one of two ways. Either the rep has a declared room for manoeuvre, for instance up to three per cent more on certain families, which they enter into the system themselves and which stays visible to the customer for a defined period. Or the verbal discount disappears, and becomes an agreed net price with an expiry date. The way that does not work is the one almost always in place, the discount granted on the phone and applied by hand by the back office when retyping the order: with the portal nobody retypes that line any more, and the customer pays full price.

The connection with the ERP: where it really breaks

The ERP remains the source of truth for almost everything: customers, items, prices, stock, orders, documents, due dates. The portal is a window onto that data plus a place where orders are born. Put like that it sounds simple, and the connection quote is often the most underestimated line of the whole project. There are eight flows, and each has a direction, a frequency and a typical way of breaking.

Customer records and delivery addresses. From the ERP to the portal, once a day is enough. It breaks when the same customer has three codes, one per site, and the portal does not know which to show. Decide first who the portal user is: the company, the single site or the person ordering, and almost always the right answer is the person, linked to one or more delivery addresses.

Items, descriptions and images. From the ERP, or from a separate product archive, to the portal. It breaks on one thing only, and always: ERP descriptions are written for the warehouse, abbreviated, full of internal acronyms, and the customer does not find "brass fitting 3/4 MF" by searching "three quarter male female fitting". Cleaning the descriptions of the top two thousand best selling codes is the most boring job of the project, and worth more than any search engine.

Net prices. From the ERP to the portal, or calculated on the fly by the single function I described. It breaks when the portal has its own copy of the rules and the ERP has its own, and the two diverge at the first promotion. One source, always.

Availability. From the ERP to the portal, every five to fifteen minutes, net of allocated stock. It breaks when the portal shows physical stock and not available stock, meaning stock already promised to other orders: the customer orders twenty pieces that appear in stock, but they are all allocated, and delivery fails. If you have several warehouses, decide first which availability to show to which customer. Stock and allocation are covered at length in warehouse management software.

Orders. From the portal to the ERP, immediately, with a confirmation coming back. It is the flow everyone designs and almost everyone designs badly in one point: the order received and not imported. If the connection stops at eleven in the evening, at midnight the customer must still see the order as received and not yet confirmed, and the next morning someone must find a list of pending orders, not an error email lost in spam.

Order status, delivery notes and tracking. From the ERP to the portal, at every status change. It is the feature that removes the most phone calls after price, because "where are my goods" is the question the back office hears most. If you deliver with your own vehicles, the delivery round comes in here too, and the link with trip planning is covered in transport management software.

Invoices, credit notes and due dates. From the ERP to the portal, once a day. It rarely breaks and is much appreciated: the customer who downloads the March invoice on their own is a customer who does not call accounts.

Credit limits and account blocks. From the ERP to the portal, before confirming every order. It is the flow nobody puts in the quote and the one that makes sales and accounts argue in the first month. The portal must know whether that customer can order, and up to how much, and must tell them politely. A blocked customer who orders online and discovers the block the next day on the phone is worse than a customer without a portal.

The test to see whether the connection holds: take an order placed from the portal and follow it by hand to the invoice, meanwhile changing the price of an item, dropping stock below the ordered quantity and blocking the customer for an overdue invoice. If in all three cases the customer sees the right thing at the right time without anyone stepping in, the connection is done. If not, you have found where it will break in the first month.

Why customers do not use it, and how to get them to

The Monday morning wholesaler did what almost everyone does: portal ready, an email with credentials to all fourteen hundred customers, a banner on the website, and then waiting. After a year forty one customers used it, almost all to download invoices. The chart shows the difference between that route and the other, and it is the biggest difference in the whole project, bigger than any technical choice.

Trade customers do not adopt a tool because it exists. They adopt it when it is faster than the way they use today, and the way they use today is sending a message to a person they know who sorts everything out. To beat that message, the portal must do three things better: let you order what you always buy in under a minute, tell you the true price and true availability without asking, and not let you make mistakes. Everything else comes later.

The features that bring customers in

Reorder from history. The list of codes that customer has bought, sorted by frequency, with today's net price and a quantity field next to each. It is the feature that matters most and the one least visible in demos, because it does not impress. For an installer who always buys the same forty codes it is worth more than the whole catalogue.

Quick order by code, and file upload. Those with their own warehouse and their own ERP want to paste twenty lines with code and quantity, or upload a file, not search products one by one. If you sell to dealers it is the second most important feature, and the customer's own code must be accepted too, not just yours.

The phone before the big screen. The installer orders from the van, at seven in the evening, with a thumb. If reordering does not work well on a phone, for that family of customers the portal does not exist.

Price and availability in search results, not on the product page. A customer who has to open every product page to know what it costs and whether it is in stock goes back to the phone after three searches.

The first hundred customers, one by one

The route that works is almost the opposite of the email to everyone. Take the hundred customers generating the most retyped lines, the ones that came out of the measurement, and open it only to them. For each one a back office person or the rep spends twenty minutes, in person or on a video call: creates the user, has them place their first reorder from their history while there, shows them where to see the status of their goods. Then for a month, when that customer sends an order by email, the back office enters it as always but replies with two lines: done, and next time you will find it ready here.

It is not a campaign, it is a habit to move, and habits move one customer at a time. With this route, in companies that followed it with discipline, after eighteen months between forty and fifty five per cent of order lines go through the portal. With the email to everyone you stay below ten. The cost of the first route is about thirty five hours of back office and rep time over three months, less than one week of one person's work.

Sales reps, the resistance nobody puts in the plan

The rep sees the portal as a threat, and from where they stand they are right: if the customer orders alone, what is the rep for, and above all who gets the commission? If that question does not have a written answer before launch, the rep will do what anyone would: tell their customers the portal has the wrong prices, and keep taking orders verbally.

The answer that works is simple: portal orders placed by a rep's customers pay commission to that rep, as if they had taken them. It costs nothing, because you were already paying that commission, and it turns the rep from enemy into promoter: the time not spent dictating orders goes into visiting new customers, and their customers order more because they order when they need to. Add that the rep sees in the portal what their customers see, abandoned baskets included, and you find yourself with twelve people pushing the project instead of braking it.

How much a B2B portal costs: module, platform or custom

The figures below are what I see on the Italian market for companies between twenty and two hundred employees, and they are complete figures: not the list price, but what the company really spends in the first year, including setup, data cleaning and connection.

The portal of the ERP you already own

Many ERPs common among Italian SMEs have a customer portal or B2B ecommerce module, sold by the same vendor. It costs between eight and thirty thousand euro in setup plus a fee between one hundred and fifty and six hundred euro a month. The advantage is huge and often underrated: prices, availability, credit limit and documents are already the ERP's, and the connection, the part that costs most in the other cases, does not exist. The limit is almost always the customer experience: slow search, awkward reordering, neglected phone use. Ask to try it on a phone, with a real user from one of your customers, before looking at anything else.

A subscription B2B platform

Between three hundred and two thousand euro a month, depending on number of customers, codes and features, and some add a percentage of transaction value which on thirty two million becomes the main cost: read the contract on that point before anything else. On top there is setup, between fifteen and sixty thousand euro, which is almost entirely three jobs: bringing in catalogue and descriptions, rebuilding the pricing rules inside the platform, and connecting it to the ERP in both directions. The customer experience is usually very good, because it is the vendor's trade.

Ask three things before signing, and get them in writing: whether pricing rules live in the platform or are read from the ERP, how much the connection costs in the second year when the ERP vendor releases a new version, and what happens to your customers' data, users and history included, if you cancel. The first is the one that decides whether in two years you will have two price lists drifting apart.

A custom portal

It starts at thirty five thousand euro for the core that really matters: users per customer and delivery address, catalogue with net price calculated by a single function, availability net of allocations, reorder from history, quick order by code, orders entering the ERP with confirmation, goods status, downloadable delivery notes and invoices, credit limit checked before confirmation, all designed for the phone first. It reaches one hundred and fifty thousand with campaigns and pre orders, online returns, a rep area, payments, multiple languages, connection with the configurator and file exchange with large customers. Add fifteen to twenty per cent a year for maintenance, and put it in the bill from the start: a custom portal without maintenance is a debt that falls due at the first ERP upgrade.

The threshold in euro

The rule I use, which holds for most Italian companies below two hundred employees: below twenty thousand euro a year of total portal spend, across fees, commissions and setup spread over the years, the ERP module or the subscription platform almost always wins. Above it, the maths changes, but more slowly than in other projects, as the chart shows: break-even between the two routes falls between year four and year five, and custom really pays only if you keep the portal for a long time and grow it.

That is why the euro threshold is not enough on its own, and there are three cases where custom wins even below that figure. When pricing rules are so intricate that no platform represents them without customisation, and then you pay for custom work inside the product, at a higher rate and without owning it. When the portal must talk to several systems at once, typically ERP, warehouse and configurator, and the connection weighs more than the platform. And when the platform takes a percentage of transaction value and that value is high: with thirty million going through online, even zero point five per cent is a figure that pays for a custom portal every year.

And there is one case where the product always wins, even above the threshold: when nobody in the company has the time and authority to follow the project, and above all customer adoption, for six months. A beautiful custom portal used by forty customers costs more than a mediocre platform used by four hundred.

The questions to ask before signing, and the hundred order test

Demos are built to show what the product does well: a catalogue with nice photos, a smooth basket, a sample customer with a simple price list. Six questions shift the conversation from the product to your problem, and they are best asked in order.

Where does the rule calculating the net price live, and what happens when I change a promotion in the ERP? If the answer is that rules must be recreated in the platform, ask who will keep them aligned and what that work costs per year.

Is the availability the customer sees physical stock or available stock, and how often is it updated? If the answer is physical stock, once a night, in the first month you will have customers angry about missed deliveries.

What does the customer see if the connection with the ERP is down? Ask to see the broken case, not the straight one: order sent while the ERP is in maintenance, item deleted with an open order, blocked customer who already has a full basket.

How do you reorder from history on a phone? Do it yourself, standing, one handed. If ten lines take more than a minute, your installers will not use it.

Who owns the customer record? Two systems that can both create a customer produce hundreds of duplicates in six months. A new customer is born in the ERP, always, and the portal receives it.

If I stop tomorrow, what do I take away? An Excel export of orders is not enough: you need users, preferences, saved baskets, history and pricing rules, in a reusable format.

Then there is the test I always recommend, and almost nobody runs. Give the vendor a hundred real orders from last month, taken from those retyped by hand, including three customers from different bands, an agreed net price, an overlapping promotion, an item with partial availability and a customer blocked by accounts. Ask them to load those customers and rules and to redo the orders from the portal, with a person from your back office sitting next to them. Then look at three things: whether the price of every line is identical to the invoice you actually issued; whether the back office can explain to the customer why a price is what it is without opening the ERP; whether the blocked customer discovers the block before sending the order and not after.

It is not a feature test, it is a method test: you watch how many questions the vendor asks about your commercial rules, which exceptions they propose to remove and how long it takes. If the hundred orders match to the cent, you have found your vendor. If they do not, you have discovered where the problem lies before paying for it, and the problem is almost never the software: it is pricing rules nobody ever wrote down, or discounts that exist only in the head of whoever retypes the orders.

The three things to fix before buying anything

There are three jobs that cost little, take a few weeks and without which any B2B portal returns half: writing down the pricing rules, cleaning the codes customers actually buy, and deciding what happens to the reps. They must be done before, not after, because after the project has started the choices are made by whoever configures it, someone who has never spoken to one of your installers.

Pricing rules written in a table. Not a lawyer's document: a table saying which price lists exist, which discount bands and on which families, which agreed net prices and with what expiry, which promotions and how they overlap, and the order of precedence when several rules apply together. Then take two hundred lines invoiced last month and recalculate the price with the table. The lines that do not match are your verbal discount, and you will almost always find they are worth more than you thought. It is the most rewarding of the three jobs, and it pays even if you never build the portal.

The top two thousand codes, cleaned. The reorder measurement produces the list of codes your customers really buy, and it is much shorter than the catalogue: often two thousand out of thirty eight thousand make eighty per cent of lines. For those codes you need a description a customer understands, the right selling unit, the minimum pack, a decent photo and, if you have it, the manufacturer's code. Two people for three weeks. The other thirty six thousand codes can wait.

Reps and back office, in writing. How reps are paid on orders customers place alone, what room they have on price and how they enter it, who in the back office follows the first hundred customers and with what goal. One page, discussed with them beforehand, not announced afterwards. Without that page, the project has twelve opponents before it starts.

I add a way of starting that is not a job but a choice: begin with a single customer family, the one with the highest reorder share, and run it for three months before opening to the others. Companies that open to all customers with the whole catalogue and all features arrive at month three with a portal used by few and a list of complaints about prices, and the second launch is much harder, because by then customers already know that thing did not work.

If your total of the five costs was below twenty five thousand euro a year, here is your most urgent problem: these three jobs, not the portal. Above all the first. Write down the pricing rules, recalculate the invoiced lines, and only then look at products.

Where to start

You start from a small first release, because a B2B portal is not an IT project: it is a project that moves a habit of your customers and a piece of your back office's work, and habits move well when they move a little at a time. The first release that almost always works is this. The hundred customers with the most retyped lines. Their net price, calculated by a single function the ERP also uses. Availability net of allocations, refreshed every quarter of an hour. Reorder from history and quick order by code, designed for the phone. The order entering the ERP without being retyped, with confirmation going back to the customer. Goods status and downloadable documents. Credit limit checked before sending. One report, on the first Monday of the month, with the share of lines placed through the portal by those hundred customers, the lines still retyped by hand and the ten customers who stopped using it. Nothing else.

With that scope you are live in a few weeks with the ERP module, in two or three months with a platform or a custom portal. From then on you repeat the reorder measurement every month, first on those hundred customers and then on all of them. If it falls, the project is working. If it does not, the problem is a price the customer does not recognise, wrong availability or a rep who does not believe in it, and no extra feature will fix it. Everything else, campaigns, pre orders, online returns, the rep area, file exchange with large customers, is built on top of a channel customers trust, and costs less because by then you know what you really need.

The Monday morning sales director, in the end, did not rebuild the portal for the first two months. They wrote the pricing rules table, and recalculating two hundred invoiced lines they found that one in nine did not match, almost always because of a discount given verbally and never recorded. They cleaned one thousand nine hundred codes. They decided that portal orders paid commission to the customer's rep, and told the twelve reps in a meeting before they could ask. Then they reopened the portal, rebuilt in the meantime around the ERP the company already had, to the one hundred and ten customers who gave them the most work, one by one. After fifteen months forty eight per cent of order lines come from the portal, the back office has stopped doing Monday overtime and two of the six people follow the customers who were buying less. The inbox at a quarter past nine on Monday has twenty two messages, and almost none is an order.

If you are running this calculation now and want to know which side of the threshold you are on before spending anything, send me two pages: how your orders arrive today and who enters them, how your pricing rules are built and which ERP you use, plus the two numbers from the test, the order lines of the last twelve months and how much of those retyped by hand were reorders. In half an hour I will tell you whether yours is a problem of pricing rules to be written, of the ERP module you already own, of a subscription platform or of a custom build. In the cases where the problem is the rules and not the software I will say so anyway, because a customer who buys the wrong thing comes back angry. You can get in touch to run that calculation together.

If you are still framing the problem, three readings that sit around this one. What happens to the availability the customer sees on the portal, across stock, allocations and picking, is in warehouse management software. If you sell products the customer must choose among variants before ordering, the piece that comes before the portal is in product configurator. And if you want to know how much margin hand applied discounts really leave on the table, customer by customer, before deciding where to start, the answer is in management control software.