A distributor in Nairobi sits through two demonstrations in the same week. The first vendor calls the product sales force automation. The second calls it a CRM. Both show a mobile app and a dashboard of coloured tiles, and both use the words visibility, productivity and pipeline. The buyer leaves less certain than when they arrived.
The confusion is reasonable. The categories have grown into each other at the edges: a CRM has picked up a mobile check-in, an SFA a lead list. From the outside they look like one thing sold under two names.
Underneath, they answer different questions, and the difference matters most in the kind of business Kenya is full of — one selling through repeated coverage of small outlets while also negotiating a handful of larger accounts. This is not an argument for either. It is a way of working out which question your business is asking, including the possibility that the answer is both, or neither yet.
What Sales Force Automation Is Actually For
Sales force automation organises a repeating day in the field. The unit of work is the visit. A rep has a route, the route has a list of outlets, the outlets have a call frequency, and the same sequence runs again next week with different quantities.
It answers a narrow set of questions well: did the call happen, at the right outlet, at roughly the right time, and what was recorded while the rep was standing there.
The workflow is field-first in a specific sense. It is built to be completed on a phone held in one hand at a duka counter, while the shopkeeper serves somebody else, in a few minutes. That constraint shapes everything from screen depth to sync behaviour.
- A beat or route plan that says which outlets are due, and when.
- Check-in that ties the visit to a place and a time rather than a claim.
- Order capture against a shared catalogue with KES pricing, schemes and a credit position.
- Shelf and stock capture, plus collections carrying M-Pesa till and paybill references against the correct invoice.
What a CRM Is Actually For
A CRM organises a relationship over time. The unit of work is the account and the opportunity attached to it. Nothing repeats on a cadence. A deal moves forward, stalls, changes hands, returns six weeks later with a different decision maker, and eventually closes or does not.
Its questions are different in kind: who are we speaking to inside this organisation, what stage is the conversation at, what did we quote, what is the next action and who owns it, and what does the weighted pipeline look like this quarter.
A CRM assumes a longer memory and a slower clock. The history of an account is the working asset. It is usually built browser-first: the work happens at a desk and in meetings rather than at a counter.
- Leads, their source, and the qualification that makes them worth pursuing.
- Multiple contacts at one account, with their roles in the decision.
- Stages, quotations and revisions, with an honest definition of what must be true to move forward.
- A full activity trail held against the account, through to renewal.
Where the Two Genuinely Overlap
The overlap is real, and pretending otherwise misleads buyers in both directions. Both systems hold a customer master, capture activity, roll that activity up for somebody who was not there, and ship a mobile application.
Vendors have extended into each other's ground because customers asked them to. It is now common to find a CRM with a geo-tagged visit log, and an SFA with a lead register and a simple pipeline view. Those features usually work. They are just not the centre of gravity of the product around them.
The overlap becomes expensive in exactly one place: the customer master. If a supermarket branch exists as an outlet in one system and an account in another, with different codes and owners, the two versions drift apart within a quarter and every reported number afterwards becomes arguable. That single decision — one master or two — usually matters more than any feature comparison you will run.
The Field-First Mobile Test
The practical test has nothing to do with feature lists: look at how your commercial team's day is shaped.
If the day is route-shaped — a known list of outlets, a known frequency, an order or activity expected at most calls, with quantity as the main variable — that is an SFA problem. If it is opportunity-shaped — few conversations, no cadence, weeks between touches, and survival of the deal as the main variable — that is a CRM problem.
Then apply the second test, specific to operating in Kenya: ask what happens when there is no signal. A rep working a route through Machakos or the country beyond Eldoret will lose coverage during the day, and electricity supply is not something field software should quietly assume either. Kenya saw a nationwide outage in 2026, and power interruption remains a normal operating consideration.
Software that needs a live connection to record a visit does not fail evenly. It fails hardest on the thinnest, most remote routes — precisely the ones head office understands least. Offline-first capture is standard in serious SFA and unusual in CRM, because the CRM user normally sits somewhere with a connection. Neither is wrong; they were built for different rooms.
The Reporting Hierarchy Question
Ask each vendor how their system rolls numbers upwards. The answer separates the categories more cleanly than any comparison table.
An SFA hierarchy is structural and geographic. A rep owns routes, routes sit inside a territory, territories inside an area, areas inside a region, regions inside the national number. A supervisor sees everything under their node. Coverage, productivity and compliance are measured against that tree, and reassigning a route reassigns its history.
A CRM hierarchy is ownership-based. An opportunity has an owner, a manager sees their team's opportunities, and the roll-up follows people rather than places. Two salespeople can work the same city without conflict because they are separated by account, not geography.
This bites in businesses with a cross-border motion. A Kenyan distributor supplying Uganda, Tanzania, Rwanda or South Sudan usually runs the export desk as a relationship business — few accounts, long lead times, terms negotiated annually. The domestic route teams working Nairobi, Nakuru and the Northern Corridor towns are a different shape entirely. Draw your hierarchy on paper before buying anything. If the room does not agree with it, no system will settle that argument for you.
Approval Routing Tells You More Than the Feature List
Every organisation has decisions a salesperson cannot take alone. Which ones they are, and how fast they must be resolved, tells you a great deal about what you are buying.
In a distribution business the approvals are small, frequent and urgent. A rep needs a discount beyond their band, a KSh credit limit stretched for an outlet that pays reliably but slowly, a return authorised, a damaged case written off, a new duka added to the master. The answer is measured in minutes, because the rep is still at the counter and the next call is waiting. SFA routing is therefore short and hierarchical: up one level, to a phone, and back.
In a relationship business the approvals are larger, rarer and slower. A quotation needs sign-off, terms need commercial review, a long payment window needs finance to agree. Days are acceptable, and people outside the sales line are often involved.
So the internal question is not "does it support approvals" — almost everything does. It is how long each decision can wait without costing an order. Answer that for your five commonest approvals and the shape of the system becomes obvious.
A Morning in Kisumu
Consider a distributor in Kisumu serving the lake region. On an ordinary Tuesday two of its people do work that looks similar and is structurally nothing alike.
The first is a rep running a route that starts near the open-air market, takes in a run of dukas and kiosks, calls at an agrovet on the road out towards the smallholder farms, and finishes at a mini-mart. At each stop, the same short sequence: check in, read the shelf, note what has run out, take the order against current KES pricing, capture the M-Pesa reference where a payment is made, and raise an invoice valid under eTIMS, since KRA now validates declared expenses against that data. Nothing is negotiated. Everything repeats next week.
The second is the key accounts person at the same distributor, who has no route at all. Her morning is a meeting about a supermarket chain's listing for a new pack size, a follow-up call to a wholesaler wanting annual terms revised, and an afternoon writing a proposal for an institutional supply contract running since March. Three touches, three accounts, no cadence, no shelf, no counter.
Same company, same commercial director, same monthly number — two entirely different shapes of day. A system built for one will be quietly resented by whoever is doing the other.
The Decision a Distribution-Led Business Faces
Most Kenyan businesses selling FMCG, agricultural inputs, pharmaceuticals, building materials or airtime are distribution-led. Volume comes from repeated coverage of dukas, kiosks, agrovets, wholesalers, mini-marts and petrol-station forecourts, with modern trade and institutional accounts as a smaller, more visible layer on top.
For that business, SFA is the load-bearing system. It governs where most of the revenue physically comes from, most of the people, most of the invoices and nearly all of the operational risk. A CRM, if there is one, covers a minority of turnover.
The trap is that the minority is the layer leadership talks about most. Supermarket listings and institutional contracts are discussed in board meetings; the duka route is not. It is easy to buy for the motion most talked about rather than the one carrying the volume, then wonder why the numbers did not move.
The sequencing rule is unglamorous. Fix the motion carrying the volume first — unless the pipeline motion is genuinely where growth is coming from, in which case fix that first and be equally deliberate. What fails is buying both at once, badly, because a vendor offered a bundle.
When You Need Both, and When You Need Neither Yet
Some businesses genuinely need both, and the pattern is recognisable: a real route operation alongside a real key accounts, export or institutional desk. Running one motion on the other's system produces a workaround culture within weeks — reps logging thin visits to close a task, or key accounts staff keeping the real pipeline in a spreadsheet because the system cannot hold a nine-month negotiation.
Where both are needed, the requirement is not two products. It is one customer master, one product and price master, and one reporting spine, with two workflows on top. That is a data architecture question, and it deserves settling before anyone signs anything.
Some businesses need neither yet. A few people covering one town from one depot, where everyone can see everyone, may get more from settling their process than from licensing software. If your product list exists in three files that disagree, if nobody can say what a route should look like, or if credit terms are set case by case with no rule, software will record that confusion faithfully, faster and at greater cost. That is not an argument for waiting indefinitely — it is an argument for knowing what you are automating.
Where These Decisions Go Wrong
The failure modes are consistent, and most are decided before a single user logs in.
- Buying the category name instead of the workflow. "We need a CRM" is often a borrowed phrase, not a diagnosis. Describe the day you want your team to have, then find the system that produces it.
- Judging by the demonstration rather than the daily use. Demonstrations run on strong connectivity with clean data. Ask to see the same task on a mid-range Android handset with the connection switched off.
- Ending up with two customer masters. Almost always accidental, almost always found at the first reconciliation, and expensive to unpick afterwards.
- Forcing a route onto a pipeline model, or the reverse. A dozen duka calls logged as opportunities produce a pipeline nobody can read; a months-long supermarket listing squeezed into a call report loses every detail worth keeping.
- Designing approvals against a chart nobody follows. Build what happens, not what is drawn.
- Leaving eTIMS and M-Pesa reconciliation until after go-live. Invoice validity and payment matching are not reporting refinements in Kenya; they decide whether the system's output is usable.
- Measuring adoption by logins. Logins tell you people opened the app. Coverage, order accuracy and collection reconciliation tell you whether anything changed.
How 1Channel Supports This
1Channel builds both — sales force automation and field-focused CRM capability, alongside distributor management — so we are not a neutral party here, and it would be dishonest to pretend otherwise. What we can be straight about is where each is the right answer, including when the answer is neither.
Where the work is route-shaped, the platform provides an offline-first Android application built for entry-level handsets: beat and route planning, verified check-in, order capture against a shared catalogue and KES pricing, shelf and stock capture at the outlet, collection records carrying M-Pesa references, and attendance and expenses. Data syncs when coverage returns, so a call recorded without signal is not a call lost.
Where the work is relationship-shaped, the same platform holds leads, accounts with multiple contacts, opportunity stages, quotations and a full activity history, so a negotiation running for months keeps its detail. Both motions read from one customer master and one product and price master — the part that usually decides whether a two-motion setup survives its first year.
Around both sit a configurable sales hierarchy, approval routing that can match how decisions are really made rather than how they are drawn, role-based access and audit trails aligned with Data Protection Act, 2019 obligations, and eTIMS-aligned invoicing through distributor management. These are obligations the product is built to support, not accreditations it holds. And if your own assessment concludes that your routes are undefined or your price master contradicts itself, the right first step is not a purchase.
Key Takeaways
The choice between sales force automation and CRM is not a contest between products. It is a question about the shape of your commercial day, and it usually answers itself once asked precisely.
- The shape of the day decides it. Route-shaped work with repeated calls at fixed outlets is an SFA problem; opportunity-shaped work with long, negotiated cycles is a CRM problem.
- One customer master, always. If an outlet exists twice under two codes, every number you report afterwards is arguable and the reconciliation never ends.
- Approval latency is the real requirement. A credit decision needed in minutes at a duka counter and a contract sign-off that can take days are different systems, not different settings.
- Test offline before you test features. Kenyan routes lose signal and power interruption is normal; a system that cannot record a visit without a connection fails worst on the routes you understand least.
- Both and neither are legitimate answers. Businesses with real route and key-accounts motions need both on one data spine; those without defined routes or a clean price master need process first.
Work out which question your business is asking before comparing anyone's feature list. A team that knows whether it runs routes or relationships — or honestly, both — will make a good decision from a mediocre shortlist. A team that has not settled that will make a poor one from an excellent shortlist.
