CRM & Customer Platforms

03

The customer relationship is a history

A relationship is not a contact card. It is everything that has happened: the first enquiry, the three quotes, the negotiation, the sale, the delivery that was late, the complaint, the person who fixed it, the repeat order. A CRM that remembers all of it means the next person who touches the customer starts from the whole story — not from whatever the last person chose to remember.

• Every touch appended — calls, messages, visits, orders and complaints are appended to one file, in order, so the story reads forward and nothing vanishes into a notebook.
• Contacts and companies — a person works for a company and belongs to a household; the file models the real structure instead of flattening everything into one flat list.
• Context that travels — a new salesperson sees what was promised, what was ordered and what was complained about — without asking the customer to repeat it.
• The file outlives the person — when the account manager leaves, the history stays; the relationship belongs to the business, not to one employee's memory.
• History that answers fast — a customer calls on a Friday; within seconds the whole story is on screen, so nobody says 'let me get back to you' for a thing they already paid for.
• Evidence on the file — agreements and correspondence attach with who-and-when, so disputes resolve by evidence rather than by who is louder.

The customer history is the product of a CRM. Everything else — pipelines, follow-ups, service — is a discipline built on top of a story told honestly.

04

One file per customer

Duplicates are the silent killer of customer platforms. The same customer in the system three times, under three spellings, with three different histories — and everyone believes they are three customers, or worse, one customer missing two-thirds of their history. We engineer deduplication into the data layer, not the manual clean-up list.

• Identity rules at intake — phone number, which in Kenya is the identity that matters, and name normalisation keep the same person from being created twice at the first screen.
• Match on the canonical +254 — the number is normalised to one form so a customer who pays by PayBill, books by phone and emails from a different address is still one file.
• Merge without loss — when duplicates are found, histories, notes and orders merge into one file; nothing is deleted, everything is re-parented.
• One view of the truth — every department reads the same file, so sales, service and collections stop believing their own private versions of the customer.
• The file is the boundary — permissions and privacy attach to the file, so what one team may see and another may not is a rule, not a feeling.
• Clean at the door — the system flags the obvious duplicate with 'there is already a file that looks like this' instead of quietly creating a second future.

One customer, one file, one history. That single invariant is what makes every other CRM feature honest — and it is built in, not cleaned up later.

05

The activity timeline

The timeline is the CRM's heartbeat — the record of what actually happened rather than what should have happened. We build timelines complete enough to trust and fast enough to actually check, because a timeline nobody consults is just a more expensive diary.

• Everything lands in one stream — calls logged, meetings, quotes sent, emails, payment reminders and complaints — chronological, on the file, never in six different tabs.
• Written by the system, not the diary — the timeline is populated as events happen, so 'did we call him back' is answered by the record, not by a person's certainty.
• Two-way with the phone — inbound and outbound calls and messages append automatically, so the timeline does not depend on the salesperson's memory of the day.
• Filters by type and date — sales wants the quotes, service wants the tickets, the manager wants the calls; one timeline with saved views serves all three.
• Attachable evidence — files, photos and receipts attach to the moments they belong to, keeping the story richer than text alone.
• Immutable in substance — notes correct by appending, not overwriting, so the timeline cannot quietly rewrite history when things went wrong.

A timeline that can be trusted is worth more than a dashboard that cannot — it is the raw material every honest analysis is cut from.

06

Pipelines that tell the truth

A pipeline that looks full and never closes is a decoration. We build pipelines that reflect reality — which deals are moving, who is stuck, what the expected close really is — so management reviews the numbers instead of the optimism.

• Stages with real criteria — a deal moves stage when evidence exists, not when someone feels hopeful; the criteria for each stage are written down and applied.
• Weighted, not fantasised — the forecast values the pipeline with the probability honestly attached to each stage, so 'expected revenue' is a calculation, not a hope.
• Stale deals surface — a deal sitting in a stage past its expected time glows on the dashboard, because the quietest revenue leak is the deal nobody touched.
• Activity behind the stage — the pipeline shows what is actually being done on each deal — last call, last quote, next step — so a 'moving' deal can be checked.
• Exit honesty — deals close or die; a pipeline that never records the lost deal hides the pattern of why deals are lost.
• Conversion by cohort — win rates by source, product and salesperson are computed from real outcomes, so effort flows to what actually converts.

