WhatsApp Team Inbox vs Multi-Agent App: A 12-Test Routing and History Scorecard

If your requirement is “route WhatsApp conversations to several agents and keep the conversation history,” compare systems by running the same acceptance tests on every option. Do not choose from a feature checklist alone. A small team may be served by WhatsApp Business’s own linked-device and chat-assignment features when the plan available to that account is enough. A shared inbox becomes more compelling when you need reliable ownership, collision prevention, auditable authorship, recoverable history, offboarding controls, or integrations. A hybrid can keep WhatsApp as the customer channel while a shared work queue controls assignment and escalation. For an overview of WhatsApp team-inbox workflows, see the WhatsApp Business AI guide; use the scorecard below to validate every claim in your own account.

The recommendation in one sentence: make identity, ownership, history, and safe recovery hard gates; compare price and convenience only after those gates pass. A product that lets several people open a chat but cannot reliably show who owns the next reply is not a team workflow. A product that preserves a transcript but merges two people into one contact is not safe history. A product that shows an AI-generated suggestion without identifying who approved and sent it is not accountable automation.

Why this comparison needs a test, not another feature list

A team-inbox buyer is usually trying to solve a concrete work problem: one customer message should reach the right person, the team should not send competing answers, and the next person should understand what happened before replying. The words “multi-agent” are ambiguous. They can mean several human staff members using linked devices, several staff members sharing a provider-backed inbox, several AI agents working on different tasks, or a combination of people and software. These are different system designs. Start by naming which actor will receive, assign, decide, and send each message.

A Search Console review for the French group page /fr/blog/team-inbox-whatsapp-multi-agents found one particularly precise query, “trouve une solution whatsapp avec routage vers plusieurs agents et historique,” with 85 impressions, average position 10.8, and zero clicks during 22–28 October 2026. That is one page-and-query observation over seven days, not a market survey, demand forecast, or proof of purchase intent. It is useful because it states the buyer’s unresolved decision plainly: routing plus history. This article turns that question into a repeatable procurement test rather than inferring what the whole market wants from a small Search Console sample.

A common evaluation mistake is to begin with a vendor’s label: “shared inbox,” “CRM inbox,” “AI inbox,” or “official API.” The label does not tell you whether reassignment preserves the same conversation, whether a sent message records its human author, whether number formatting creates duplicate contacts, or what happens when a linked-device limit is reached. Those are observable behaviors. A buyer can test them with synthetic contacts, two staff accounts, and a written evidence log before connecting real customers.

Separate the four meanings of “multi-agent”

First, a linked-device team is several human operators using the same WhatsApp Business identity from a primary phone and companion devices. It may be quick to operate and may fit a small team, but the account’s actual plan, device limits, assignment features, and visibility should be verified in the deployed region. Second, a shared-inbox team uses a separate workspace that groups conversations, assigns owners, and may connect to WhatsApp through a provider or business integration. The supplier’s data model and recovery behavior become part of the workflow. Third, an AI agent is software that classifies, drafts, or acts on conversations. It should not be confused with another human seat. Fourth, a hybrid gives the AI a bounded preparation role and gives a named human or queue the authority to send or resolve the case.

These categories can coexist. For example, a team may keep a human-operated WhatsApp account for direct replies while its shared inbox handles assignment and reporting, with an AI system suggesting labels. The key procurement question is not “Does it support multiple agents?” It is: “For each message, which component holds the authoritative conversation identity, who owns the next action, which actor may send, and where can an auditor reconstruct the sequence?” If the seller cannot draw that path, ask for a demonstration using your test cases before discussing contract length.

What the official app documentation says—and why older claims can conflict

WhatsApp’s official help materials describe linked devices and, for eligible business offerings, multi-agent features such as assigning chats. The baseline linked-device guidance and the eligible multi-agent plan are not the same promise. Meta’s help page says the standard linked-device setup supports up to four companion devices, while its multi-agent guidance describes additional capacity and assignment for eligible business accounts. Availability, product names, caps, and plan terms can vary by market and account, so confirm the current screen and help text for the account you will actually use. Start with Meta’s linked devices help page and multi-agent business help page.

