Wholesale orders through a messenger, posted straight into the accounting system

About the client

A food wholesaler with more than 300 regular B2B customers: shops, cafés and small chains. Accounting runs in a small-business edition of their ERP. Orders arrived by messenger, phone and email, and sales reps copied them into the system by hand.

A classic wholesale situation: many customers, repeating orders, and every one of them passing through a person’s hands.

The problem

How an order used to go

The customer messaged a rep in free text: “bring the usual, plus two crates of water.” Then:

• the rep recalled what “the usual” meant, clarified the lines, checked stock, quoted a price;
• entered the order into the accounting system by hand;
• sent an invoice, sometimes hours later if they were busy.

With 300-plus customers and four reps that created a queue: at peak an order took twenty to forty minutes, some requests got lost in the conversation, and customers rang to ask about status.

In money

Reps spent most of the day on mechanical intake and transfer instead of working with new customers and upselling. Lost and duplicated requests, manual entry errors, delayed invoices — by the department head’s estimate this cost the company a noticeable share of repeat orders, which went to faster suppliers.

Why not a web portal

A B2B portal was the first idea. But portals have a problem: customers have to be made to use them — another site, another password, another tab. Half of them would have carried on messaging anyway. The customers already lived in the messenger, so we closed 80% of the scenarios with a bot for a fraction of the cost of a portal, and left the portal idea for later if we hit a ceiling.

The approach

Discovery

A few days spent going through real order conversations and the structure of the accounting system. The key finding: 70% of orders are a repeat or a small variation of the last one. So the main scenario is not “pick from a catalogue from scratch” but “repeat the last order and adjust it.”

Key decisions

aiogram plus an integration layer. A webhook bot, with a separate FastAPI service as the layer to the accounting system over its HTTP services. All the difficulty sits in the integration layer, not in the cleverness of the bot.

Real-time stock validation. Before accepting a line, the bot checks availability through the accounting HTTP service, so a customer never orders what is not there.

Documents from the accounting system, not from the bot. The invoice and the delivery note are produced by the accounting system, which is the source of truth for prices and legal details; the bot hands the customer a finished PDF. No duplication of pricing logic.

The solution in detail

Bot scenarios

• Repeat the last order — the bot shows it, the customer adjusts quantities and confirms.
• Order from the catalogue — navigation by group, search by name or item code, with the customer’s own contract prices.
• Status — “where is my order”, “when is delivery” — with no rep involved.
• Documents — invoice and delivery note on request, from the accounting system, as PDF.
• Escalation — a “call a human” button that passes the conversation context across, so the rep does not start from scratch.

Posting into the accounting system

A confirmed order goes into the accounting system as a document over the HTTP service: the counterparty is resolved from the messenger account (matched when customers were onboarded), lines by item code, prices by the customer’s wholesale tier. The rep sees the order already in the system and steps in only where a human decision is needed.

Observability

Every order is logged, and exchange failures raise alerts in the team’s channel. If the accounting system is unavailable, the bot accepts the order into a Redis queue and posts it as soon as the connection returns, so the customer never hits an error.

The hardest parts

Matching customers to counterparties

The problem. A messenger account has no connection to a counterparty record in the accounting system — and without that link you can neither apply prices nor post the order.

The fix. A one-off linking procedure: on first use the customer confirms their phone number, the bot finds the counterparty by that number and links the accounts. Ambiguous cases — several legal entities on one contact — go to a rep for manual confirmation.

”The usual”, without magic

The problem. Customers phrase orders informally and expect the bot to understand “the usual”.

The fix. We did not build guesswork on a model. We built an explicit, predictable “repeat the last order” mechanic with editing. That is more reliable and more legible to the customer than an AI that occasionally gets quantities wrong.

Results

Six weeks after launch

• 72% less time to place an order — from twenty to forty minutes down to a few minutes; repeating the last order takes under a minute.
• Zero manual transfers of requests from messenger into the accounting system.
• An invoice immediately rather than hours later.
• MVP in three weeks, the full feature set in a month and a half.

Reps moved from mechanical intake to upselling and new customers. The web portal idea has not come back up: the bot covered the main scenarios.

What changes for each role

A bot beats a full portal where customers already live in the messenger. What that gives each participant:

The regular customer. A “repeat the last order” button covers the main wholesale scenario: adjust quantities, confirm, receive a PDF invoice. Ordering takes under a minute from a phone, and there is nothing to learn, because the interface is already familiar. Stock is checked immediately, so “we ordered and then got a call saying it was out” stops happening, and prices shown are their own contract prices.

The sales rep. The mechanics of intake disappear entirely: requests from the messenger post into the accounting system without manual transfer. The bot answers “where is my order” and “when is delivery” on its own, and when a conversation escalates the rep sees the full context instead of starting over.

The accounting system specialist. The integration runs over HTTP services: real-time stock checks, the order posted as a document, invoices produced by the system itself. Pricing logic is not duplicated in the bot — there is one source of truth, so channels cannot disagree.

The IT director. The Redis queue handles the main failure mode: if the accounting system is temporarily unavailable, the bot accepts the order and posts it once the connection returns. The customer does not hit an error and does not leave for a competitor because of somebody else’s outage.

The commercial director. The bot covers most of a B2B portal’s scenarios for a fraction of the cost. That is a deliberate trade: where the customer base already sits in a messenger, a portal adds less functionality than it adds friction.

Stack

• Bot and backend: Python 3.12, aiogram, FastAPI, Redis, PostgreSQL, structlog
• Accounting: HTTP services for posting orders and issuing documents
• Infrastructure: Docker Compose, alerts into a team channel

When this approach fits

It fits if:

• there are many repeating B2B orders currently arriving by messenger and phone;
• reps copy requests into the accounting system by hand and lose time on mechanics;
• customers already live in a messenger, and making them learn a web portal is a losing proposition.

It does not fit if:

• you need complex catalogues with configurators, multi-level roles and a branded interface — then you need a full B2B platform;
• every order is unique and requires engineering selection — a bot will not replace the rep.