A pipeline is a forecast engine, and a forecast engine that lies is worse than no pipeline at all. Ours are built to survive the month-end review.

07

Deal stages with real criteria

A deal stage that means 'kind of proceeding' means nothing. Every stage in our pipelines comes with explicit entry and exit criteria — the evidence that makes the next stage true — so movement through the funnel is a matter of fact, not of temperament.

• Written entry criteria — 'meeting attended', 'quote sent', 'budget confirmed' — a deal cannot enter a stage without the evidence that defines the stage.
• Exit means progress — a deal leaves a stage when the next criterion is met, so the pipeline reflects actual progression rather than emotional progression.
• Probability per stage — each stage carries an honest close probability, reviewed against real historical outcomes rather than inherited from a template.
• Expected close computed — the forecast reads the committed dates and the stage probabilities together, so 'this month' means something testable.
• Stage-walk visible — sales leadership can see not just where deals sit, but how long each has sat there, by whom, and with what recent activity.
• Dead deals die properly — a lost deal is recorded with its reason, because the pattern of losses is where the next quarter's wins are hiding.

Stages without criteria are horoscopes. Criteria make the pipeline a management instrument instead of a mood ring.

08

Follow-ups that never slip

Customers forgive a lot except being forgotten. The follow-up is where the sale, the renewal and the relationship are actually won or lost. We build follow-up machinery into the system so 'I was busy' stops being how commitments die.

• Scheduled by the record — the next action, the next call date and its reminder live on the file, so nothing depends on a person's intention to remember.
• Due today, visible today — the dashboard opens on the follow-ups that are due now; the system makes the day's obligations unmissable rather than merely searchable.
• Escalation when it slips — a follow-up that goes overdue escalates to the manager with the customer's file attached, because silence is a decision nobody made.
• Rescheduled deliberately — moving a follow-up requires a reason and a new date, so 'later' becomes a decision with a calendar, not a vanishing.
• On the customer's rails — the reminder goes out by the channel the customer actually answers — WhatsApp, SMS or email — not the channel that is convenient to us.
• The proof is the outcome — every follow-up closes with a result that appends to the timeline, so the cadence produces history, not just pings.

We run live reminders on our own platform — rent cycles, renewals, grace windows — and the discipline is identical: the system remembers so the person can care.

09

Service without dropped threads

Customers remember the ticket that vanished as much as the product that worked. We build service desks with resolution tracking, SLAs and escalation, so no thread dies silently and no customer has to re-explain their problem to a third agent.

• Tickets tracked to resolution — every request has an owner, a state and an outcome; a ticket is closed by evidence, not by the widget closing.
• The customer's problem is the record — the ticket carries the customer's words, the fix, the time taken and the follow-up, so the history is coherent end to end.
• Escalation with a pulse — a ticket that breaches its SLA escalates automatically with its full context, so 'unresolved' is never a quiet state.
• Re-openable without shame — a customer who comes back is the same ticket, reopened with history intact, not a brand-new stranger with a brand-new problem.
• Handoffs that do not drop — when ownership changes, the trail shows who had it, what they did and what remains, so nothing is lost in the transfer.
• Complaint-to-leverage loop — the themes in tickets feed the product and operations backlog, so the same problem stops costing the business twice.

Service is memory. The customer is the one who remembers the dropped ticket; we build so the system remembers first.

10

SLAs and escalations that mean something

An SLA that nobody watches is a wish. We wire service levels into the system as hard states: response clocks start the moment a ticket lands, breaches trigger escalations automatically, and the history shows exactly where the time went — because 'why was this slow' is a question that always gets asked.

• SLA clocks that start at intake — the response and resolution clocks begin the moment the ticket arrives, not when an agent happens to look at it.
• Breach triggers escalation — crossing the response time automatically escalates to the next level with the ticket attached, so nobody has to monitor a clock.
• Priorities that carry weight — 'customer cannot transact' and 'cosmetic question' are different promises, priced honestly in the SLA and honoured differently.
• Time attribution visible — the timeline records which queue, which agent and which wait each hour belonged to, so improvement is a plan, not a debate.
• Escalation etiquette — automatic does not mean robotic; the customer is told, in the right tone, that their case has been raised up, not dumped.
• SLA reports on outcomes — adherence is measured and reviewed at the cadence leadership actually meets, with the same honesty as the sales forecast.

