A messenger bot instead of a B2B customer portal: when it works and what it costs

Short answer: a messenger bot covers most day-to-day scenarios of a B2B customer portal — orders, order status, documents, notifications — for 20–30% of what the portal costs. An MVP takes three to five weeks. You need the full portal when large catalogues, multi-level roles or branded interface requirements enter the picture.

Here is where the boundary runs.

Why B2B customers want a bot in the first place

At a typical distributor or manufacturer, communication with wholesale customers looks like this: orders arrive by messenger and email, a sales rep copies them into the accounting system by hand, the customer calls to ask about status, the rep goes and looks it up and calls back. Every step is manual work and delay.

The classic answer is a B2B portal. But portals have a problem people rarely mention: you have to make customers use it. Another site, another password, another tab. Half the customers carry on messaging the sales rep anyway.

A bot removes the barrier to entry, because the customer is already in the messenger. Nothing to install, no password to remember, no interface to learn.

What a bot does well

In our experience bots comfortably cover:

• Order intake — by catalogue, by part number, or by repeating the last order, with stock validated against the accounting system in real time.
• Status queries: where is my order, when does it ship, is it in stock — with no sales rep involved.
• Documents: invoices, delivery notes, reconciliation statements, on request, as PDFs.
• Notifications: shipment, price change, a waitlisted item arriving, overdue receivables.
• Escalation to a human — a “talk to my rep” button that carries the conversation context across.

Technically this is a webhook-based bot plus an integration layer to your accounting system and CRM. No magic — and it is that integration layer, not the cleverness of the bot, that determines how hard the project is.

What a bot does badly

The honest limits, and the reasons a portal sometimes wins:

1. Large catalogues with complex filtering. Picking one item out of forty thousand by eight parameters in a chat interface is misery. In our experience the boundary sits somewhere around five hundred to a thousand items with simple navigation.
2. Multi-level roles and approvals. A buyer creates the order, a manager approves it, accounting sees only the invoices. Possible in a bot, but cramped.
3. Analytics and reporting. Charts and pivot tables do not belong in a chat.
4. Branding. The bot lives inside the messenger’s interface and very little of your design survives. Partly solvable with a mini app, which is a hybrid of bot and web application.

What drives the cost

Three tiers, roughly:

• MVP: order intake, statuses and one integration. Three to five weeks.
• Production: catalogue, documents, notifications, CRM. Two to three months.
• Hybrid with a mini app: a web interface inside the messenger. Three to four months.

The main cost factor is not “the bot”, it is the integrations: how many source systems, whether the accounting system already exposes usable HTTP services or they have to be written, and whether the exchange needs to run in both directions.

One thing to check when evaluating a vendor’s estimate: if there are no separate lines for the accounting integration and for handling exchange failures — the system is down, a document did not post — the estimate is incomplete, and that will surface halfway through the project.

The practical test

Ask yourself two questions:

1. How many items does the customer actually order? If a typical order is ten to fifty items from a familiar set, a bot will cope. If every order means searching a large catalogue, you need a portal or a mini app.
2. Who is the user? One buyer who already lives in messengers — a bot. A whole department with roles and an approval process — a portal.

A frequent working strategy is to start with the bot as the MVP: spend a month proving that customers will self-serve at all, collect the real scenarios, and design the portal on that data — or discover the bot was enough and save the portal budget entirely.

In short

• A bot is the fastest way to give B2B customers self-service: three to five weeks.
• Cost is driven by integrations, not by conversation design.
• A portal is warranted for large catalogues, roles and branding — and it should be designed using the data the bot collected.

If you are unsure whether you need a bot or a portal, describe the process and we will cost out both. The related read is build versus buy.