Distributor Ordering and Field Force Software Case Study

The challenge

At Aries Agro, an agri-inputs manufacturer with a national distributor network, orders arrived as WhatsApp messages, photographs of handwritten sheets and phone calls, and were retyped into the accounting system by the internal sales desk. Product names were whatever the distributor called them, quantities were sometimes packs and sometimes units, and a schemed price agreed verbally in one conversation was invisible to anyone processing the order later. Field officers reported visits in a group chat, so there was no dependable record of which distributors had been seen in a given month, what was discussed or what was committed. Outstanding balances lived only in accounts, which meant new orders were regularly accepted from distributors already well past their credit terms and the problem surfaced weeks afterwards during collections.

The approach

We gave distributors a structured ordering channel that speaks in their own terms — their approved product list, their pack sizes, their agreed price list and their credit position shown at the point of ordering rather than discovered afterwards. Orders enter the system already validated, so retyping disappears and a scheme applies because it is attached to the distributor and the period rather than because someone remembered the conversation. The field application records visits against the distributor with location and time, captures the order taken or the reason none was, and works offline so a route through poor coverage is not a reporting gap. Outstandings and ageing were surfaced to both the field officer and the sales desk before an order is confirmed, with the rules on what happens over the limit made explicit rather than negotiated case by case.

The outcome

An order now arrives as data rather than as a message someone has to interpret, so the catalogue, pack size and price on the order are the agreed ones and the internal desk stops being a transcription service that also absorbs the errors. Because the credit position is shown while the order is being placed, an overdue account is a decision made deliberately at the point of sale rather than a discovery made later during collections. Field activity is a record instead of a chat history, so it can be asked questions of, which route was covered, which distributors have not been visited, which visits produced no order and why, and a conversation about coverage is settled by looking rather than by asserting.

WhatsApp wins in distribution because it is where the distributor already is, and any system that ignores that gets bypassed within a fortnight. The aim was not to take the channel away but to give the same convenience a structure underneath it.

What is the unit a distributor actually orders?

Not a product. A pack. The orderable item in a distribution business is a product in a specific pack size, with its own unit of measure and its own number of packs to a lot — and treating the product as the unit is what makes “twenty” an ambiguous quantity.

So the pack type is the record everything hangs off. It carries the product it belongs to, the pack size, the unit that size is expressed in, and how many packs make a lot. An order line is then a pack type and a lot count, and there is no interpretation step between what the distributor meant and what the desk processes.

That single modelling decision removes most of what the internal sales desk was doing. Retyping a WhatsApp message is not clerical work; it is a person resolving an ambiguity, and the errors it generates are the errors of resolving it differently each time.

Why the everyday order carries no price

This surprises people, so it is worth stating directly. A routine distributor order in this system records intent — which packs, how many lots, for which distributor, against which depot — and the money appears when the invoice does, from the accounting system that raises it.

That is the right division of labour. The manufacturer’s ERP is the authority on what a consignment was billed at, and duplicating pricing into an ordering app creates a second authority that will eventually disagree with the first. The ordering system’s job is to make the intent unambiguous and the approval traceable; the invoice remains the invoice.

Where price does live in the application is the advance-booking scheme, which is a different instrument: a defined window in which distributors commit to quantities at a published rate, with eligibility controlled per depot and the rate held per product and unit for that scheme. A booking scheme is a commercial event with a start, an end and a rate card. An everyday order is not.

How the system decides what each person is allowed to see

A distribution business has two overlapping notions of “mine”, and both had to be modelled.

The first is the depot. A depot administrator’s reach is the set of depots they are actually recorded as administering, and a request naming a depot is intersected with that set rather than trusted. The second is the reporting line. Field roles run from the representative up through group, state and regional levels, and a manager’s scope is the subtree beneath them, resolved by walking the reporting relationships.

One implementation detail is worth passing on, because getting it wrong fails silently. When a scope resolves to no depots at all, the filter cannot be an empty list — an empty list is a syntax error in the database, and the tempting fix of dropping the filter shows the user every depot instead of none. The correct behaviour is to emit a condition that is always false. A permission check that degrades to “show everything” when it has nothing to match on is worse than no permission check, because it looks like it is working.

What the field application actually captures, and how it survives no signal

A representative starts and ends a shift with location attached, and the application will not start one without GPS enabled. The interesting part is the order of operations on the server: the timestamp and the raw coordinates are written first, and turning those coordinates into a place name happens afterwards, without the write waiting on it. The shift time is the fact that must never be lost; the address is a convenience.

Rural routes lose coverage, so a shift action taken offline is queued on the device and replayed in order when the connection returns. Replay needs to be safe, and it is made safe in the database rather than in the client: a unique index permits only one open shift per person per calendar day, evaluated in Indian Standard Time rather than UTC, so a duplicate replay is rejected by the constraint and reported back as “shift already started” rather than creating a second record.

Business dates are not UTC, and a shift index built on UTC days would split an evening shift across two dates for half the country.

What we would do differently

The scoping filter was originally applied before ownership was checked — the request named a depot, the query filtered on it, and whether the person was entitled to that depot was established afterwards. It reads as an ordering detail and it is an access-control defect: a depot administrator could read another depot simply by asking for it.

The rule that came out of it is worth keeping. Resolve what someone is allowed to see first, then intersect the request with it. Never let a request parameter reach the query before the permission that governs it has been evaluated — the same discipline that makes showing the credit position at the point of ordering work in Sazinga Field, and one that matters everywhere in distribution where what you can see depends on who you report to.