An SLA is a promise with a clock and a paper trail. Built properly, it makes the service floor faster and calmer at the same time.

11

Self-service that deflects politely

The simple questions should not need a human, and a human should not need to repeat the answers. A self-service portal that deflects the common questions — status, FAQs, the form they need — saves the floor's energy for the questions that genuinely need a person, without ever making the customer feel processed.

• Politely first — the portal answers the top queries — where is my order, how do I renew, what are the rates — using the customer's own data, not a generic FAQ wall.
• A human is one tap away — every self-service dead-end offers a real person, so deflection never becomes a wall.
• Status with the same truth — the portal reads the same records the agents see, so the customer and the agent look at the same reality, not two versions of it.
• Auth that protects — the portal is locked to the customer, and in Kenya the phone — the M-Pesa and PayBill number — is often the key that fits.
• Escalation leaves a file — a portal question that becomes a ticket lands on the customer's file with the trail intact, not in a parallel universe.
• Measured deflection — we watch what the portal absorbs and what it fails to absorb, because a portal that confuses customers doubles the work instead of halving it.

The goal is not to keep customers away from humans — it is to make sure the human they eventually reach has the context and the time to actually help.

12

The sales floor measured honestly

Sales teams run on targets, and targets run on data. When the data is self-reported and unreviewed, the forecast is fiction. We build the floor's reality into the system — activity, pipelines, outcomes — so performance conversations are grounded in the records both sides can see.

• Activity is visible, not volunteered — calls, meetings and follow-ups enter the timeline as they happen, so 'I've been busy' has a shape leadership can see.
• Outcomes beat optimism — win rates and conversion are computed from closed deals, so performance review is a reckoning with reality, not a debate about feelings.
• The manager sees the pipeline, not the summary — leadership can look at every deal, its stage, its age and its last activity, because that is where the problems live.
• Commissions from the record — payoffs reference the confirmed outcomes and the ledger, not a discretionary spreadsheet; the numbers both sides accept are the same numbers.
• Coaching data, not surveillance theatre — the purpose is to show where help is needed — which stage stalls, which step trips new hires — not to turn the CRM into a spy.
• Territory truth — accounts and allocations are explicit, so the question 'whose deal is this' is answered by the record and not by whoever claimed it first.

A sales floor that trusts its own numbers argues about the market instead of about the data. That is the trust we build the records to support.

13

WhatsApp, SMS, email and the broadcast

Where Kenya's customers actually live is WhatsApp and SMS; email is the official record. We build communication into the customer platform — one-to-one and broadcast — on the channels customers have open, with consent, quiet hours and delivery honesty. A message nobody receives is worse than no message, because it costs money and quietly erodes trust.

• Templates with placeholders — follow-ups, payment reminders, confirmations and apologies render with the customer's name, reference and amount, so broadcasts never feel like mailshots.
• Consent and quiet hours — who opted in, on which channel, and the hours the business will not ping them, are recorded and enforced; a customer who is shouted at by a 10pm reminder will not stay a customer.
• Broadcast with delivery honesty — sends are tracked for delivered and failed, and numbers that hard-fail are quarantined before they become a cost and compliance problem.
• Transaction messages ride the money — the STK confirmation, the receipt and the PayBill reference reach the customer the instant the money moves, because silence is anxiety.
• A reply is a person, not a bot alone — a WhatsApp number behind a business is staffed sensibly; the system routes, the human decides, and the record appends both.
• Promotional restraint — send cadence is disciplined: the customer who just paid does not need an upsell in the same breath as their receipt.

We run the same discipline on KodiiPay — every payment movement produces a message — and we bring that reliability to every customer platform we build.

14

Money inside the CRM: from quotation to collection

A customer platform that stops at the promise is a customer platform that lets its sales slip into the gap between 'we will invoice you' and 'the money is in'. We connect the CRM to real collection: quotes become invoices, invoices become a payment link or an STK Push, and the cleared money lands back on the customer's file as history.