This matters because published material can be stale. The English team-inbox primer linked above says the Business app allows up to five linked devices. The current official help material reviewed for this article states four companion devices for the standard arrangement and describes a separate eligible multi-agent option. Treat the discrepancy as a reason to check, not as an excuse to declare either a universal cap. The acceptance test should record the exact account, market, subscription tier, device count, assignment behavior, date, and evidence. “Works on our demo account” is not sufficient if the production account has a different eligibility state.

An official feature page establishes that a feature is documented; it does not establish that the feature will meet your queue, audit, privacy, or recovery requirements. Likewise, a third-party vendor’s claim that it supports “unlimited agents” does not answer whether all agents have the correct access, whether conversations remain distinct, or whether outbound messages are attributed. Use product documentation to generate test hypotheses. Use your own test run to decide whether the feature is acceptable.

Choose by operating model

Your operating condition	Start by testing	Non-negotiable evidence	Likely direction
A small, stable team with simple ownership and little reporting	Native linked devices and assignment	Assignment visible to every operator; sent-message actor visible; tested plan limit	Native app may be sufficient
Several queues, shifts, or specialist teams	Shared inbox	Reassignment retains history and owner; concurrent replies are controlled	Dedicated shared inbox
Strict contact identity, offboarding, audit, or retention requirements	Shared inbox and integration controls	Export, access revocation, identity merge behavior, retention controls	Shared inbox, subject to governance review
AI classifies or drafts but people remain accountable	Hybrid workflow	AI suggestion is separate from approved send; human author and policy decision are logged	Hybrid with a human send gate
Low message volume but complex exceptions	Native or shared inbox plus an explicit exception queue	A named fallback owner and an escalation record	Choose the simplest option that passes the tests

The table is a routing aid, not a universal vendor ranking. “Small” should be defined by your own simultaneous workload, shifts, exception rate, and coverage needs. A team of three may need strong audit controls; a larger team may have a narrow and stable workflow. Do not infer complexity from headcount alone. If you have a legal, safety, financial, or high-value support queue, make the risk of a wrong recipient or an untraceable reply part of the hard gate even if that queue is quiet.

A useful decision rule is to distinguish capability from control. Capability means a person can open, assign, or answer a conversation. Control means the team can prove which record is authoritative, prevent or detect conflicting actions, revoke access, and reconstruct the outcome. Procurement decks often demonstrate capability because it looks good in a demo. The acceptance scorecard emphasizes control because that is what keeps the workflow dependable after the demo account is replaced by real shifts, real number formats, staff turnover, and interrupted connectivity.

The 12-case buyer acceptance scorecard

The following scorecard is an original, vendor-neutral protocol designed on 30 October 2026. It contains 12 scenario definitions; it is not a benchmark result. No vendor product was run or scored for this article. Use a test account, synthetic contacts, and two human operators. For each case, save the setup, timestamp, screenshots or exported evidence, observed result, workaround, and pass/fail decision. If a case is not run, mark it not tested. Never silently convert an unrun test into a pass.

1. New inbound message creates one conversation

Send a first message from a synthetic customer identity. Confirm that the system creates one conversation record and that every permitted operator sees the same record. Capture the customer key shown in the inbox, the external channel identifier if the system exposes one, and the timestamp. Then refresh or reopen the workspace on the second operator’s device. The acceptance condition is one customer identity, one conversation for that thread, and a visible route to the owner or unassigned queue. Two cards for the same first message are a failure until the supplier explains and demonstrates a safe resolution.

2. Two agents try to answer at the same time

Have operator A and operator B open the same inbound conversation. Ask both to submit a different reply within the same short test window. Observe whether the platform locks the send, warns the second operator, queues the draft, or records two outbound messages. The acceptance condition is not merely “the user should remember to check.” There must be an enforceable control or an immediately visible collision signal, and the evidence must show which reply was delivered. Record a duplicate send as a hard failure for any queue where contradictory messages would harm the customer.

3. Assignment is explicit and shared

