How oversight of a company-owned WhatsApp number works.

What a manager sees once a number is linked

Oversight here means a management view, not a shared inbox. Every linked company number sits in one dashboard, searchable from any desk: who replied and how fast, every customer still waiting and for how long, reply SLAs met or missed by rep, and every call in and out, logged and never recorded.

The archive keeps what the phone loses. A message deleted after it was captured is kept with the time it was sent and the time it was removed, and a chat cleared before a departing rep hands the phone back is still there when the number goes to the next rep. Nothing is ever sent from a linked number: managers read, and reps keep replying from their phones.

Company-owned numbers only, and visible to your team

WAOversight links company-owned WhatsApp Business numbers and nothing else. A rep's personal WhatsApp is a separate account on a separate number: it is not linked, not visible and not touched, and no setting changes that. If a rep sells from a personal number today, the fix is a company number, and the guide to company-owned WhatsApp numbers covers how to set one up.

The oversight is visible from both sides. The link is listed on the company phone under Linked devices for as long as it exists, and your team should be told in writing which numbers are covered before one is linked. Every manager view, search and export is written to an access log nobody can edit or switch off.

What happens to a message after it arrives

Every event WhatsApp hands us is durably committed to an append-only event log before it is acknowledged. Nothing downstream sees a message until that write has returned. It is the ordering that matters: acknowledge first and you have promised to keep something you have not yet written down, and the window between the two is exactly where messages go missing.

Everything after the log is a consumer with its own cursor: the conversation view, the metrics, the media downloader. Each tracks its own position independently, so one falling over does not stall the others, and a consumer that dies mid-batch resumes from its last committed offset rather than from wherever it happened to be in memory. Recovery is replay, not reconstruction.

One writer per number, enforced rather than assumed

A linked number is held by exactly one process at a time. That is enforced with an advisory lock in the database and a fencing token carried on every write: a process that loses the lock and does not yet know it finds its writes rejected by the database, because the token it is carrying is stale. Two processes each believing they own the same session is how an archive ends up with duplicates and gaps simultaneously, and convention is not a defence against it.

Delivered at least once, recorded exactly once

Any capture pipeline worth trusting will deliver some events more than once, and that is the correct failure mode, because the alternative is losing them. Turning at-least-once delivery into exactly-once recording takes two independent mechanisms: a short-lived idempotency guard that rejects a message id already seen on that number, and a uniqueness constraint in the database that would reject the duplicate anyway if the guard were unavailable. Belt and braces on purpose. "Exactly once" asserted through a single mechanism is a claim about a happy path, not a property of a system.

Immutable by construction, not by policy

The archive accepts inserts and nothing else. Original message text and send time cannot be updated after they are written; the database refuses, not the application. A deletion or an edit arrives as a new event plus a flag; it never rewrites what was already recorded.

Records on a number are additionally chained: each commits to a hash of the one before it, so the sequence is tamper-evident. Removing or altering a record breaks the chain at that point, and the break is detectable by recomputing it, which you can do yourself, without trusting us. Chain heads are periodically anchored to write-once storage, so a compromise of the primary database cannot quietly rewrite history behind you.

Attachments are captured, not linked

Media is fetched eagerly, on arrival, into your own object storage under a per-tenant encryption key, with object lock applied. The key needed to decrypt what WhatsApp sent exists at rest only while the transfer is still in flight, and is destroyed the moment the object is verified in storage.

The alternative, resolving a link to WhatsApp's servers at the moment you click it, is the common design, and it is not an archive. An attachment you can only see for as long as somebody else chooses to host it is a bookmark.

Nora reads the archive, never the phone

On every plan, Nora, the AI that watches your queue, reads your customers' threads, puts what needs a manager at the top of the queue and closes what is handled, each item quoting its message. Nora reads from the archive after a message is captured, and cannot send from a linked number. How Nora works.

What your reps have to do

Hand over the company phone for a minute, and scan the code again on the rare occasion a session drops. That is the entire list. There is no app, no profile to install, no number change, and no difference in how they use WhatsApp afterwards.

They should also read the page we wrote for them before you roll this out. Rollouts that skip that step are the ones that turn into an argument.