Fleet and Dispatch Management Software in Kenya: What SMEs Actually Need

What is fleet and dispatch management software?

Fleet and dispatch management software is a shared operations system that turns customer requests into assigned jobs, tracks each job through delivery or service completion, records proof, alerts staff to exceptions and connects the work to payment and reporting. GPS location can be one input, but it is not the whole system. A dot on a map tells you where a vehicle is; it does not tell you which customer is waiting, whether the job is profitable, whether proof of delivery exists or whether M-Pesa payment was matched.

For Kenyan couriers, movers, water bowser operators, LPG delivery firms, cleaning companies and field-service contractors, the useful product is a dispatch command center built around actual work. Drivers or technicians can receive and update jobs through a simple mobile interface or approved WhatsApp workflow, while dispatch sees the full board.

Which problems should an SME solve first?

Begin with visibility and ownership. Every active job needs a reference, customer, location, promised time, assigned person, status, value and next action. Most operational chaos comes from one of those fields living in someone's head or disappearing in a WhatsApp group. Once the core job record is reliable, add customer notifications, proof, payments and analytics.

• Phone or WhatsApp orders that never reach a dispatch board.
• Duplicate assignments and unclear ownership.
• Customers repeatedly calling for status.
• Late jobs noticed only after a complaint.
• Photos and signatures stored on personal phones.
• Cash or M-Pesa receipts that finance cannot match to jobs.
• Managers compiling daily reports manually.

A focused build should remove these points before adding route optimisation, predictive maintenance or other advanced features.

What features do Kenyan fleets actually need?

The essential modules are order capture, job board, assignment, status updates, exception alerts, proof of delivery or service, customer communication, payment status and daily reporting. Multi-depot operators may need zones, branch capacity and transfer workflows. Recurring field-service firms need schedules, checklists and contract history. Movers may need survey appointments, inventory lists and crew planning. The product should reflect the business, not force every operator into a courier template.

Role-based views keep it usable. A driver needs today's assigned jobs and a fast update action. Dispatch needs all work in motion and exceptions. Finance needs completed-but-unpaid jobs. The owner needs revenue, capacity, delays and customer issues. When everyone sees the same database through the right lens, calls and arguments decrease.

Can drivers use WhatsApp instead of another app?

In some workflows, yes. An approved WhatsApp integration can send assignment details, capture a driver's status reply, receive a location or proof photo and update the central job. This reduces training because the driver already knows the channel. It is especially useful for a focused prototype or a workforce that does not need complex scanning and offline features.

WhatsApp is not automatically the right answer for every fleet. High-volume scanning, offline operation, continuous GPS, barcode workflows or strict device controls may justify a dedicated mobile app. The decision should follow the job, connectivity and risk. A good vendor explains the trade-off rather than forcing the most fashionable interface. Whatever the channel, updates must create structured events in the central system, not remain as chat history.

How should proof of delivery work?

Proof should be tied to the specific job and timestamp. Depending on the service, it may include recipient name, signature, photo, delivery note, GPS point, checklist or customer confirmation. Dispatch and customer service should find it from the job record in seconds. Sensitive photos and signatures need access controls and retention rules; they should not sit indefinitely in a public group or personal gallery.

The system should prevent false completion where appropriate. For example, a job may require both a delivery photo and recipient name before “delivered” becomes available. Exceptions need a separate status with a reason—customer unavailable, wrong address, vehicle issue, payment pending—so management learns why failures happen instead of merely seeing a lower completion number.

How do alerts reduce customer calls?

Customers call when the operation knows something but does not communicate it. Trigger updates at meaningful stages: job accepted, assigned, on route, delayed, completed and proof available. Do not send a message for every internal movement. For delays, notify the customer with an honest new expectation and alert dispatch to intervene. The aim is proactive clarity, not notification noise.

An exception dashboard is more valuable than a wall of green jobs. Dispatch should see late pickups, stalled statuses, repeated failed attempts, unassigned work and completed jobs with missing proof. The system taps the team's shoulder before the customer does. That is how service quality improves without hiring a larger call centre.

How does M-Pesa fit into dispatch operations?