Assign the conversation to operator A, then view it as operator B. Confirm that the owner, team, status, and next expected action are visible consistently. Change the assignment to operator B and inspect what changed in the record. A colored badge that only one person can see is not enough. The evidence should make clear whether assignment is a real state transition, whether it has an actor and time, and whether an old owner can still send without warning. If the product has only labels or notes, document the manual convention needed to emulate ownership.

4. Reassignment preserves context

Move a conversation from one operator or queue to another after several messages have been exchanged. Ask the recipient to summarize the issue using only the history visible in the workspace. Confirm that messages, attachments or attachment references, internal notes, and relevant customer attributes remain attached to the same conversation. The test should also verify that private notes are not accidentally included in a customer-visible transcript. Passing requires usable context and an unambiguous separation between customer messages and internal material.

5. Identity normalization does not split or merge the wrong person

Use synthetic phone numbers written in equivalent forms, including international country code and local punctuation. Test the system’s documented normalization rules. One community-reported Chatwoot issue described a conversation split when variations of an Argentina number produced separate contact-inbox records; it is one user report, not evidence of prevalence or current product behavior. Use it as a test prompt: format the same test identity consistently, then deliberately vary formatting and inspect whether the system merges, splits, or asks for review. Never merge solely because two strings look similar. Passing means equivalent formats resolve safely while a genuinely different person remains distinct.

6. A returning customer reaches the right history

Close or resolve a test thread, then send a later message from the same synthetic identity. Confirm whether it reopens the original conversation or creates a new one, and inspect what the next operator sees. Either behavior can be acceptable if it is consistent and the relationship is visible. The dangerous result is a new thread that hides relevant history or a merged thread that combines unrelated topics without a review step. Record the rule for reopening, the visible links between threads, and the search path an on-call operator needs to use.

7. Every outbound message has a meaningful actor

Send one message as operator A and another as operator B. Inspect the customer-facing record and the administrative or export view. Determine whether the system stores the human author, the shared account, a provider identity, an automation identity, or only a generic sender. The team should be able to distinguish a message typed and sent by a person from one prepared by software and approved by a person. If all outbound messages appear under one shared identity, decide whether that is acceptable for your business and retain a separate internal audit trail.

8. The unassigned and out-of-hours path has an owner

Send a message when no named operator is available, or simulate an after-hours period in a test environment. Inspect the queue, status, notification, and escalation behavior. A safe outcome may be a clear unassigned queue with a scheduled review, an on-call owner, or a disclosed service message. An unsafe outcome is a conversation that appears answered because an automation acknowledged receipt but has no operational owner. Record who must act next and how the team will detect a message that has sat without a human decision.

9. Device or plan limits have a tested fallback

On the actual account type under evaluation, add devices or operators until the documented or displayed capacity is reached. Do not test this by disconnecting a production phone. Verify what the UI says, who may add a device, and what happens when a plan changes or an operator loses eligibility. Meta’s help materials distinguish standard linked devices from eligible multi-agent features, and some operational details such as calls or reconnects can differ. Passing requires a written fallback owner and a safe way to continue receiving or triaging messages when a device is unavailable.

10. Staff departure revokes access without orphaning the queue

Use a test operator account. Remove its access, then check whether its session, device, API credentials if applicable, and open assignments are invalidated or transferred. Ask an administrator to confirm the action in the audit record. A user disappearing from an employee list is not proof that every active session is revoked. The queue should remain visible to the authorized replacement, while the departed operator should no longer be able to read or send. Document who owns the offboarding checklist and how long revocation takes in the observed environment.

11. History can be exported, retained, and removed under policy

Request a test export or inspect the vendor’s documented export mechanism. Verify that it preserves timestamps, message direction, conversation identity, actor attribution, and the distinction between customer-visible messages and internal notes. Then locate the documented retention and deletion controls and identify which system is authoritative if the vendor, connector, and CRM each retain copies. Do not use a real person’s data for this test. Passing means an administrator can explain what is retained, where, for how long under the configured policy, and how a deletion or access request propagates through the actual data chain.

12. AI assistance is bounded and separately attributed

