Business Dashboard in Kenya: 12 Requirements Before You Build

A business dashboard should help a specific person make a specific decision with information they can trust. It is not simply a collection of attractive charts. When teams begin with colours and chart types before agreeing on the decisions, definitions and source data, the result often becomes another report that people export, question and rebuild in a spreadsheet.

For a Kenyan or East African organisation planning a management, sales, finance, operations, programme or service dashboard, the strongest brief describes the operating system around the numbers: who owns each metric, where it comes from, how quickly it changes, who may see it and what happens when something is wrong.

First decide what the dashboard must help someone do

Write one sentence for every intended user: “When this person opens the dashboard, they should be able to decide whether to ___ and then ___.” A sales manager may need to reassign neglected opportunities. An operations lead may need to investigate late orders. A finance lead may need to reconcile collections with invoices. Those are different products even when they share data.

Also decide what the dashboard will not do. A leadership overview does not need every transaction field. A frontline exception queue should not become a board report. Clear boundaries protect usability, performance and access control.

The 12 requirements to settle before development

1. A named audience and decision

List the roles that will use the dashboard, the decisions each role owns and the frequency of those decisions. “Management” is too broad. Name the branch manager, head of sales, finance controller, programme lead or service desk supervisor and describe the action they can take.

2. A metric dictionary with ownership

For every KPI, record its plain-language purpose, formula, data grain, time zone, inclusions, exclusions, comparison period, target and owner. Define ambiguous words such as active, completed, revenue, conversion, customer and overdue. If two teams calculate the same label differently, resolve that before it reaches the screen.

3. An authoritative source inventory

Identify the system of record for each field: accounting platform, CRM, ecommerce database, M-PESA reconciliation file, inventory system, support tool or approved spreadsheet. Record how the data is accessed, who owns that access and whether the source has stable identifiers. A dashboard cannot create consistency that the source process does not have.

If customer work is fragmented across spreadsheets and follow-up channels, the CRM system guide explains the workflow decisions that should come first. For stock and fulfilment reporting, use the inventory management system guide to map movement and reconciliation rules.

4. A data-quality baseline and reconciliation rule

Measure missing identifiers, duplicates, invalid dates, inconsistent categories and records that fail to join. Agree which trusted total the dashboard must reconcile to and within what tolerance. Document known differences, such as cancellations recorded after a daily cut-off, so users can distinguish expected timing from a defect.

5. The model, grain and history

Decide whether one row represents an order, order line, payment, customer, visit, case, task or daily summary. Mixing grains can silently double-count totals. Separate descriptive entities from measurable events, preserve stable keys and specify whether changed values should update history or only future reporting.

6. Refresh frequency and freshness status

“Real time” is not a useful default. Define the business need: every few minutes, hourly, daily or after a controlled close. Include source cut-off times, time zone, late-arriving data, retry behaviour and an obvious “last updated” status. If a refresh fails, the dashboard should say that the data is stale instead of displaying old numbers as though they are current.

7. Drill-down and traceability

Users need a path from a summary to the branch, product, channel, owner or transaction behind it. Define permitted filters and the record-level fields needed to investigate a number. Where practical, retain a source reference so an authorised user can verify the record without hunting through several systems.

8. Exceptions, alerts and the next action

A useful operational dashboard highlights what needs attention: a threshold breach, unassigned lead, stock variance, failed integration, overdue approval or unreconciled payment. Define who receives an alert, how often, through which channel and when it escalates. Avoid notifications that repeat without ownership or a clear next action.

When the goal is to reduce manual routing as well as improve visibility, scope the dashboard with workflow automation rather than treating the two as separate projects.

9. Role-based access and auditability

Map roles to the data they are allowed to see and the actions they may perform. A branch user may see only one location while leadership sees consolidated results. Sensitive customer, employee, health or financial fields may need stronger restrictions or removal from the dashboard entirely. Record permission changes, important exports and administrative actions where risk warrants it.

10. Accessible desktop and mobile use

Choose charts because they answer the question, not because they look sophisticated. Provide readable labels, sufficient contrast, keyboard-friendly controls and a table or textual equivalent where needed. Do not rely on colour alone to indicate status. Decide which views must work on a phone and which analysis genuinely requires a larger screen.

11. Performance, export and integration boundaries

State acceptable load time, expected data volume, peak users and essential exports. Define whether the dashboard is embedded in an existing system, links back to operational records or becomes part of a broader custom software product. Exports should follow access rules and carry enough context—filters, period and freshness—to be understood outside the screen.

12. Ownership, monitoring and change control

Name the business owner, data owner and technical owner. Define monitoring for refresh failures, broken integrations, unusual volume and slow queries. Set a process for changing a formula, source or target, including approval, testing and communication. A dashboard is an operational system, so include backups, dependency updates and support in its lifecycle.

A practical acceptance test

Before launch, ask representative users to complete real tasks without coaching. A useful acceptance checklist includes:

• Each headline KPI matches an agreed trusted calculation for a sample period.
• Filters, totals and drill-downs preserve the correct data grain.
• Freshness, time zone and failed-refresh states are visible.
• Each role sees only the permitted locations, teams and fields.
• Mobile layouts preserve the priority decisions and actions.
• Charts remain understandable without colour and have clear labels.
• Exports reflect the selected filters and do not expose restricted data.
• An owner can explain what happens when a source, formula or integration changes.

Spreadsheet, BI tool or custom dashboard?

The right choice depends on verified scope, not company size alone. A small team can need a carefully controlled operational dashboard, while a larger organisation may solve a narrow question with a governed spreadsheet. Use the custom software cost guide to identify the work that typically shapes a development estimate, without treating any generic figure as a quote.

Frequently asked questions