• Quotation to invoice in one motion — the accepted quote becomes the invoice with its line items intact, so nobody re-keys a number that can drift.
• Collect on the customer's own rail — the invoice carries its payment path — STK Push to the phone, a PayBill account or a Till on M-Pesa/Daraja in the home market, cards and PayPal elsewhere — and the money moves the moment the customer is ready.
• One ledger for every collection — payments, refunds and fees are entries with references, written atomically with the balance they change.
• Confirmed, never assumed — a payment claim is verified against the gateway's own status before it is booked; the customer is never credited on hope.
• Idempotent to the bone — a retried or double-delivered callback returns the settled truth; the money is never counted twice by a flaky network.
• The ledger reconciles — day totals match the statement, so 'what did we collect today' is a number the accountant and the bank both agree with.

The collection is part of the relationship, not an awkward sequel to it. When the money clears cleanly and the receipt arrives instantly, the customer's trust in the business grows.

15

The rails between the quotation and the cleared funds

A quote is a promise and a payment is the proof, and the customer settles that proof on the rail they already trust — the STK push on their phone, the card saved to the account, a PayPal balance, a wire from the bank. The file must end up holding the same settled truth whichever pipe carried the money. M-Pesa/Daraja is our home-market lived example of that discipline, and every rail we add earns exactly the same treatment.

• The invoice meets every gateway — the payment path a customer is offered comes from the rails they actually hold, not from whichever gateway the vendor found easiest to wire.
• One collection flow, every adapter — M-Pesa/Daraja, PayPal, Stripe, PayStack, cards and bank transfers plug into the same flow under the same verification contract.
• A callback is a claim on every single rail — the gateway's 'successful' notice is double-checked against its own status before the ledger or the customer's file records a credit.
• The retried payment never double-charges — idempotency keys absorb re-sent requests and doubled deliveries across every adapter, so the payment history on the file stays single.
• The receipt follows the rail that actually moved — the confirmation carries the M-Pesa reference, the card receipt or the transfer slip of the channel that settled, so the customer's trust matches the record.
• Every adapter reconciles on its own statement — day totals per rail are matched to that rail's settlement, surfacing drift while it is still cheap to fix.

A customer who pays by card one month and by M-Pesa the next is still one customer with one file, provided every rail lands in the same ledger under the same discipline. We build so the relationship story stays whole no matter how the money travels.

16

Search and context

A CRM that cannot find the customer is a filing cabinet with a broken drawer. Search is not a feature on the side — it is the front door of the whole platform, and it has to open fast, because every search is usually happening while a customer is on the line.

• Typeahead on every screen — the customer, company or ticket is found as the agent types; nobody submits a query to find a record they already know.
• Search across the history — names, phones, references, order IDs and even note text are indexed, so 'the one who called about the delivery' is findable, not folklore.
• Context persists — opening a customer keeps their file, timeline and open tickets on screen together, so the agent's next answer is already loaded.
• Saved views for the daily list — 'my calls today', 'overdue follow-ups', 'accounts owing this week' — the lists the floor actually lives in, one click away.
• Results respect permissions — search shows what the searcher is allowed to see, enforced at the data layer rather than by tidy behaviour.
• Fast even when it grows — indexes and bounded queries keep search instant as the file count grows into the millions, so speed does not rot with scale.

Every second a customer waits while an agent searches is a second the relationship pays for. We build search that makes the wait a memory.

17

Security: who sees the customer file

The customer file is commercially sensitive — pricing, payment behaviour, complaints, contacts. Access to it must follow the role and the need, enforced by the database, with the customer's own view kept separate from the staff's. A CRM that cannot keep its secrets cannot keep its customers.

• Roles that match the floor — sales sees sales records, service sees tickets, finance sees balances; the file respects the org chart, not the curiosity.
• Row-level data control — what was said in a private negotiation stays where its owner can see it; branch, team and ownership scope the rows the database serves.
• Audited every access that matters — views of sensitive fields and every change of record are logged with actor and timestamp, so discretion is structural, not hoped for.
• Consent recorded with the contact — marketing-consent, opted-in channels and quiet hours live on the file with the customer's word on it, ready for a data-protection question.
• The customer's own portal — self-service shows the customer their data under their own sign-in, never the internal file with margins and notes attached.
• Export as a controlled act — bulk export is a permission with a log, because the spreadsheet is how the whole file would actually walk out of the building.

The customer file is a vault with a spreadsheet's convenience — when the vault rules are enforced by the system, convenience does not cost the secret.

18

Integration with the rest of the stack

