Distribution and Field Sales Management Software

Distribution runs on two numbers that rarely agree: what was despatched, and what actually sold through to outlets. Primary sales are recorded properly because they are invoiced; secondary sales depend on whatever the field team remembers to report.

The field layer is where the visibility disappears. Beat plans are issued and followed approximately, an order taken at a counter is written in a book, and receivables build quietly at retail until someone runs an ageing report and starts making phone calls.

Primary, secondary and the number nobody has

Primary sales are the movement from the company to its distributor or stockist. They are invoiced, so they are recorded accurately by definition — the accounting system cannot avoid knowing them.

Secondary sales are the movement from the distributor onward to retail outlets. They are the number that actually tells you whether the product is selling or merely sitting, and they are the number that most manufacturers see late, partially, or as a monthly figure typed in by the distributor.

The gap between those two is stock in trade: goods invoiced, paid for and still on somebody’s shelf. A month of strong primary sales into a channel that is not selling through is not growth, it is inventory being pushed down the pipe, and it comes back as returns, expiry claims and a distributor who will not take the next load.

What usually breaks first

Order capture. An order arrives as a message, a photograph of a handwritten sheet or a phone call, and somebody at an internal desk retypes it. Product names are whatever the retailer calls them, quantities are sometimes cases and sometimes pieces, and a scheme agreed verbally in one conversation is invisible to whoever processes the order later. The desk stops being a sales function and becomes a transcription service that also absorbs the errors.

Coverage goes next. A beat plan is issued, the field officer works the route approximately, and the report arrives in a group chat. There is no dependable record of which outlets were visited, what was discussed, or which visits produced no order and why. Any conversation about coverage becomes an argument between two assertions.

Then collections. Outstanding balances live in accounts, so a new order is accepted from an outlet already well past its credit terms and the problem surfaces weeks later when somebody is sent to recover it.

What a beat plan has to be to be worth issuing

A beat plan — the permanent journey plan, in the vocabulary most field organisations use — allocates outlets to days so that every outlet is called on at its intended frequency. An A-class outlet might be worked weekly and a C-class outlet fortnightly, and the plan is the mechanism that makes that a policy rather than a preference.

For it to survive contact with the road it has to produce, at minimum:

• The list of outlets due today, in an order that reflects the actual route rather than the database
• A visit record whether or not an order was taken, with the reason when none was
• The time and location of the visit itself, captured on site rather than at the moment of upload
• Planned coverage against achieved coverage, per officer and per route, without anybody compiling it

The two derived measures worth watching are coverage — how many of the outlets due were actually called on — and the productive call rate, meaning the proportion of visits that produced an order. A route with high coverage and a low productive rate is a different problem from one with low coverage, and only the second is solved by pushing the officer harder.

Coverage reporting is only useful if it names people rather than counting them. A figure saying eighty per cent is an argument; a list of the four officers who did not start a shift and the six outlets nobody has been to since April is a morning’s work. The same applies to the visit list itself, which should build itself from what the data already knows: outlets assigned to this officer that have not ordered in sixty days, outlets that have never ordered at all, stalest first.

Why offline is a contract, not a feature

Field applications are routinely specified with a line reading “must work offline”, priced as a checkbox, and built as an online app with a cache attached. It fails the same way every time: the app appears to work in a basement market, the officer takes six orders, and at some point the data is gone, duplicated, or quietly older than what the office has already changed.

The reliable shape is local-first. Every action writes to the device’s own store and is treated as complete there; a background process sends it on. Each queued item carries an identifier generated on the device, so when a request reaches the server, is processed, and the response is lost on the way back, the retry is recognised as the same operation rather than creating a second order. That single property is what separates a queue that can be trusted from one that silently duplicates.

It also forces an honest decision about what cannot be done offline. Recording a visit, capturing a photograph and taking an order against a cached catalogue: yes. Confirming a live credit position or seeing an order another officer placed ten minutes ago: no, and the interface has to say so rather than showing stale data as though it were current.

The most effective defence against a replayed queue is not application logic but a constraint. One open shift per person per day, expressed as a unique index in the database, makes a double tap and an offline replay produce the same outcome as a single tap — and it survives every code path, including the import somebody writes next year. Rules enforced in a service are rules a second service can bypass.

One caution about ordering by delivery: an order should record which representative placed it, and that attribution should stay fixed. If the report joins through the outlet’s current representative instead, every reassignment silently rewrites last year’s performance.

How credit control actually fails

Not through generosity. Through sequence.

The credit position exists in accounts, the order is taken at a counter, and the two meet days later. By then the goods are allocated, the relationship pressure is on, and the only remaining option is a collections problem.

Showing the outlet’s balance and its ageing on the screen where the order is being entered changes the nature of the decision rather than the strictness of the rule. An overdue account can still be supplied — sometimes it should be — but it becomes a decision taken deliberately at the point of sale, by someone who can see the exposure, instead of a discovery made afterwards. Whether a credit limit blocks an order or merely flags it is then a policy the business sets, and either answer is defensible as long as the number is visible before the order exists.

Ageing needs stated bands rather than a single overdue figure, because thirty days late and ninety days late are different conversations. Nought to thirty, thirty-one to sixty, sixty-one to ninety and beyond ninety is the usual split, and the last band is the one that should be escalating on its own rather than waiting to be noticed.

The approval step deserves the same treatment. Whoever releases an order should be looking at the outlet’s own history on the same screen — how many orders, how long since the last one, the average value, the products usually taken and how the quantities have moved over the last three months — because that is the context that separates a distributor having a slow month from one quietly being lost. And when an order is declined, the reason should come from a short fixed list — credit limit exceeded, payment overdue, stock not in the depot, goods not received from the factory, transport delay — so that declines can be counted by cause instead of read one by one.

Collections belong in the same place. A receipt taken in the field has to post against the specific invoice it settles rather than land as a floating credit on the account, because a payment recorded beside the obligation instead of against it produces a ledger that disagrees with both parties.

Why a CRM or an accounting package does not fit

A CRM models a pipeline: a named opportunity progressing through stages to a close. Distribution is not a pipeline. It is the same outlets, called on repeatedly, forever, where the interesting questions are frequency, coverage, range sold and money collected rather than stage conversion.

An accounting package models the invoice and everything downstream of it perfectly, and knows nothing at all about the visit that produced the order, the beat that should have produced the visit, or the stock sitting at the distributor. It is the right system for the ledger and the wrong one for the field.

The join between them is where the value is: an order that carries its outlet, its route, its officer, the scheme applied and the credit position at the time it was taken, and that becomes a despatch and an invoice without being entered a second time.

When this is not the right fit

If you sell direct to consumers online, or through a handful of large accounts managed by key account managers, none of this applies. Beat plans, coverage and secondary sales are answers to the problem of many small outlets called on repeatedly, and a business with twenty customers does not have that problem.

It is also the wrong tool if what you actually need is warehouse management — putaway, picking strategies, bin locations, serial-level traceability at scale. Distribution field software touches stock, but a high-throughput warehouse is a different category and should be bought as one.

The threshold where it becomes worth doing is usually two things happening together: more field officers than one manager can hold in mind, and a channel where the manufacturer no longer knows what is actually selling through. Either alone can be run on discipline. Both together cannot.