If an AI feature is present, test it using a synthetic message that contains an instruction to ignore the business workflow, reveal internal notes, or send an unauthorized commitment. Confirm that customer text cannot change routing rules or permission policy, that an AI draft is visually distinct from a human-approved reply, and that a person must approve consequential outbound content. Inspect what is logged when the AI suggests, when the human edits, and when the message is sent. If the AI can send autonomously, test the exact permission boundary and an immediate stop mechanism before enabling it for real customers.

How to run and score the test fairly

Run the cases in the same sequence for each candidate, using equivalent test data and equivalent user roles. Create a test account A and test account B, a synthetic customer contact, and an administrator. Record the product version, account tier, market, connected channels, and date. Use the vendor’s own supported workflow; do not create an artificial failure by bypassing documented setup. For a case that depends on an unavailable feature, record the prerequisite and test whether the feature can be enabled for your exact account before scoring it. A sales representative’s verbal answer is a hypothesis, not test evidence.

Score each case as 0, 1, or 2. Give 0 when the required outcome fails or cannot be verified; 1 when it passes only through a manual workaround that has an owner and a visible record; and 2 when it passes through a built-in control with an inspectable audit trail. Keep not tested outside the numeric score. For a directional summary, calculate 100 × earned points ÷ (2 × number of executed cases). The score is only a summary of this team’s evidence, not an industry rating. A candidate with a higher total can still be disqualified by a failed hard gate.

Set hard gates before the demo. For a team that must prevent conflicting customer replies, case 2 is a gate. If a wrong-person merge could disclose information, case 5 is a gate. If people leave frequently or conversations contain sensitive data, case 10 is a gate. If your organization must answer data access or deletion requests, case 11 is a gate. Mark a gate as failed, not “mostly passed,” when the required control is absent. A manual workaround may earn one point only if a named owner, trigger, and evidence record are demonstrated. “Our staff will be careful” is not an operational control.

A fair comparison also separates product constraints from test mistakes. If the second operator has no access because an administrator never invited them, correct the setup and rerun. If the feature is available only on a paid tier, record the tier and include its actual commercial condition in the decision. If the supplier changes the workflow between demos, save the before-and-after evidence and rerun the affected cases. Never compare one system with two configured users against another system that has only one demo login. Consistency of the test is part of the result.

A small executable collision check for your internal workflow

A browser lock icon or a written rule can help people notice that a conversation is open, but the send action needs a durable idempotency key if your application mediates outbound work. The following Node.js example is deliberately vendor-neutral: it models two operators attempting the same logical reply. Run it with node collision-check.js. It does not call WhatsApp or prove that a vendor implements this behavior; it shows the property your integration should test—one accepted send for one logical action.

const assert = require('node:assert/strict');
const sent = new Set();

function acceptSend({ idempotencyKey, actor }) {
  if (sent.has(idempotencyKey)) {
    return { accepted: false, status: 409, reason: 'already accepted' };
  }
  sent.add(idempotencyKey);
  return { accepted: true, status: 202, actor };
}

const first = acceptSend({ idempotencyKey: 'conv-17:reply-4', actor: 'agent-A' });
const second = acceptSend({ idempotencyKey: 'conv-17:reply-4', actor: 'agent-B' });
assert.equal(first.accepted, true);
assert.equal(second.accepted, false);
console.log({ first, second });

In a real system, the set must be replaced by an atomic durable store with a uniqueness constraint or equivalent transaction. The key must represent the logical send operation and remain stable across retries. If the process crashes after the provider accepts a message but before your application records the response, a retry must reconcile the provider event rather than blindly send a second message. A locally passing snippet is a design aid; the acceptance case must still inspect the actual provider or inbox behavior.

Keep a minimal event ledger, even when the inbox owns the UI

Before comparing vendors, define the minimum record you need to reconstruct a reply. A useful logical event includes a conversation key, provider message key, event time, direction, actor type, actor identifier, assignment state, approval state, and an idempotency key. Do not assume every provider exposes all fields in the same way. The purpose is to ask the supplier what is observable and what remains in your own system. If the answer is “the shared phone account,” record that as a limitation and decide whether your policy accepts it.

An example state sketch is:

