Proactive customer service in B2B: the manager hears first

B2B customers rarely complain before they leave. They space their orders, drop a product line, let a payment run late, and the invoice shows it months later. At a distributor with tens of thousands of customers, we run a proactive customer service that gets the account manager there first: five alerts, computed on the company's own data, nightly or the moment the event happens, each one sent to the person who has to act, with the reason and the next step.

Where a B2B customer is lost

The distributor sells to other companies in several markets, through its own sales force and subsidiaries. Its data sits in seven systems, among them orders, invoicing, the warehouse and the customer portal. Well-built systems, all of them. Answering one business question still meant opening five screens and joining them by hand.

The most expensive question was this one: which customers are reducing their activity right now? That is where B2B customer churn hides: by the time someone sees it in the invoicing, the loss has been running for months.

What is proactive customer service

Proactive customer service, also called proactive customer care or proactive customer support, means the company sees the problem before the customer has to raise it. Reactive support answers the complaint about a late order. Proactive service knows about the delay before the complaint exists. In the system described here, the person who sees it first is the account manager, and whether the customer is contacted is their call. The reactive side, one support address per customer, is in our post on B2B customer service. This one is about what happens before anything arrives.

A consumer writes an angry email. A purchasing manager just buys from someone else next month. The signals are already in the company's systems, spread across orders, invoices, incidents, and quotes. Nobody has time to read them account by account, every day, for a portfolio of thousands.

That is the job of the monitoring agents: rules that run on the connected data and send what they find. They read the whole portfolio every night, and immediately for the events that cannot wait: a new order against an overdue balance, a quote that went cold. The five alerts in this post run at the distributor; the data model underneath and the agents on top of it are what we build for every client, and the agents change with the business. When a condition is met, the finding goes as a written report to the person who has to act, inside the Hellomatik application, and by email or messaging for the people who do not open it every day.

Five proactive customer service examples

Each alert has a trigger and a recipient, and its message ends with the next step. Four go to the account manager; the overdue balance goes to finance, and the manager sees it on the customer's file.

Abandoning customers. When the time since a customer's last order passes twice their own usual interval, the account manager gets the account's state and the suggested contact, plus the product lines the customer has stopped buying.

Receivables and collections. Overdue amounts and returned payments are checked against the credit limit when a new order comes in, before it ships. Finance gets the amount with its age and a recommendation: block, contact, or continue.

Unresolved issues. An open issue that keeps dragging on, or the same reason coming back on the same account, raises a warning to the account manager.

Unconverted demand. Quotes and carts that did not turn into an order reach the account manager the same day, with their amount and the circumstances that may explain them.

Delivery commitments. Delivery dates promised to the customer in writing are checked against the carrier. The manager is warned before the complaint arrives.

Abandoning customers: what the alert carries

The rule is per customer, and it feeds two things the system keeps for every account. One is a health score from 0 to 100, with the reasons behind it. The other is a situation, one of six states: new, growing, stable, declining, at risk, or lost. A customer who orders every ten days and goes twenty without ordering is flagged. A customer who orders twice a year is not flagged in month three. The seasonal pattern, each month's usual behavior for that customer, reduces the noise.

The alert does not stop at "this customer is at risk." It says which product lines that customer used to buy and has stopped buying, each one with what it brought in last year. That is the list the account manager needs for the call.

At the distributor, we ran that computation across a portfolio of tens of thousands of customers. In one account alone we found more than a thousand individual products (SKUs) abandoned completely across the lines it had stopped buying, led by a line that had brought in tens of thousands of euros the previous year and nothing in the current one. That figure did not exist in any of the seven systems until the rule produced it.

Why the ERP and the CRM do not raise this alert

The ERP records purchases. It does not know what a normal interval is for this customer, so it cannot tell a slow month from an account that is leaving. The CRM knows the contacts and the visits, and its health score, where there is one, is filled in by hand. Neither holds the abandoned lines with last year's revenue next to each, because that number has to be computed from orders and invoices against the catalog, every night.

That computation needs one data model of the account: the customer, the order and what it contained, the invoice, the payment, the open issue, and the account manager, related to each other and kept up to date. The alerts are rules on top of it. That is the whole proactive support model.

How to structure proactive customer follow-up: the Monday plan

Every alert goes out when its condition is met: the overdue balance the moment a new order comes in, the quote the same day, the doubled interval the morning after the nightly run. The Monday plan sits on top of them, and on the platform it is the sixth agent. Each week, every account manager receives the accounts in their portfolio that need a contact, ordered by priority, with the reason and the file to read before the call.

The plan does the part of the job nobody has time for: scanning thousands of accounts to decide who deserves a call this week. The system decides who is on the list and brings the file. The call is the manager's.

How an alert is tested before going live

We do not switch on an alert the day we build it. It goes through four steps first.

A threshold that flags every seasonal customer in January shows up in the replay, before anyone receives it.

What this system does not do

It does not decide why. The alert says the interval doubled and which lines stopped. Whether the customer switched supplier or just changed season is for the manager to find out on the call.

It does not run on disconnected systems. Orders, invoicing, incidents, and quotes have to be readable. At the distributor that meant seven systems and more than seven thousand source tables. Connecting them is the longest part of the work, and it is done once.

What is contracted is a project. A two-week audit of the systems, then the connection, then each alert, one at a time. The data model that comes out of it is the company's. The case is on our case page for this distributor, in Spanish.