You already message your members. Can you prove they agreed?
Statements go out by bulk SMS at a flat rate whether anyone reads them. Reminders come from a staff handset. And when a member disputes being contacted, or the Data Protection Commissioner asks, there is nothing to show. Sema sends on WhatsApp, and keeps the record that makes it defensible.
Kenya · African Creator, Pexels
The four things you send
All of them are templates Meta has approved in advance, so they reach a member whether or not a conversation is already open.
Statements and balances
UtilitySend a member their balance or a statement summary as an approved utility template. They reply in the same thread, and that reply opens a 24-hour window your team can answer in with anything.
Repayments and contributions, collected
UtilityA reminder that arrives where people actually read. When the member replies, your team sends the M-Pesa prompt from the same conversation, into your own paybill, with the loan or member number as the reference. Your team sees it paid, with the receipt, once M-Pesa confirms it.
Renewals and lapse notices
UtilityReach a policy or loan cohort before it lapses. Contacts are segmented by tag, so a renewal run goes to the people it concerns and nobody else.
Login and confirmation codes
AuthenticationOne-time passwords over WhatsApp rather than SMS, on the authentication rate. Delivery is recorded per message, so a disputed login has an answer.
Four questions, and where the answer lives
Sending is the easy part. These are the questions that come afterwards, and the reason a spreadsheet of numbers and a staff phone stop being good enough once you are regulated.
- Did this member agree to hear from us?
- Every contact carries when and how they opted in, and each consent change is kept as an event rather than overwritten. STOP is honoured automatically and recorded, so an opt-out is provable too.
- Who sent this, and from where?
- Actions are written to an audit log with the member of staff, what they acted on, and the address they acted from. A message is never just "sent by the system".
- What did it actually cost?
- Each message is priced before it sends and reconciled afterwards against what Meta charged. Meta’s charge for a message it does not bill is not taken from you, and a failed one is refunded automatically.
- Did they actually pay?
- A payment is marked paid only once Sema has asked M-Pesa itself, with your own credentials, never on the word of the message M-Pesa posts back. The receipt is kept against the conversation, and your core system can be told by webhook the moment it is confirmed.
- Can we remove a member’s data on request?
- A contact’s data can be exported for a subject access request and erased on request, while billing records are retained for the seven years Kenyan tax law requires.
Segregation of duties, enforced by the database
Roles are not a setting the interface honours and a script ignores. The boundary is a row-level policy in the database, so a member of your finance team can reconcile the bill without being able to read a single member conversation, however they connect.
An organisation always keeps an owner, and only an owner can appoint another. That rule is a database trigger, which means it holds for the interface, for support scripts, and for anything else.
- Owner
- Everything, including closing the workspace
- Admin
- Everything operational, including billing and connecting numbers
- Manager
- Runs conversations and campaigns. No billing
- Agent
- Answers members. No billing, no settings
- Billing
- Credit and invoices only. Cannot read a single conversation
- Viewer
- Read-only
What it looks like
Pictures of Sema itself, from a sample workspace, as it is today.
A member pays by M-Pesa in the chat, into your own paybill, and it shows once M-Pesa confirms it.
Statement and reminder runs: who each reached, who read it, and what it cost.
The parts behind it
- Payments →
Repayments and contributions by M-Pesa, confirmed by M-Pesa, with the member number as the reference.
- Campaigns →
Statements, repayment reminders and AGM notices to the members who agreed.
- Automations →
A loan pre-check form, and follow-ups to members who went quiet.
- The API →
Your core system sends balances and one-time codes, and hears about every payment.
Ready for your trade
- Message templates, already written →
The messages your trade sends most, written the way Meta approves them.
- A loan pre-check form, and an insurance quote →
A form your customers fill in without leaving WhatsApp, made already; you change its words.
- A first week, set up for you →
Which messages, automations and reports to start with, in the Help Centre.
Your customers’ data, protected
A member’s money is the most private thing they share with you. These hold whoever signs in, and however they connect, because the database enforces them, not the screen.
Roles the database enforces
Owner, admin, manager, agent, billing and viewer. The billing role reads the money and never a conversation, however it connects.
Two-factor sign-in, for everyone
An owner can require a code from an authenticator app of everybody in the workspace.
An activity log
Sign-ins, failed sign-ins, team changes and keys: who, when and from where.
Consent on the record
When and how each customer agreed, as Kenya’s Data Protection Act asks, and STOP honoured in English and Kiswahili.
Kept as long as you choose
Messages kept until deleted, or from 30 days to five years, and a customer’s data exported or erased on request.
Is it working?
Sema checks itself every minute, and says what it found on its status page.
Start with one product line.
Connect your number, import the members for a single scheme, and send one statement run. You will see the cost before it goes and the record after.
Start freeNothing to pay to start. Talk to us first on 0784 155 752, or on WhatsApp.