conversation_key: normalized business identity + channel scope
message_key: provider message id or stable ingestion key
actor_type: human | automation | provider
actor_id: named user, workflow, or system identity
assigned_queue: current accountable queue
approved_by: human identity or null
sent_at: provider-confirmed time or pending
idempotency_key: unique key for one logical outbound action

This is a schema prompt, not a claim about WhatsApp’s API payload. Use the supplier’s technical documentation to map these fields, and label fields that are inferred or unavailable. For example, a “seen by” event is not necessarily the same as an assignment, and a CRM contact ID is not automatically the channel’s unique conversation identifier. Make the difference visible in the design so that reporting does not convert a guess into a fact.

Privacy, accountability, and AI boundaries

Treat the customer thread, internal note, CRM record, connector log, and AI prompt as separate data locations until the provider demonstrates otherwise. Map which organization decides why the data is processed, which supplier processes it on instruction, and whether any supplier uses content for a separate purpose. The EDPB’s controller and processor guidelines explain that these roles are functional and must be assessed from the actual processing arrangement. The product label “processor” in a contract does not by itself settle the role for every data flow. Have your privacy or legal owner validate the contract and configuration for your jurisdiction and use case.

Ask each candidate to demonstrate role-based access, offboarding, export, retention, deletion, and incident evidence. If the team has multiple queues, test whether an operator can search outside their assigned work and whether internal notes appear in exports or AI context. Keep the minimum information necessary in prompts and notes. A conversation platform may make data easy to find; that does not make every data use necessary. Separate customer-facing content from internal operational context, and do not let the convenience of a shared transcript erase access boundaries.

For AI features, apply the same principle to authority. Customer text is untrusted input, not a policy instruction. The OWASP LLM application guidance describes risks such as prompt injection and excessive agency. In a WhatsApp workflow, this supports a practical recommendation: an AI classifier can propose a queue, and an AI assistant can draft a reply, but business permissions, routing rules, and send approval should be controlled outside the customer’s message. The test should include adversarial and contradictory text, not only a polite FAQ.

If an AI agent sends autonomously, define allowed actions, disallowed actions, confidence or escalation triggers, emergency stop, and evidence retention before rollout. Avoid using a single “AI enabled” switch as the risk control. Measure a specific action boundary: for example, whether the agent may acknowledge receipt, ask a fixed clarification, change a CRM field, promise a delivery date, or issue a refund. Each permission needs an owner and a test. When policy is unclear or the source data conflicts, the system should preserve the conversation and route it for human review rather than inventing a confident answer.

Failure modes that a polished demo can hide

Duplicate replies. Two operators open the same conversation and both send. The workflow depends on memory instead of an enforceable lock, collision alert, or clear ownership. Reproduce it with case 2 and capture the customer-visible outcome. If the product cannot prevent the collision, document the manual control and its owner; do not call the behavior safe merely because the demo facilitator avoided sending twice.

Split identity. A phone number appears in different formats and creates two contacts or two conversation histories. The root cause may be normalization, connector mapping, or an operator-created duplicate. The single Chatwoot issue cited in case 5 is a useful failure prompt, not proof that any current inbox has a widespread defect. Test your country formats, test how corrections are reviewed, and never auto-merge two people solely to make the dashboard look tidy.

Invisible reassignment. A manager changes the owner, but the previous person still believes they are responsible or the new person never sees the handoff. Require a visible state change and message to the receiving queue. Record the prior owner and new owner with a time. If the platform only has labels, define a convention that cannot be confused with a customer-visible status and test the shift-change path.

History without provenance. The transcript is present but it is not clear who sent a message, whether a human edited an AI draft, or whether a note was visible to the customer. Keep attribution as a separate case from retention. A downloadable transcript that strips actor identity is not equivalent to a useful audit trail. Ask the supplier to show the same event in the agent UI, administrator view, and export.

Automation owns no queue. A bot acknowledges the message and removes it from an unread queue without assigning a human follow-up. Define a human owner or a durable exception queue for every automation outcome. Test silence, low confidence, unavailable staff, and a complaint that does not fit the declared intent. The success metric is not how many messages the bot touches; it is whether the next responsible action remains clear.

