KENYA · GUIDE 0597 · EDITION 4.2
Customer database setup in Kenya: Operations and Quality Checks
Deliver the agreed result consistently
Create the customer database around actual service needs, defining identifiers, permitted fields, consent information where relevant, user roles, and duplicate resolution responsibility.
The operating sequence for this offer is:
- Define the customer-data purpose, authorized fields, access roles and retention, then demonstrate search and permissions using fictional records before any import.
- Validate supplied records, restrict unnecessary fields and test role access, duplicate handling, export and deletion according to the approved process.
- Reconcile imported counts and exceptions with the owner, supply backup and correction instructions and document responsibility for lawful ongoing use.
Put acceptance into the job record
Roles limit access appropriately and record counts reconcile.
Ask staff to find a customer, record an interaction, update contact details, and handle a duplicate without exposing records unrelated to their duties.
Inspect at the point where a correction is still possible, then again at handover. Record rejected or incomplete output separately from accepted output. A completed task is not automatically an accepted task, and an invoice does not establish that the customer received the right result.
Measure real capacity
Time preparation, the main operation, transport, cleaning, approvals and correction as applicable. The slowest stage determines how much you can promise. Where two orders need the same person, space or equipment at the same time, resolve the conflict before confirming both deadlines. An additional enquiry should not erase a commitment already made.
| Operating checkpoint | Evidence for this business |
|---|---|
| Before starting | Create the customer database around actual service needs, defining identifiers, permitted fields, consent information where relevant, user roles, and duplicate resolution responsibility. |
| During delivery | Validate supplied records, restrict unnecessary fields and test role access, duplicate handling, export and deletion according to the approved process. |
| At acceptance | Ask staff to find a customer, record an interaction, update contact details, and handle a duplicate without exposing records unrelated to their duties. |
| At the pilot review | Record field purposes, import mappings, duplicate decisions, access tests, staff retrieval tasks, correction requests, and agreed ownership of future data quality work. |
Keep a correction and escalation rule
When inputs, access, specifications or customer instructions change, pause the affected work and confirm the effect on time and cost. Do not quietly lower the acceptance standard to avoid a delayed delivery. Keep rework caused by your error distinct from a customer-requested change of scope and agree the remedy clearly.
A database fails when staff create fresh records for every interaction or collect sensitive details nobody needs, making accurate customer history harder to maintain.
Retain the minimum records needed to investigate a complaint without disclosing unrelated personal information. Use measured delivery and actual acceptance as the basis for expanding capacity, rather than the maximum theoretical output of a tool or production line.
Operating control points for this exact offer
| Sequence | Work method | Release checkpoint |
|---|---|---|
| 1 | Ask owner which business task each field supports. | Do not collect identity numbers or private family details for an ordinary enquiry. |
| 2 | Preserve originals and IDs; distinguish person from organisation. | Shared reception emails do not prove duplicate people. |
| 3 | Create owner/editor/viewer permissions and test with fictional records. | Public links expose no contact data. |
| 4 | Require source/owner for edits and keep duplicate decisions traceable. | No silent merge deletes conflicting facts. |
| 5 | Staff finds one enquiry, updates status and exports authorised subset. | Owner can revoke access and apply approved retention/correction process. |
Do not substitute a tick for an observation: record the count, measurement, approved sample or evidence reference used at each checkpoint. Mark unresolved work as held and identify who can approve the recheck.
Diagnose a failure before repeating it
| Observed symptom to investigate | Check the cause | Proposed response |
|---|---|---|
| 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. |
These are diagnostic prompts, not proof of the cause in a real incident. Separate suspect output, record any correction and repeat the relevant acceptance check. Link rejected units, rework time, replacement materials, customer credits and collection delays to the actual job result.