KENYA · GUIDE 0597 · EDITION 4.2
Customer database setup in Kenya: Risks and Launch Plan
Set the conditions for a safe commercial test
- Unlawful reuse
- duplicate records
- excess access
A database fails when staff create fresh records for every interaction or collect sensitive details nobody needs, making accurate customer history harder to maintain.
A risk list is useful only when it changes a decision. For each risk, write the observable warning, who checks it and the response before the next commitment. Do not treat a reserve of money as permission to continue unsafe or unauthorized work.
Use a small, measurable pilot
Use fictional records to test permissions and search before import.
The pilot scope is: Create the customer database around actual service needs, defining identifiers, permitted fields, consent information where relevant, user roles, and duplicate resolution responsibility.
| Gate | Evidence before continuing |
|---|---|
| Scope agreed | Create the customer database around actual service needs, defining identifiers, permitted fields, consent information where relevant, user roles, and duplicate resolution responsibility. |
| Output acceptable | Ask staff to find a customer, record an interaction, update contact details, and handle a duplicate without exposing records unrelated to their duties. |
| Costs recorded | Include process discovery, historical-data cleanup, field setup, access controls, import checks, staff training, and future maintenance for changing contact information and ownership. |
| Buyer response recorded | Record field purposes, import mappings, duplicate decisions, access tests, staff retrieval tasks, correction requests, and agreed ownership of future data quality work. |
Stage the launch around prerequisites
First confirm the buyer specification and activity requirements. Then compare suppliers, establish suitable facilities and prepare the operating record. Run the bounded trial when those prerequisites are in place. Review actual costs, quality failures and cash collected before increasing the commitment.
This sequence is not a promise that the complete business cycle fits into 30 days. Growing periods, qualifications, approvals, seasonal access and customer buying cycles can require longer. Revise the schedule when a prerequisite changes rather than skipping it to meet a launch date.
Choose continue, revise, pause or stop
Continue only when the scoped result is accepted and direct costs and payment timing are workable. Revise one part of the offer if the problem is identifiable and affordable to test again. Pause when required information, permission, skills or resources are missing. Stop the affected work when safety, consent or lawful authority is uncertain.
Keep a maximum test loss and unpaid-balance limit suited to your actual funds. A successful single delivery is useful evidence, but it does not establish year-round demand or justify committing every available resource.
Tie launch milestones to observable checks
| Risk signal | Evidence to inspect | Response to test |
|---|---|---|
| Viewer can edit | Check inherited/direct permissions. | Correct roles and retest denied action. |
| Shared email causes merge | Review person/organisation keys. | Restore separate contacts pending owner decision. |
| Export includes restricted notes | Inspect export field selection. | Limit authorised subset and correct permission design. |
Outstanding go / hold conditions
- Actual data purpose, access platform and retention policy unverified.
- No contacts imported or contacted.
Assign an owner, evidence reference and review date to each unresolved condition. Do not give every milestone a fixed calendar date when it depends on a crop, production, approval or competence cycle. Run only a suitable limited trial, reconcile accepted output and actual cash, and record whether the evidence supports holding, revising, proceeding within the limit or stopping.