Operations · Africa
WhatsApp is an excellent channel and a poor system of record. A chat log has no schema, no state and no identity key you can rely on, so it cannot answer what a customer owes or which quotes are open. Keep the channel, and move the record into a system that can.
Last updated 2026-09-04. Published by Umbra ERP.
The reason business moved into WhatsApp is not inertia. Every property that makes it awkward as a business tool is a property that makes it excellent as a channel, and the trade was a sensible one at the time it was made.
It removes the acquisition step entirely. The customer already has the app, already has your number, and does not have to be persuaded to do anything new. Any alternative channel starts from zero: a download, an account, a password, and a reason to bother. That gap is not a marketing problem to be solved with better copy, it is a structural cost that gets paid on every single customer.
It also degrades gracefully. A text message is a few hundred bytes and the client queues and retries it, so a conversation survives an intermittent connection, a train tunnel and a load-shedding window. A web application on the same connection either loads or it does not, and a half-loaded page with a submitted form is worse than no page at all. On networks that are fast on a good day and unusable on a bad one, the channel that buffers wins.
And it carries the formats orders actually arrive in. A photograph of a handwritten list, a picture of the exact part needed, a voice note recorded while driving, a forwarded spec from someone else's chat. A structured order form cannot accept any of those, which is why customers ignore structured order forms. The channel adapted to the customer rather than the other way round, which is the correct direction for a channel.
A chat log is an append-only sequence of untyped events. That is the whole of its data model, and every limitation follows from it directly rather than from any deficiency you could fix with better habits.
It has no schema, so there are no amounts, only text that looks like amounts. "1800 for the lot" is a string. Nothing can sum it, age it, or compare it to a credit limit. The question "what does this customer owe me" requires aggregation over typed values, and a chat log holds none, which is why the answer to that question in a WhatsApp-run business lives in somebody's head and changes depending on who you ask.
It has no state, only messages. A quote that is open, a quote that was accepted verbally, a quote that has expired and a quote that was superseded by a better price all look identical in a thread: a message from three weeks ago. There is no field that transitions. So the business cannot list its open quotes, cannot age its pipeline, and cannot tell whether a customer who has gone quiet is deciding or gone.
Its identity key is a phone number, which is weaker than it looks. One customer messages from the office line on Monday and a personal handset on Thursday. A company changes the person who does the ordering and the number changes with them. Two numbers, one debt, and nothing in the channel connects them. Meanwhile the same number may be one person acting for three different businesses, which is the reverse problem.
And it holds no documents that anyone else accepts. A supplier's accounts department cannot process a screenshot. A tax authority cannot assess one. The chat is where the commercial agreement happened, and it is categorically not where the evidence of it can live.
The most expensive property of a chat-run business is rarely discussed because it only surfaces once, badly. The customer history is on a handset. The handset belongs to a person. The person can leave.
When a salesperson resigns, the business does not lose a contact list, it loses the entire negotiation history for their accounts: what was promised, what discount was agreed, what the customer complained about in March, which delivery went wrong. Their replacement starts from nothing and the customer notices immediately, because they have to explain their own history to the company they have been buying from for four years.
A phone backup does not solve this, because a backup is an archive rather than a database. It restores to another handset, in the same unindexed form, readable only in sequence. Nobody is going to scroll two years of messages to answer whether a rebate was agreed. Data you cannot query is data you do not have.
The fragmentation compounds with headcount. Four salespeople means four disjoint views of the customer base, with no way to search across them, no way to detect that two of them are quoting the same buyer, and no way for a manager to see the pipeline without asking four people what they think it is. Every one of those answers is an estimate produced from memory, and estimates produced from memory are systematically optimistic.
The absence of state deserves its own treatment, because it causes the most visible commercial damage and it is the easiest to fix.
Consider the ordinary case of a customer who enquired three weeks ago, received a price, and has now come back to ask again. In a chat, the second enquiry looks exactly like a first enquiry. It arrives clean, with no marker attached saying that a live quote already exists. So a second quote gets raised, with a different number, possibly a different price because the person raising it is not the person who raised the first, and now the customer holds two documents from you and will act on whichever is cheaper.
The same absence produces the follow-up failure. Nobody chases a quote at day seven, because nothing surfaces at day seven. There is no list of things awaiting a decision, only a thread that has stopped moving among forty other threads that have also stopped moving. Deals do not get lost to competitors nearly as often as they get lost to silence.
This is exactly what a status field is for, and why Umbra's intake flow runs a deterministic check for open quotes raised for that customer in the last 90 days before it proposes anything. A repeat enquiry surfaces the existing quote and the number of days it has been open, so the person handling it can revise rather than duplicate. That check is a database query with a fixed window, not a judgement, so it returns the same answer every time it runs.
The instinctive fix is to move customers onto something structured: a portal, an order form, an app. This fails for a reason that is worth stating precisely, because it fails the same way every time.
The benefit of the move accrues entirely to you and the cost accrues entirely to the customer. They install something, create an account, remember a password, and learn an interface, in order to improve your bookkeeping. Nothing in that trade is attractive from their side, so adoption stalls at the handful of customers who were already the easiest to deal with, and the rest carry on messaging. You now run two systems and reconcile between them, which is worse than the position you started from.
The correct move is to leave the channel alone and change where the record lives. The customer keeps messaging. What changes is that the conversation stops being the final destination of the information and becomes the input to something that can hold it properly: typed amounts, a customer identity, a document with a number, a status that transitions, a balance that can be aged.
That reframing also settles an argument that consumes a lot of time internally. The channel does not need to be complete. It does not need to hold the price list or the credit limit or the delivery history. It needs to be where the customer is comfortable talking, and one step needs to exist that gets what was agreed into the system of record.
This is where product marketing in this category tends to overstate, so it is worth being exact. Umbra does not connect to WhatsApp. It is not a WhatsApp Business API provider, it does not send messages, and it does not receive them. No customer traffic is routed through it.
What it does is read a conversation you give it. You paste the thread in, or you attach a photographed order or a PDF, and the assistant extracts the facts: who the customer appears to be, their contact details, what was asked for, quantities, delivery details. It then checks those facts against your existing records deterministically, matching on exact email, on the last nine digits of the phone number, and on a fuzzy name score, and looking for open quotes raised for that customer in the last 90 days. It proposes what to create, and nothing is written until you confirm.
The paste is a real cost and pretending otherwise would be dishonest. It is a deliberate action per order rather than zero actions. In exchange you get three things an integration would not give you. The conversation can come from any client, any handset, a desktop app or a colleague's forwarded screenshot, because the input is content rather than a connection. There is no account approval, no message template pre-approval and no third party in the path of your customer traffic. And the boundary between the chat and the ledger stays a place where a person looks, which is precisely where you want the boundary when the thing on the far side is your receivables.
What the assistant can propose covers the useful shape of an order: a customer, a lead, a quote with lines, invoice lines, and a follow-up message drafted for you to send through whichever channel the conversation is on. It sends nothing itself. Prices on the proposed lines are re-read from your product catalogue at the moment of execution, so a figure somebody typed into the chat never becomes the price on the document.
Once the record exists, the conversation can carry on as normal, with the difference that what you send into it now comes out of a system rather than out of a text field.
A quotation can carry a private client details link. This solves the single hardest thing to extract from a chat, which is the customer's own registration data: legal name, physical address, TIN, VAT number and billing email addresses. Asking for those in a message produces partial answers over four days. Sending a link produces them in one action, entered by the person who actually knows them. The answers merge onto the customer record, and a field left blank is treated as unanswered rather than wiping what you already hold, so a half-completed form cannot destroy good data.
Invoices and quotes can carry pay links for card and EcoCash. The link is something you paste back into the conversation yourself, which keeps the payment request in the channel the customer is already in without Umbra touching that channel. These links are enabled per account by an administrator rather than being self-service, and they settle in US dollars, with ZWG not enabled on the card rail, so plan the local-currency portion of your book around a different settlement route.
When a payment is recorded, by any route, a receipt is raised automatically. Sending that receipt to the customer is a separate and deliberate action, which is a distinction worth knowing rather than discovering. And where a customer buys on a rhythm, recurring invoices and recurring quotes will generate on a schedule, weekly through to annually, pinned to a day of the month with month-ends handled, with optional automatic sending. The recurring customer stops depending on somebody remembering.
Tax deadlines run from commercial events, and in a chat-run business those events happen in the chat. That is the real reason the record has to be somewhere else: the obligation is created by a message and discharged by a document.
In Zimbabwe, a fiscal tax invoice must be issued within 30 days of the supply. The supply is the goods leaving your yard after a WhatsApp exchange, not the moment somebody gets round to typing it up. A tax invoice is not required where the amount is less than US$10.00, which is a genuinely useful floor for small counter sales. Registration for VAT becomes compulsory once taxable supplies exceed or are likely to reach US$25,000 or the ZiG equivalent in a 12-month period, a threshold effective from 1 January 2024, and the standard rate is 15.5 per cent. Returns are due on or before the 25th of the month following the tax period, under the Value Added Tax Act (Chapter 23:12).
The window that catches people out is on the other side of the transaction. Input tax must be claimed within 12 months of the date of the invoice. A customer who never received a proper invoice because the order lived in a chat loses their deduction, and they will remember which supplier caused that when they next choose between two quotes.
Payroll runs on the same principle. PAYE is remitted on or before the 10th of the following month, into the ZIMRA Single Bank Account, in the currency in which the earnings were received. None of these deadlines can be met from a message history, and none of them care that the underlying agreement was informal.
Fiscalisation is worth stating carefully because it is often oversold. Umbra submits to ZIMRA through a FiscalCloud virtual fiscal device, and submission is triggered by a person, per invoice or per batch. Issuing an invoice does not fiscalise it on its own, and Umbra is not a ZIMRA-certified device in its own right. What it gives you is a fiscal status visible on each invoice, so you can see what has been submitted and what has not, which is the thing a chat log can never tell you.
The change worth making is small and specific. It is not a migration, a portal, or a request that customers behave differently.
The test is whether the business can answer three questions without opening a phone: what is outstanding, which quotes are live, and what did we agree with this customer last time. If the honest answer to any of those is that somebody would have to scroll, the record is still in the chat, and everything downstream of it is an estimate.
You can paste the conversation into Umbra and it will read it, check the details against your existing customers and open quotes, and propose the records to create, such as a customer and a quote with priced lines. You review the proposal and confirm it before anything is written. Prices come from your product catalogue, not from the conversation.
No. Umbra is not a WhatsApp Business API provider, it does not send or receive messages, and no customer traffic passes through it. The capability is that you give it a conversation, by pasting the text or attaching a photographed order or a PDF, and the assistant reads what you gave it.
It is evidence of a conversation, not a record of a transaction. It holds no typed amounts, no document numbers and no status, so it cannot produce a tax invoice, a statement or a VAT return. In Zimbabwe a fiscal tax invoice must be issued within 30 days of the supply, and that obligation cannot be met from a message thread.
If the history lived in the chat, it leaves with them: the negotiation, the agreed discount, the complaint from March. Their replacement starts blind and the customer notices. The fix is not a policy about phones, it is making sure the agreed outcome of each conversation lands in a shared system at the time it is agreed.
Yes, by copying the link from the invoice or quote and pasting it into the conversation yourself. Card and EcoCash pay links are enabled per account by an administrator and settle in US dollars. The payment then reconciles against the document, and a receipt is raised automatically when it is recorded.
Yes. The intake flow accepts an attachment as well as pasted text, so a photographed order or a PDF can be read and turned into a proposal. Attachments cover a photographed order and a PDF, so where an order arrived as a voice note, type the details in yourself and run the intake on that text.
Give quotes a status in a shared system, and check before raising. Umbra runs a deterministic check for open quotes raised for that customer in the last 90 days and surfaces them before it proposes a new one, so a repeat enquiry becomes a revision rather than a second document with a different number and possibly a different price.
Usually not. A portal asks the customer to install something, create an account and learn an interface so that your bookkeeping improves, which is a trade with no upside on their side. Adoption stalls, most customers keep messaging, and you end up running two systems. Keep the channel and fix the record behind it.
Regulatory figures on this page are taken from the following primary sources. Tax rates and thresholds change; check the source before relying on a figure.