Skip to main content
[ LOG / FIELD NOTES ] ←17:41:09

One Engine, Many Surfaces: Why We Built for WhatsApp and Voice

May 28, 2026 · Product · 6 min READ

The channel is not the product. WhatsApp is where Streemline started because that is where business in Ghana already happens, and voice is where we are going next because plenty of customers would rather call than type. But the thing that makes the system trustworthy — a deterministic core, human approval on consequential actions, every action written to the Record — lives underneath the channel entirely. If that layer is built right, a new channel is a new surface, not a new system. If it is built wrong, every channel is a separate liability.

This post explains the architecture decision and what it took to hold onto it.

Engine below, surfaces above

The SOUL Engine does not know it is on WhatsApp. Every inbound interaction, whatever the surface, is converted into the same internal shape: who is asking, what they want, what data and rules apply. From there the path is identical:

  • Deterministic lookups answer the questions that have exact answers — which is most of them. These interactions never touch an AI model.
  • The model handles interpretation where language is ambiguous, and only proposes.
  • Consequential actions stop for human approval, per the rules the business set.
  • Everything is written to the Record, append-only, in one trail.

    • The surface layer above is thin: adapters that translate between a channel's native format and the internal one. WhatsApp is one adapter. Voice is another.

    Why WhatsApp first

    WhatsApp in Ghana is not one channel among several; it is where the customer already is, for buying, complaining, and confirming payment. Meta's own reporting has long put WhatsApp's global user base in the billions, and anyone operating in West Africa can see its saturation without needing a statistic. Starting anywhere else would have meant asking customers to change behavior, which is the one thing an operations product must never require.

    Why voice second

    Voice matters here for reasons that are easy to miss from a desk in another market:

  • Many customers are more comfortable speaking than typing, in whatever language they think in
  • A phone call works on any handset, smart or not
  • For utilities and institutions, the phone line is often the official channel of record already

    • Voice is also the harder discipline. A text conversation tolerates a second of latency; a call does not. That constraint pushed us to keep the deterministic core fast, which paid back on every surface.

    The rule that makes it work: one Record

    The non-negotiable in this architecture is that all surfaces write to the same audit trail. A customer who calls in the morning and messages on WhatsApp in the afternoon is one customer with one history, and a compliance officer reviewing an incident sees one sequence of actions regardless of where each step happened.

    The alternative — per-channel logs stitched together after the fact — is how audit gaps happen. We learned to treat the Record as the spine and the channels as limbs.

    A worked example: a utility

    GridWatch, our utilities product, runs customer intake for power outage reports. Consider one incident from the customer's side.

    A resident of a Tema suburb loses power at night. She sends a WhatsApp message: "Light is off at Community 8, since 9pm." The system logs the report, matches it against other reports from the same feeder area — a deterministic correlation, no model involved — and confirms receipt with a reference number. Her neighbor, who does not type, calls instead and says the same thing to the voice surface. Same engine, same incident record; the two reports strengthen the same signal.

    When the utility's operations team restores the feeder, a restoration notice goes out — to the texter by WhatsApp, to the caller by voice callback, because the system answers on the surface each person used. Every report, correlation, and notice sits in one trail the utility can audit later.

    Neither customer knew or cared which "channel strategy" was in play. Each used the surface natural to them and got the same treatment. That is the entire point.

    What this means for you

    If you are evaluating any multi-channel operations platform:

  • Ask where the logic lives. If pricing rules or approval rules are configured per channel, you will maintain them per channel, and they will drift.
  • Ask whether the audit trail is unified. One customer, one history, one log — regardless of surface.
  • Add channels for your customers, not your roadmap. A channel nobody asked for is pure maintenance.

    • Build the engine once, make it accountable once, and let the surfaces multiply. The other order does not work.

    FILED BY — Streemline Team · Product & Engineering

    ✓ ON THE RECORD
    ← ALL FIELD NOTES