Every Monday morning in logistics operations across Nairobi, versions of the same ritual play out: team members open multiple systems, download reports, paste data into a master spreadsheet, run calculations by hand, check for errors, and compile a package for stakeholders. The work is not cognitively demanding. It is data assembly — performed by people trained and paid for something more analytically valuable. And across Kenya's transport and logistics sector, it consumes thousands of cumulative person-hours each week.
Kenya's logistics industry is, by African standards, digitally advanced. According to The Africa Logistics (2025), over 60% of freight operators in Nairobi and Mombasa now use mobile-based cargo tracking platforms, and digital freight matching applications have cut empty return trips — a significant cost driver in third-party logistics — by as much as 25%. The sector is not resistant to technology adoption. But internal reporting infrastructure has not kept pace with customer-facing digitalisation. Systems talk to clients and to regulators; they do not consistently talk to each other.
The engagement described in this case study illustrates a pattern we encounter repeatedly in Nairobi operations teams: a capable, well-run company with a specific, measurable problem that had resisted commercial off-the-shelf solutions, resolved through custom pipeline automation in under twelve weeks.
The problem: forty-five hours a month of data assembly
Three members of the operations team at a mid-sized Nairobi third-party logistics company spent every Monday morning doing the same thing. They opened five different systems, downloaded reports, pasted data into a master Excel workbook, ran calculations by hand, checked for errors, and emailed the consolidated report to twelve stakeholders by noon. Each person spent three to four hours on the task. Across the team, that was ten to twelve person-hours every single week — over forty-five hours per month — on work that produced no new analytical insight. It moved data from one place to another.
By the time they approached Hekima Labs, the team had already attempted a commercial solution. The off-the-shelf tool did not integrate cleanly with their transport management system, required manual exports at several steps, and broke whenever a source system updated its export format. They had spent money, burned several weeks of goodwill, and returned to the manual process. This experience is not unusual. Research on enterprise technology implementation consistently finds that commercial automation tools perform most reliably in standardised, horizontal use cases — and that the specific combination of legacy systems, localised data formats, and uneven API maturity common in Nairobi businesses frequently falls outside what general-purpose tools handle well.
Mapping the problem before building anything
We spent the first two weeks in discovery, not building. We mapped every data source: the transport management system, the fuel tracking platform, the customer billing portal, the driver payroll system, and a government customs interface. We documented which fields were needed, in what format, at what cadence, and who received them downstream.
This diagnostic phase is where most automation projects get the framing wrong. The visible symptom was 'Monday report takes too long.' The underlying structural problem was that data lived in five isolated systems with no programmatic bridge between them, and reconciliation was performed by a human every week as an act of institutional routine. Any intervention that did not address the data isolation would exchange one manual step for another. The failed commercial tool had treated the symptom without resolving the structure.
What the data sources looked like
- Transport management system: trip records, vehicle assignments, route times — accessible via REST API
- Fuel tracking platform: litres consumed, cost per trip, anomaly flags — CSV export only, no API
- Customer billing portal: invoices raised, payment status, outstanding balances — REST API with token authentication
- Driver payroll system: hours logged, overtime, deductions — legacy system with Excel export only
- Government customs interface: clearance status and duty records — portal requiring browser automation
The solution: a pipeline that runs while the team sleeps
We built a Python-based ETL (extract, transform, load) pipeline that runs automatically every Sunday at 10pm. It connects to each source system via its preferred integration method: API calls where available, scheduled file pickup where not, and a headless browser for the government customs portal.
The pipeline normalises field names across all five systems, converts currencies to a consistent KES base, applies the business logic previously encoded in the manual spreadsheet, flags anomalies — unusual fuel consumption, unmatched trip records, overdue invoices above a defined threshold — and compiles the final report into a Google Sheet formatted identically to the one the team had been assembling by hand.
At 6am Monday, the report is complete. An automated WhatsApp Business notification alerts the operations manager. The twelve stakeholders receive an email with a direct link to the live Google Sheet, which updates in real time when corrections are made during the quality check — eliminating the version-control confusion that had been a secondary, unspoken problem before the automation.
Technical components used
- Python 3.12 for all ETL logic — lightweight and maintainable without specialist ML knowledge
- Google Sheets API for the output report — stakeholders already knew the format
- WhatsApp Business API for automated delivery notification
- Playwright (headless browser automation) for the government customs portal
- Google Cloud Run for scheduled execution — no persistent server to manage or patch
- Slack webhook for internal pipeline health alerts
Results: month one through three
Month one was the calibration phase — and, in our experience, the most instructive part of any automation project. The pipeline ran reliably, but the team identified eight edge cases absent from the sample data used during build: a new vehicle type added to the fleet mid-month, a non-standard invoice format introduced by one customer, and a date-format inconsistency in the payroll export caused by a software update on the legacy system. Each was patched within 24 hours.
This is normal, anticipated behaviour in any production automation. Global research on enterprise process automation finds that between 15% and 30% of production edge cases emerge only after go-live, regardless of the depth of pre-launch testing. The critical design decision is comprehensive error logging — systems that fail loudly are dramatically cheaper to maintain than systems that fail silently, because failures are visible, attributable, and resolvable before they reach stakeholders.
By month three, results had stabilised:
- Weekly reporting time: from 10–12 person-hours to under 2 hours (quality check only)
- Monthly time cost: from approximately 45 person-hours to under 4
- Report errors caught in QA: down 94% in month one, near zero by month three
- Report delivery time: from noon Monday to 6am Monday — six hours earlier
- Pipeline failures in three months of production operation: zero
No staff were made redundant. The three operations team members shifted their recovered capacity to route optimisation analysis, customer SLA monitoring, and driver performance management — work that had previously gone unaddressed because the team was occupied with data assembly.
What this means for Nairobi operations teams
The logistics company in this study is not exceptional. The pattern recurs across Kenya's transport sector. The Northern Corridor — the principal freight route connecting Mombasa to landlocked East African markets — is well-documented in logistics research as suffering from operational inefficiency that is partly attributable to data fragmentation between carriers, customs authorities, and logistics intermediaries. Digital integration at the individual firm level compounds into corridor-level throughput and regional competitiveness.
Global research on workflow automation (Kissflow, 2026; Quixy, 2025) finds that 60% of organisations achieve positive ROI from process automation within twelve months of implementation, with error reduction rates of 40–75% and task completion time reductions of up to 70% in well-scoped implementations. These figures are consistent with our East African engagements, with one important caveat: outcomes are strongly correlated with the quality of problem selection at the outset. The highest-return projects are almost always the ones that appear, on the surface, too simple to bother with.
The economics in a Nairobi context are straightforward. A project of this scope typically costs between KES 400,000 and KES 800,000 depending on the number of source systems and the complexity of business logic required. At 45 person-hours per month recovered, the payback period at typical mid-level Nairobi operations salaries is under six months — before accounting for error reduction and the analytical value of work that now gets done for the first time.
Signs that you have a similar problem
- A recurring report that requires more than four person-hours per week to produce
- Operational data that lives in more than two systems with no programmatic connection between them
- Manual copy-paste steps at one or more points in your data workflow
- Stakeholders who regularly receive reports late or chase the operations team for updates
- Staff who describe part of their role as "just pulling the data together"
If any of the above describes your team, the work described here — the data source inventory, the integration map, the baseline metric — is where a productive conversation begins. Our discovery process starts with exactly this kind of mapping exercise, with no commitment to implementation required.