A job can carry an expected amount and payment state: not requested, pending, received, matched, refunded or exception. Depending on the business's payment setup, transaction information may arrive through an approved API, payment provider, bank feed, statement import or controlled manual confirmation. The system matches the transaction reference and amount to the job, then sends unmatched items to finance.

Do not promise universal automatic access to M-Pesa data; capabilities differ by till, paybill, bank and provider arrangement. The integration must be designed around the account the business actually uses. Even where full automation is unavailable, a structured reconciliation queue is better than screenshots in a group. Finance gains a clear list of what is paid, what is unmatched and what requires human review.

What does fleet software cost in Kenya?

Costs vary by number of users and vehicles, integrations, customer portal, GPS hardware, mobile app requirements and support. Subscription fleet trackers may be appropriate when location is the main need. Custom software makes sense when dispatch, customer communication, proof, invoicing and M-Pesa need to follow the operator's own workflow.

Kavenacc's OpsCommand Core is $8,497 one time for a custom unified operations dashboard with up to three data integrations. The Premium package starts at $14,997 where a dedicated web/mobile component or more integrations are required. A narrower AI Agent Launchpad starts at $4,997. Payments can be made through M-Pesa, card, bank transfer or installments. The free seven-day prototype allows management and dispatch to test the flow before committing.

What is a practical 30-day implementation plan?

1. Week 1: map request-to-payment, statuses, exception reasons and user roles; prototype one live board with sample jobs.
2. Week 2: test with dispatch and two or three field users; simplify every update that takes too long.
3. Week 3: connect the first intake channel, proof workflow and payment source; train supervisors.
4. Week 4: launch one route, depot or service line; review exceptions daily before wider rollout.

Import only active jobs and essential reference data first. Historical cleanup can follow. Keep a fallback process during the controlled launch and define who can change statuses, reassign work or edit payment fields. The fastest implementation is not the one with the most features; it is the one the field team actually updates.

Which metrics should owners monitor?

Track jobs created, assignment delay, on-time pickup and completion, average cycle time, exception rate by reason, first-attempt success, proof completeness, customer status contacts, revenue per job or route, completed-unpaid work and unmatched payments. For field service, add technician utilisation and repeat visits. Compare the same definitions every week.

GPS distance and app logins can support analysis, but they do not prove the system improved the business. The best metrics connect operations to customer experience and cash. If late jobs fall but margins collapse, routing may be inefficient. If proof is complete but customers still call, notifications may be unclear. A command center should expose these trade-offs rather than celebrate activity.

How do you choose between SaaS and a custom build?

Choose standard SaaS when your process is standard, the integrations exist and staff can adopt the product without workarounds. Choose custom when the competitive advantage is your workflow, several disconnected systems must be unified, local payment and WhatsApp behaviour matters, or per-seat subscriptions become expensive. A hybrid is common: keep a proven GPS provider and build an owned operations layer around it.

Before selecting a vendor, ask for a prototype using your statuses and one real service scenario. Confirm code ownership, export, access controls, uptime responsibility, support, integrations and the exact boundary between software and hardware. Avoid any proposal that promises route optimisation, GPS and M-Pesa without first inspecting your accounts and fleet environment. Specific discovery is a sign of competence.

Dispatch software requirements checklist

Write requirements as operational outcomes. Instead of “we need GPS,” write “dispatch must see which available vehicle can reach the pickup within the promised window.” Instead of “we need reports,” write “finance needs a daily list of completed jobs without matched payment.” Outcome language allows the developer to choose the simplest reliable mechanism and prevents a feature list that looks impressive but leaves the original problem untouched.

Test the prototype under pressure. Create two urgent jobs, reassign one, mark a customer unavailable, upload the wrong proof, lose connectivity and submit a duplicate payment reference. Check whether dispatch can recover without calling the developer. Field software succeeds when exceptions are easy; the normal happy path is rarely the hard part.

Plan device and support realities too. Decide whether phones are company-owned, which data bundles are available, who resets access, how departed workers are removed and what happens when the platform is unavailable. A printed or exported fallback manifest can keep essential work moving during an outage. Resilience is part of the product, not an afterthought added when the first incident happens.

Frequently asked questions