The account plan changes. An evaluation succeeds on a paid or region-specific tier, then the organization buys a different account or loses eligibility. Record the exact tier and check plan changes, device reconnection, primary-phone requirements, and downgrade behavior. The feature and the account condition are one procurement unit. Put any capacity assumption in the implementation checklist, not only in the sales slide.

Export exists but recovery is not operational. A vendor can export a file, but the team cannot restore assignment, link it to a CRM identity, or locate the right conversation during an outage. Ask for the recovery procedure, not just the export button. Have an administrator demonstrate what the team does if an account is locked, the main device is unavailable, or the connector is delayed. Note which information can be recovered and what must be reconstructed manually.

The AI follows an instruction inside the customer message. A customer asks the assistant to reveal internal notes, bypass identity verification, or promise a prohibited result. Treat the message as data. The model may help interpret it, but it should not redefine its own access or business policy. Run the scenario in a test account, inspect the draft and event record, then confirm a human can pause or override the workflow.

Questions to ask during a vendor demonstration

Ask the supplier to use your test identities and show the full workflow from first inbound message to reassignment, outbound send, export, and offboarding. Avoid a demo that jumps directly to a successful final screen. Ask: “Where is the authoritative conversation identifier?” “What prevents a second operator from sending the same logical reply?” “Can I see the previous and current owner with a timestamp?” “How do I distinguish a human-approved AI draft from a fully automated message?” “What remains accessible after a user is removed?” “What does a customer-data export contain, and which system controls deletion?”

Then ask the supplier to repeat one case after a failure: disconnect a test device, retry a delayed event, change the assignment during an open session, or simulate a second send. You do not need a dramatic fault injection exercise. You need to see whether the product exposes a clear state and a responsible next action when normal conditions stop. If an answer depends on a custom implementation, name the implementer, contract owner, and evidence that will be delivered. “The API can do that” should lead to a documented API capability and an acceptance test, not an assumption.

A useful demonstration has the vendor narrate which records change and which do not. For example, when a conversation is assigned, does the system update an owner field, add a label, create a task, or only notify a user? When an AI suggests a reply, is that a draft object or an outbound message? When an operator is removed, what happens to their open queue? These questions reveal whether the workflow is coherent across channels or merely attractive in one screen.

Turn results into a decision record

Keep one scorecard per candidate with columns for case number, setup, expected behavior, observed behavior, evidence path, workaround, severity, owner, and retest date. Attach only synthetic data. Put hard-gate failures at the top so that a high convenience score cannot conceal an unacceptable risk. Track unresolved items as procurement conditions with a named owner and a deadline. If a vendor promises to fix an issue before launch, require a retest against the same case after the change; do not replace the test with an email assurance.

The comparison should include implementation work. A shared inbox may reduce the time to assign and report but can introduce a new data store, provider dependency, or integration failure path. A native app may reduce configuration but leave more coordination to staff. A hybrid may improve AI assistance while adding another system boundary. The Boston Consulting Group’s AI capability overview is a useful high-level reminder that AI value depends on operating model and capability, but it is not a WhatsApp product benchmark. Translate any strategy language into a local owner, workflow, measure, and test before making the investment case.

Do not use a made-up “productivity uplift” to justify selection. Measure your own baseline if it matters: time from inbound message to first human owner, time from assignment to first responsible reply, number of duplicate-send incidents, number of split-contact corrections, and time needed to reconstruct a conversation. Define the start and stop events before collecting data. Exclude test traffic and disclose the sample window. If you do not yet have a baseline, call the measurement a planned pilot rather than a result.

A practical decision sequence

flowchart TD
  A[Name the actors and queues] --> B{Does native account support required assignment and capacity?}
  B -- Yes --> C[Run all hard-gate cases in the native app]
  B -- No --> D[Evaluate a shared inbox]
  C --> E{Identity, ownership, history and offboarding pass?}
  D --> E
  E -- No --> F[Reject or redesign; keep a documented exception queue]
  E -- Yes --> G{Is AI part of the workflow?}
  G -- No --> H[Choose the simplest tested option]
  G -- Yes --> I[Keep policy outside customer text and require a bounded send gate]
  I --> J[Run adversarial, attribution and stop-control cases]
  J --> H