A CRM in an island makes the sales floor its own data centre. The real customer platform connects — to accounting, the website, email, telephony, WhatsApp and payments — so the relationship record is enriched by reality instead of quarantined from it. And every integration is built to survive the flaky network.

• Accounting sync — invoices, payments and credit notes post to the books from the same records, so finance and sales never reconcile two versions of yesterday.
• Web and lead capture — form submissions, website enquiries and campaign responses become files with source attribution, so lead origins stay answerable.
• Telephony — call logs and recordings attach to the caller's file automatically, so the timeline holds the voice of the relationship too.
• WhatsApp and SMS — conversations append to the file in both directions, so the customer's preferred channel is part of the same history as the office emails.
• Payment rails — M-Pesa/Daraja, PayPal, Stripe, PayStack, cards and bank transfers flow into the ledger and the file as first-class adapters under one disciplined machinery — verified, idempotent, reconcilable.
• Webhooks with dead-letter honesty — what fails is quarantined visibly with its payload, so a lost notification never means a lost follow-up or a lost record.

A customer platform is the hub, not the island. We wire the hub to everything the business already runs so the story writes itself.

19

Operations: the platform that runs while you sleep

A CRM is judged on ordinary days — the reminder that fired, the ticket that escalated, the reconciliation that matched, the broadcast that delivered. We build the operational layer so the system does its steady work without anyone needing to remember, and reports honestly when it cannot.

• Scheduled engines — follow-up checks, SLA clocks, reminder sends and overdue escalations run on clocks with advisory locks, never on 'someone remembers'.
• Delivery telemetry — every scheduled communication knows whether it was delivered, read or failed, because a reminder that never arrived is a promise broken silently.
• Reconciliation jobs — collection totals match the statement on schedule; a mismatch becomes a visible workflow instead of a quiet drift.
• Health monitoring — integration latency, queue depth and error rates are watched before users notice, because slow is a papercut with a timeline.
• Backups that restore — the restore is rehearsed, not assumed; a backup that has never been restored is a hope, not a backup.
• A support path with timelines — when the business raises an issue, it gets a timeline, not a void; software without a support path is an incident waiting for a weekday.

The measure of the platform is a quiet Tuesday: the follow-up fired, the ticket moved, the money reconciled, nobody melted down. That is the ordinary standard we build for.

20

Honest limits of a customer platform

A CRM can organise a relationship, but it cannot manufacture one. The pipeline reflects the sales effort; it does not replace it. The follow-up machinery fires on schedule, but the human warmth of a follow-up is still human. We say these things plainly, because the vendor who promises software that 'sells for you' usually sells disappointment.

• The system writes history; people make it — the CRM is the memory of the relationship, not the relationship; garbage behaviour produces a meticulously recorded version of garbage.
• Adoption is a people problem wearing software clothes — the finest CRM can be defeated by a team that never chose it; we build the change with the floor, not at it.
• Data quality flows from the floor — the timeline is as honest as the entry habits around it; we build guard rails, but the humans must feed the machine.
• Delivery is not the same as affection — WhatsApp and email reach the phone; only a human makes the message feel like care, and the system should leave room for that.
• Forecasts are probabilities, not promises — a pipeline forecast is a reasoned estimate, and we label it as such rather than let it be recited as a guarantee.
• Money integration raises the bar — the moment the CRM collects payments it becomes a money system with money discipline, and that is exactly where our standards live.

We prefer to hand you honest machinery and a realistic plan than a fantasy with a dashboard. The honest version is the one that still feels right after two years of Thursdays.

The toolchain

The customer operations toolchain

The stack behind a customer platform that remembers everything, tells the truth about the pipeline, communicates on the customer's rails and collects without friction — the same discipline our own payments platform runs on.

Lifecycle

The customer platform lifecycle — from the first file to a floor that trusts it

Every customer platform we build follows the same arc: understand how the business really relates to its customers, build the memory and the follow-through, wire the money, then make the floor the system was built for the ones who keep it alive.

Closing

More than development

A customer platform is the business's memory of the people it serves — every touch, every promise, every payment, every complaint, every follow-up. We build the memory so it holds. That includes:

The customer relationship is the longest-lived asset a business owns. The platform should make it longer, richer and more honest — not a cage the relationship has to fit inside.

We build the memory a business can rely on — because the customer is always the one who remembers what the system forgot.