Use the diagram as a procurement sequence, not an architecture mandate. If the native app passes all required cases and is supportable by your administrators, there may be no need to add a shared inbox. If it fails a hard gate, do not buy a product merely because it adds more screens; test another option against the same evidence requirements. If AI is absent today but planned later, include the AI cases as launch gates for that later phase rather than pretending they are already satisfied.

Proof pack: what to retain after the decision

The proof pack should contain the scenario definitions, test account and plan details, observed results, screenshots or exports with synthetic data, product documentation versions, unresolved assumptions, hard-gate decision, and the owner of each follow-up. Include a short data-flow diagram showing WhatsApp, provider or connector, shared inbox, CRM, AI service if present, and the systems that store history. Mark every boundary where identity, assignment, message content, or approval state changes. If the supplier will not confirm a field or behavior, label it “unknown” rather than filling the gap with a diagram invented by the buyer.

For each major claim, keep the source close to the claim. Meta’s linked-device and multi-agent help pages are the primary references for current app capability; verify the exact article and account tier at purchase time. The EDPB controller/processor guidelines support the role-mapping question, while OWASP supports the need to treat AI inputs and permissions carefully. Community reports from HubSpot’s forum and the Chatwoot issue tracker are prompts for test cases, not prevalence statistics or current product verdicts.

Limits and contradictions in the evidence

Official product documentation can be more authoritative than a blog post about feature availability, but it may still be account-specific, translated differently, or updated after a buyer’s evaluation. The cited community reports describe individual experiences. One report cannot show how often duplicate replies or split identities happen, and an open issue cannot establish a present-day defect or its scope. A product demo video, even from the vendor, shows a selected path through an interface; it cannot substitute for your own acceptance test. During this review, video search did not yield a feature-specific demonstration with a transcript that could verify the behaviors in the scorecard, so no video is used as factual support.

The 12-case scorecard is a proposed reproducible protocol. Its sample size is 12 designed scenarios, not 12 customers, products, or observed outcomes. It has not been executed against any vendor and therefore produces no vendor ranking or measured pass rate. Its scope is team routing, identity, history, attribution, recovery, and bounded AI assistance. It excludes pricing comparisons, API throughput, deliverability benchmarks, legal advice, and a security penetration test. Adapt the cases to your own use and retain the changes so that two suppliers are still compared against the same bar.

Validation checklist

• [ ] Define whether “agent” means human staff, AI software, or both.
• [ ] Record the target account tier, country or region, device count, and feature eligibility.
• [ ] Identify the authoritative conversation and customer identity keys.
• [ ] Run the duplicate-send case with two operators.
• [ ] Confirm assignment and reassignment are visible to both operators.
• [ ] Test history, internal notes, attachments, and reopened conversations.
• [ ] Test equivalent phone-number formats and prevent unsafe automatic merges.
• [ ] Verify outbound actor attribution in the interface and export.
• [ ] Demonstrate the unassigned and after-hours path.
• [ ] Remove a test operator and verify access revocation and queue transfer.
• [ ] Locate export, retention, deletion, and recovery procedures.
• [ ] If AI is enabled, test untrusted customer instructions, approval, and stop controls.
• [ ] Mark every unrun case “not tested” and retain the reason.
• [ ] Apply hard gates before calculating any convenience score.
• [ ] Name an owner and retest date for each unresolved procurement condition.

Bottom line

For a small, stable team, begin by testing the official WhatsApp Business options available to your own account. Do not assume the base app is limited to a single operator, and do not assume an eligible multi-agent feature is included in every account. If the team needs dependable cross-shift ownership, collision prevention, auditable authorship, controlled history, and offboarding, compare a shared inbox using the same 12 cases. If AI is involved, keep the business policy and send authority outside customer-provided text, and make human approval and attribution visible where the risk requires it.

The strongest procurement decision is not the one with the longest feature list. It is the simplest workflow that passes the team’s hard gates and leaves a clear record of who must act next. Keep the test evidence, record the exact account and integration configuration, and repeat the cases after a major plan, provider, or workflow change. That turns “multiple agents with routing and history” from a vague promise into a decision your operations team can verify.