WhatsApp Team Inbox vs Multi-Agent App: A 12-Test Routing and History Scorecard
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.
We built four chats. Obviously, that was the sensible thing to do.
---
title: "We built four chats. Obviously, that was the sensible thing to do."
description: "How a tiny hotel FAQ chat multiplied into four parallel chat implementations—and how we finally made them share a component."
tags: webdev, javascript, architecture, ai
canonical_url: chat.fodylabs.com
cover_image: chat.fodylabs.com
published: true
---
Whenever a developer runs into a problem, the first question is not always “How do we solve it?” Often it is “What are we going to solve it with?” Build it ourselves, or use something already built? Open source, or a hosted service?
Today, if you have AI, the answer seems obvious:
“Build it ourselves! Ourselves, ourselves!”
And why not? Why drag home some old, heavy, slow contraption, built twenty years ago—practically in the age of mammoths—when AI can produce a shiny new one before lunch?
We had that choice in front of us. In retrospect, this is the comparison we should have made before enthusiastically opening the editor:
| Option | What it brings | Public price (USD) | The small print / “weight” |
|---|---|---|---|
| Build it ourselves | Exactly the hotel FAQ flow we wanted; no inbox or support suite we did not need | No vendor fee; developer time sold separately (apparently) | Every bug, integration, update and future feature comes home with you |
| Chatwoot | Open-source, self-hostable live chat and shared inbox; API and webhooks; optional AI features | Community self-hosted edition: $0 for the software. Cloud plans start free; paid plans are per agent | “Free” still needs Linux, PostgreSQL, Redis, and a production server. For production, Chatwoot recommends at least 4 GB RAM and 2 CPU cores. |
| tawk.to | Hosted live chat, ticketing and knowledge base; AI Assist available | Widget: $0. Remove branding: $29/month. AI Assist: from $29/month | A very persuasive “why build this?” price. You still need to check which extras and workflows your use case requires. |
| Crisp | Hosted chat and shared inbox; higher tiers add workflows, ticketing and AI tools | Free: $0 (2 seats); Mini: $45/month per workspace; Essentials: $95; Plus: $295 | Workspace pricing, not per agent. The amount buys a broader support platform, not just a chat bubble. |
| Intercom | Messenger, shared inbox, help center, automation and Fin AI agent that can take actions on external systems | Essential: $29/seat/month; Advanced: $85; Expert: $132, plus $0.99 per Fin outcome | Seat cost plus AI outcomes. Excellent if you need that customer-service platform; a lot to adopt just to answer “Does the room include breakfast?” |
This is a snapshot of public prices and product descriptions checked on October 16, 2026, not a universal benchmark. Plans, billing terms and included quotas change; the linked vendor pages are the source of truth. Chatwoot's Community code is MIT-licensed; its self-hosting guide documents the server requirements.
And before anyone asks: no, this is not a bundle-size comparison. These vendors do not publish directly comparable widget JavaScript sizes on the cited pages. “Heavy” can mean downloaded bytes, a dashboard with a small city inside it, an invoice, or the operational burden of keeping Postgres and Redis happy. We did not measure all those things, so we will not invent a kilobyte column to make the table look more scientific.
One thing we can measure, though: the embeddable widget script that ends up running on a hotel’s or a taxi company’s website is plain JavaScript, with zero npm packages pulled into the visitor’s browser. Not “minified to feel light”—there is simply no dependency tree to minify. We cannot audit anyone else’s supply chain, so we will not claim the competition is insecure. We can say that our widget has no third-party code to go wrong, which is a smaller, quieter kind of security than a vendor’s compliance page, but a security property all the same.
Also, we did not actually complete this spreadsheet before building. We had a small, concrete need and wanted a small, concrete widget. The spreadsheet is the responsible version of the story; the real version is that we started coding and only later noticed the pattern.
The small problem that started it
We had a problem with our hotel websites: tourists were having to navigate them.
They wanted to know the price, what was included, whether there was a transfer. The answers were on the site, of course. Somewhere. Usually behind a menu, a page, and a small but meaningful test of one's determination.
We did not want to bring in a large, opinionated component just to answer “How much is the room?” So we made a little chat for our quick hotel sites. Put it on the page, give it the basic information, let the tourist ask in ordinary language. No grand strategy. No platform roadmap. Just fewer clicks between a question and an answer.
This is how many grand strategies begin: by insisting there is no grand strategy.
Meanwhile, in three other parts of the codebase…
We were also building a taxi service. Passengers needed a way to talk to drivers.
We were building a financial application. Customers needed support.
And we were still building hotel sites, where that first little chat seemed like a pretty good idea.
These projects did not politely line up and wait for one another to finish. They were happening in parallel. Which is a productive way to work, right up until you look around and discover that you are developing four chats at once.
Four chats. Each one better than the other three. Naturally.
That sentence should make an engineer reach for the fire alarm. We did not have one handy, so we reached for the architecture.
The usual copy-paste strategy was working perfectly
By “perfectly,” we mean every chat was improving—and none of them was improving in quite the same way.
One had picked up a useful interaction. Another had better handling for its particular workflow. A third had learned something about support. Fix a small thing in one, and the other three remained serenely unaware. They were not broken; they were simply becoming four separate answers to the same question.
Copying fixes between them was possible. So is maintaining four calendars by sending yourself increasingly stern emails. Possible is not the same as a plan.
The important realization was that the products did not need the same behavior. They needed the same chat component—with a way for each host application to supply its own behavior.
One chat, not one-size-fits-all
We pulled the shared parts behind one embeddable interface. The host application still owns its data, business rules and decisions. The chat provides the conversation surface and can be configured to fit the job.
For a hotel site, the starting point is deliberately boring:
<script src="https://chat.fodylabs.com/chat-engine.js" defer></script>
<script>
window.addEventListener('load', function () {
ChatEngine.mount({
endpoint: 'https://chat.fodylabs.com/api/chat',
historyEndpoint: 'https://chat.fodylabs.com/api/history',
title: 'Ask us anything',
payload: { project: 'YOUR_PROJECT_ID', key: 'pub_YOUR_PUBLIC_KEY' }
});
});
</script>
Those two placeholders are the project's identifiers, not magic credentials you have to invent. In the FodyChat dashboard, create a project, add its FAQ or other knowledge, and copy the generated embed snippet. It supplies the project's ID and its pub_… public key. The ID tells FodyChat which project's settings and knowledge to use; the public key identifies that project when the widget calls the API. It is meant to appear in the page source, so it is not a password or secret. The project also needs to allow your website's origin.
“Boring” is a compliment here. Add the business's FAQ or basic information, and a visitor can ask a question without taking the scenic route through the navigation.
If the FAQ grows into a library, the same chat can use retrieval over a larger knowledge base. If the application has live data, it can call the application's API. If the application needs to perform an action, the host can explicitly allow that action and handle it itself.
The chat can grow up. It does not have to arrive wearing enterprise architecture on day one.
A conversation is not a transaction
The taxi application taught us to be particularly careful about the difference between “the chat said so” and “the system did so.”
A passenger can ask for an excursion, give a date and time, and say how many people are coming. That is a useful draft. It is not a booking. It does not mean the order was submitted, and it definitely does not mean a driver has accepted it.
The assistant can help prepare the details. In our current flow, Taxi owns the booking form, validation, confirmation and actual order status. We chose that boundary; developers could authorize a different flow to submit the order. A driver is assigned because the dispatch system says so—not because a language model has become optimistic.
The same boundary matters in financial support. A chat can help someone find information or navigate a workflow. The application still decides who is signed in, what they are allowed to do, and whether any operation actually happened.
In other words: the assistant may be helpful, but it does not get promoted to database.
Some useful problems were smaller than “build a chat,” but solving them well made the experience much better. A taxi passenger can dictate where they need to go instead of typing an address. The chat finds the place, shows it on an in-chat map, and passes the selected point into Taxi's booking form, where the passenger can review and confirm the order.
Dictation also lets visitors speak instead of type, with the transcript placed in the message box for review before sending. And when a conversation reaches a human operator, messages are translated in both directions. Operators on Telegram or Slack can reply with a voice note; it is transcribed and translated into the guest's language like a typed response.
And sometimes a chat is just a chat
Once the chat and AI were connected to the same useful information, we could reuse that work in more than one place. For almost no additional infrastructure, a business can let visitors ask questions naturally instead of navigating the site—and use its well-structured knowledge as a practical starting point for generative engine optimization (GEO).
There is an important distinction: an embedded chat does not automatically make a site visible to external AI search engines. It does not rewrite the site's pages or robots.txt, and it cannot promise that another AI will crawl or cite the business. We explain what this GEO foundation does—and does not—mean in the public integration guide.
Where the job calls for AI clients to query live data directly, we can expose the relevant API through tools or MCP. We did that for Radioller's live station catalog. It is a specific integration, not a button that turns every chat into a universal MCP server.
Looking a little further ahead, perhaps an AI will pick up our plans over morning coffee—or catch a half-formed thought—and order a taxi without a chat or a website anywhere in sight. That future may be a year or two away. Let's give it a little time.
Until then, explore FodyChat and try the playground.
1 reaction
Mentions
Vous connaissez Crisp ou Intercom ? Il existe un équivalent open source et auto-hébergeable, codé en Ruby on Rails : Chatwoot. J'y ai branché Mistral en Agent Bot 😛. Testé et approuvé ! chatwoot/chatwoot chatwoot.help
4/ Chatwoot: WhatsApp, Instagram e e-mail numa caixa só, pra equipe toda. chatwoot/chatwoot
WhatsApp Team Inbox vs Multi-Agent App: A 12-Test Routing and History Scorecard 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.
9 'Free' AI & Dev Repos: Only 5 Are Actually Free A viral reel lists nine 'free' GitHub repos that replace paid software and implies you'll save hundreds a month. All nine are real, but 'free' needs an asterisk, so here's the honest sort (stars and prices at time of filming). Genuinely free and self-hosted: Cap (replaces Loom), Chatwoot (Intercom), OpenProject (Asana, Community Edition), OpenWhispr (Wispr Flow), and VoiceStudio (ElevenLabs-style voice cloning that runs locally). Download, run, done. Free app, but you still pay someone: OpenSEO replaces the Semrush subscription but needs a paid DataForSEO API key (pay-as-you-go, $50 minimum top-up), so you pay per lookup; and open-higgsfield is a free UI that calls Higgsfield's own API and spends credits on your paid Higgsfield account. Read the licence first: the fully-free Calendly self-host is the Cal.diy fork, whose README says personal, non-production use only (commercial Cal.com is open-core); and WeKnora is a local document-Q&A (RAG) tool that can read your Notion, not a Notion-workspace replacement. And every one means you run the server, updates, backups and security yourself. The reel's on-screen savings total only counts five of the nine tools and doesn't even add up, so treat savings as 'could', not 'will'. Still, five solid freebies is a genuinely good haul. Sources (checked 22 Oct 2026): Cap (replaces Loom): CapSoftware/Cap Chatwoot (Intercom): chatwoot/chatwoot OpenProject (Asana): opf/openproject OpenWhispr (Wispr Flow): OpenWhispr/openwhispr VoiceStudio (ElevenLabs): debpalash/VoiceStudio OpenSEO (Semrush): every-app/open-seo open-higgsfield (Higgsfield): wide-trace/open-higgsfield WeKnora (RAG / reads Notion): Tencent/WeKnora Cal.diy (Calendly, MIT self-host): calcom/cal.diy Which of the five would you self-host? Independent channel. Not sponsored. Retold in our own words and visuals. #AI #OpenSource #SelfHosted #shorts Made with AI-generated visuals and voice.
Chatwoot: The modern customer support platform, an open-source alternative to Intercom, Zendesk, Salesforce Service Cloud etc. (38k stars) What it does All text below is quoted directly from the project README. >Open-source live-chat, email support, omni-channel desk. An alternative to Intercom, Zendesk, Salesforce Service Cloud etc. Collaboration & Productivity: - Private Notes and @mentions for internal team discussions. - Labels to organize and categorize conversations. - Keyboard Shortcuts and a Command Bar for quick navigation. - Canned Responses to reply faster to frequently asked questions. - Auto-Assignment to route conversations based on agent availability. - Multi-lingual Support to serve customers in multiple languages. - Business Hours and Auto-Responders to manage response expectations. - Agent Capacity Management to balance workload across the team. >Chatwoot centralizes all customer conversations into one powerful inbox, no matter where your customers reach out from. It supports live chat on your website, email, Facebook, Instagram, Twitter, WhatsApp, Telegram, Line, SMS etc. Repository chatwoot/chatwoot Repository stats |Metric|Value| |:-|:-| |Stars|38,358| |Forks|9.3k| |Last release|v4.19.1 (2026-10-24)| |Languages|Ruby 51.3%, Vue 24.6%, JavaScript 21.7%| |Contributors|411| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|@claude (61 commits), @Copilot (28 commits), @cursoragent (3 commits)| |AI co-authored commits|Claude: 61, Cursor: 3, Copilot: 31| Main contributor |Field|Value| |:-|:-| |Name|Pranav| |GitHub|@pranavrajs| |Commits to this repo|1,407 (top contributor)| |Bio|Building @chatwoot.| |Company / Location|San Francisco | Kerala| |X / Twitter|@pranavrajs| |Followers|512| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.
9 open source Alternatives: Free Code Is Not Free Everything #shorts Nine open-source alternatives, with the catches that subscription-replacement videos often skip: API usage, hosting, hardware and commercial license terms. This is a source-checked overview, not a claim that every tool is installed or that you will save a fixed amount. Original pixel-art Wyatt animation, original script and locally generated transition sounds. AI-generated Kore narration. No reference footage, sprite, creator likeness, music or cloned voice used. YouTube altered/synthetic-content disclosure: Yes. Checked27October2026. Project terms may change. Local models and third-party dependencies can have their own licenses. Cal.diy is currently marked for personal, non-production use. OpenSEO's real DataForSEO data is paid usage after limited trial credit. OpenHiggsfield requires a platform key; it is not verified unlimited free generation. Cap's distributed desktop app pricing charges for commercial rights; this is distinct from its source-code license. No affiliation or endorsement. SOURCES OpenWhispr: openwhispr/openwhispr VoiceStudio: debpalash/VoiceStudio VoiceStudio terms/editions: voicestudio.sh WeKnora: Tencent/WeKnora OpenProject: opf/openproject Community Edition: openproject.org Chatwoot: chatwoot/chatwoot Cal community repo: calcom/cal.com OpenHiggsfield: wide-trace/open-higgsfield OpenSEO: every-app/open-seo DataForSEO: dataforseo.com Cap: CapSoftware/Cap Cap pricing: cap.so [de-DE] 9 Open-Source-Alternativen: Freier Code ist nicht kostenlos #shorts Neun Open-Source-Alternativen, die die Haken aufzeigen, die Videos zu Abo-Alternativen oft auslassen: API-Nutzung, Hosting, Hardware und kommerzielle Lizenzbedingungen. Dies ist eine geprüfte Übersicht, keine Garantie für die Installation aller Tools oder eine feste Ersparnis. Originale Pixel-Art-Animation von Wyatt, Originalskript und lokal generierte Übergangssounds. KI-generierte Kore-Erzählung. Es wurden keine Referenzaufnahmen, Sprites, Abbildungen der Urheber, Musik oder geklonte Stimmen verwendet. Offenlegung veränderter/synthetischer Inhalte von YouTube: Ja. Geprüft am 27. Oktober 2026. Die Projektbedingungen können sich ändern. Lokale Modelle und Abhängigkeiten von Drittanbietern können eigene Lizenzen haben. Cal.diy ist derzeit für den privaten, nicht-kommerziellen Gebrauch gekennzeichnet. Die echten DataForSEO-Daten von OpenSEO sind nach einer begrenzten Testphase kostenpflichtig. OpenHiggsfield benötigt einen Plattformschlüssel; die unbegrenzte kostenlose Generierung ist nicht garantiert. Die Preise für die Desktop-App von Cap beinhalten die kommerziellen Nutzungsrechte; diese sind von der Quellcode-Lizenz zu unterscheiden. Keine Verbindung oder Empfehlung. QUELLEN OpenWhispr: openwhispr/openwhispr VoiceStudio: debpalash/VoiceStudio VoiceStudio Nutzungsbedingungen/Editionen: voicestudio.sh WeKnora: Tencent/WeKnora OpenProject: opf/openproject Community Edition: openproject.org Chatwoot: chatwoot/chatwoot Cal Community-Repository: calcom/cal.com OpenHiggsfield: wide-trace/open-higgsfield OpenSEO: every-app/open-seo DataForSEO: dataforseo.com Cap: CapSoftware/Cap Preisinformationen: cap.so [es-US] 9 alternativas de código abierto: Código gratis no significa gratis para todo #shorts Nueve alternativas de código abierto, con los detalles que suelen omitir los vídeos que reemplazan las suscripciones: uso de la API, alojamiento, hardware y términos de la licencia comercial. Esta es una descripción general verificada, no una garantía de que todas las herramientas estén instaladas ni de que se obtenga un ahorro fijo. Animación original de Wyatt en pixel art, guion original y sonidos de transición generados localmente. Narración de Kore generada por IA. No se utilizaron imágenes de referencia, sprites, imágenes del creador, música ni voces clonadas. Aviso de YouTube sobre contenido alterado/sintético: Sí. Verificado el 27 de octubre de 2026. Los términos del proyecto pueden cambiar. Los modelos locales y las dependencias de terceros pueden tener sus propias licencias. Cal.diy está marcado actualmente para uso personal, no comercial. Los datos reales de DataForSEO de OpenSEO son de pago tras un período de prueba limitado. OpenHiggsfield requiere una clave de plataforma; no se garantiza la generación gratuita ilimitada. El precio de la aplicación de escritorio distribuida de Cap cobra por los derechos comerciales; esto es independiente de su licencia de código fuente. Sin afiliación ni respaldo. FUENTES OpenWhispr: openwhispr/openwhispr VoiceStudio: debpalash/VoiceStudio Términos y condiciones de VoiceStudio: voicestudio.sh WeKnora: Tencent/WeKnora OpenProject: opf/openproject Edición Comunitaria: openproject.org Chatwoot: chatwoot/chatwoot Repositorio comunitario de Cal: calcom/cal.com OpenHiggsfield: wide-trace/open-higgsfield OpenSEO: every-app/open-seo DataForSEO: dataforseo.com Cap: CapSoftware/Cap Precios de Cap: cap.so [fr-FR] 9 alternatives open source : le code gratuit n'est pas gratuit partout #shorts Neuf alternatives open source, avec les points importants souvent omis dans les vidéos de remplacement d'abonnements : utilisation de l'API, hébergement, matériel et conditions de licence commerciale. Il s'agit d'un aperçu vérifié du code source, et non d'une garantie d'installation de tous les outils ou d'économies fixes. Animation originale en pixel art de Wyatt, script original et sons de transition générés localement. Narration Kore générée par IA. Aucune image de référence, aucun sprite, aucune image du créateur, aucune musique ni voix clonée n'ont été utilisés. Divulgation du contenu modifié/synthétique sur YouTube : Oui. Vérifié le 27 octobre 2026. Les conditions du projet peuvent changer. Les modèles locaux et les dépendances tierces peuvent avoir leurs propres licences. Cal.diy est actuellement indiqué pour un usage personnel et non commercial. L'utilisation des données réelles DataForSEO d'OpenSEO est payante après une période d'essai limitée. OpenHiggsfield nécessite une clé de plateforme ; la génération gratuite illimitée n'est pas vérifiée. L'application de bureau distribuée de Cap facture les droits commerciaux ; cela est distinct de sa licence de code source. Aucune affiliation ni approbation. SOURCES OpenWhispr : openwhispr/openwhispr VoiceStudio : debpalash/VoiceStudio Conditions d’utilisation et éditions de VoiceStudio : voicestudio.sh WeKnora : Tencent/WeKnora OpenProject : opf/openproject Édition communautaire : openproject.org Chatwoot : chatwoot/chatwoot Dépôt communautaire de Cal : calcom/cal.com OpenHiggsfield : wide-trace/open-higgsfield OpenSEO : every-app/open-seo DataForSEO : dataforseo.com Cap : CapSoftware/Cap Tarifs : cap.so [hi] 9 ओपन सोर्स विकल्प: फ्री कोड का मतलब सब कुछ मुफ्त नहीं #shorts नौ ओपन-सोर्स विकल्प, जिनमें वे सभी शर्तें शामिल हैं जिन्हें अक्सर सब्सक्रिप्शन-रिप्लेसमेंट वीडियो अनदेखा कर देते हैं: API उपयोग, होस्टिंग, हार्डवेयर और वाणिज्यिक लाइसेंस की शर्तें। यह स्रोत-जांच पर आधारित एक विस्तृत अवलोकन है, यह दावा नहीं है कि हर टूल इंस्टॉल किया गया है या आप एक निश्चित राशि बचा लेंगे। मूल पिक्सेल-आर्ट वायट एनिमेशन, मूल स्क्रिप्ट और स्थानीय रूप से उत्पन्न ट्रांज़िशन साउंड। AI-जनरेटेड कोर नैरेटर। कोई संदर्भ फुटेज, स्प्राइट, निर्माता की छवि, संगीत या क्लोन की गई आवाज का उपयोग नहीं किया गया है। YouTube द्वारा परिवर्तित/सिंथेटिक सामग्री का खुलासा: हाँ। 27 अक्टूबर 2026 को जांचा गया। प्रोजेक्ट की शर्तें बदल सकती हैं। स्थानीय मॉडल और तृतीय-पक्ष निर्भरताओं के अपने लाइसेंस हो सकते हैं। Cal.diy वर्तमान में व्यक्तिगत, गैर-उत्पादन उपयोग के लिए चिह्नित है। OpenSEO का वास्तविक DataForSEO डेटा सीमित परीक्षण क्रेडिट के बाद सशुल्क उपयोग के लिए उपलब्ध है। OpenHiggsfield के लिए एक प्लेटफ़ॉर्म कुंजी की आवश्यकता होती है; यह असीमित निःशुल्क उत्पादन के लिए सत्यापित नहीं है। Cap के वितरित डेस्कटॉप ऐप मूल्य निर्धारण में वाणिज्यिक अधिकारों के लिए शुल्क लिया जाता है; यह इसके स्रोत-कोड लाइसेंस से अलग है। कोई संबद्धता या समर्थन नहीं। स्रोत OpenWhispr: openwhispr/openwhispr VoiceStudio: debpalash/VoiceStudio VoiceStudio नियम और शर्तें/संस्करण: voicestudio.sh WeKnora: Tencent/WeKnora OpenProject: opf/openproject कम्युनिटी एडिशन: openproject.org Chatwoot: chatwoot/chatwoot Cal कम्युनिटी रेपो: calcom/cal.com OpenHiggsfield: wide-trace/open-higgsfield OpenSEO: every-app/open-seo DataForSEO: dataforseo.com कैप: CapSoftware/Cap कैप प्राइसिंग: cap.so [id] 9 Alternatif Open Source: Kode Gratis Tidak Berarti Gratis Segalanya #shorts Sembilan alternatif sumber terbuka, dengan catatan yang sering diabaikan oleh video pengganti berlangganan: penggunaan API, hosting, perangkat keras, dan ketentuan lisensi komersial. Ini adalah tinjauan yang telah diperiksa sumbernya, bukan klaim bahwa setiap alat telah diinstal atau bahwa Anda akan menghemat sejumlah uang tertentu. Animasi Wyatt pixel-art asli, skrip asli, dan suara transisi yang dihasilkan secara lokal. Narasi Kore yang dihasilkan AI. Tidak ada cuplikan referensi, sprite, kemiripan kreator, musik, atau suara kloning yang digunakan. Pengungkapan konten yang diubah/sintetis YouTube: Ya. Diperiksa 27 Oktober 2026. Ketentuan proyek dapat berubah. Model lokal dan dependensi pihak ketiga dapat memiliki lisensi sendiri. Cal.diy saat ini ditandai untuk penggunaan pribadi, bukan produksi. Data DataForSEO asli dari OpenSEO berbayar setelah kredit uji coba terbatas. OpenHiggsfield memerlukan kunci platform; ini tidak diverifikasi sebagai generasi gratis tanpa batas. Harga aplikasi desktop terdistribusi Cap mengenakan biaya untuk hak komersial; ini berbeda dari lisensi kode sumbernya. Tidak ada afiliasi atau dukungan. SUMBER OpenWhispr: openwhispr/openwhispr VoiceStudio: debpalash/VoiceStudio Ketentuan/Edisi VoiceStudio: voicestudio.sh WeKnora: Tencent/WeKnora OpenProject: opf/openproject Edisi Komunitas: openproject.org Chatwoot: chatwoot/chatwoot Repositori komunitas Cal: calcom/cal.com OpenHiggsfield: wide-trace/open-higgsfield OpenSEO: every-app/open-seo DataForSEO: dataforseo.com Cap: CapSoftware/Cap Harga Cap: cap.so [it] 9 alternative open source: il codice libero non è gratuito in tutto #shorts Nove alternative open-source, con tutti i dettagli che i video che promettono di sostituire gli abbonamenti spesso omettono: utilizzo delle API, hosting, hardware e termini di licenza commerciale. Questa è una panoramica verificata a partire dalle fonti, non una garanzia che ogni strumento sia installato o che si possa risparmiare una somma fissa. Animazione originale in pixel art di Wyatt, sceneggiatura originale e suoni di transizione generati localmente. Narrazione di Kore generata dall'IA. Nessun filmato di riferimento, sprite, immagine del creatore, musica o voce clonata utilizzati. Dichiarazione di YouTube sui contenuti modificati/sintetici: Sì. Verificato il 27 ottobre 2026. I termini del progetto potrebbero subire variazioni. Modelli locali e dipendenze di terze parti possono avere licenze proprie. Cal.diy è attualmente contrassegnato per uso personale e non produttivo. I dati reali di DataForSEO di OpenSEO sono a pagamento dopo un periodo di prova limitato. OpenHiggsfield richiede una chiave di piattaforma; non è verificata la generazione gratuita illimitata. Il prezzo dell'app desktop distribuita di Cap prevede l'utilizzo dei diritti commerciali; questo è distinto dalla licenza del codice sorgente. Nessuna affiliazione o approvazione. FONTI OpenWhispr: openwhispr/openwhispr VoiceStudio: debpalash/VoiceStudio Termini/edizioni di VoiceStudio: voicestudio.sh WeKnora: Tencent/WeKnora OpenProject: opf/openproject Community Edition: openproject.org Chatwoot: chatwoot/chatwoot Repository della community di Cal: calcom/cal.com OpenHiggsfield: wide-trace/open-higgsfield OpenSEO: every-app/open-seo DataForSEO: dataforseo.com Cap: Italiano: CapSoftware/Cap Prezzi di Cap: cap.so [pt-BR] 9 Alternativas de código aberto: código gratuito não é tudo de graça #shorts Nove alternativas de código aberto, com as ressalvas que os vídeos de substituição de assinaturas geralmente omitem: uso de API, hospedagem, hardware e termos de licença comercial. Esta é uma visão geral verificada a partir do código-fonte, não uma afirmação de que todas as ferramentas estão instaladas ou que você economizará uma quantia fixa. Animação original em pixel art de Wyatt, roteiro original e sons de transição gerados localmente. Narração de Kore gerada por IA. Nenhuma filmagem de referência, sprite, imagem do criador, música ou voz clonada foi usada. Divulgação de conteúdo alterado/sintético do YouTube: Sim. Verificado em 27 de outubro de 2026. Os termos do projeto podem mudar. Modelos locais e dependências de terceiros podem ter suas próprias licenças. O Cal.diy está atualmente marcado para uso pessoal, não comercial. Os dados reais do DataForSEO do OpenSEO são de uso pago após um período de teste limitado. O OpenHiggsfield requer uma chave de plataforma; não há verificação de geração gratuita ilimitada. O preço do aplicativo de desktop distribuído do Cap cobra por direitos comerciais; isso é distinto de sua licença de código-fonte. Sem afiliação ou endosso. FONTES OpenWhispr: openwhispr/openwhispr VoiceStudio: debpalash/VoiceStudio Termos/edições do VoiceStudio: voicestudio.sh WeKnora: Tencent/WeKnora OpenProject: opf/openproject Community Edition: openproject.org Chatwoot: chatwoot/chatwoot Repositório da comunidade Cal: calcom/cal.com OpenHiggsfield: wide-trace/open-higgsfield OpenSEO: every-app/open-seo DataForSEO: dataforseo.com Cap: CapSoftware/Cap Cap Preços: cap.so
8. Chatwoot → replaces Intercom Every lead and customer message (chat, email, socials) in one shared inbox. ⭐ 38.3k chatwoot/chatwoot
🔗 All 9 Open-Source GitHub Repositories: 1. Cap (Loom alternative): CapSoftware/Cap 2. Cal.com (Calendly alternative): calcom/cal.com 3. VoiceStudio (ElevenLabs alternative): VoiceStudio/VoiceStudio 4. Chatwoot (Intercom alternative): chatwoot/chatwoot 5. OpenProject (Asana alternative): opf/openproject 6. OpenSEO (Semrush alternative): every-app/open-seo 7. WeKnora (Notion AI alternative): WeKnora/WeKnora 8. OpenWhispr (Wispr Flow alternative): openwhispr/openwhispr 9. Open Higgsfield (AI Video alternative): github.com/Higgsfield-AI 💬 Quick poll: Which one are you cloning or deploying first? (Or tell us which paid software should get replaced next!) 👇
Customer conversations scattered across channels? 💬 Chatwoot brings live chat and support messages into a shared inbox. Assign conversations and collaborate in one place. 🧑💻 chatwoot/chatwoot #CustomerSupport #浇朋友 #蓝朋友 #互关 #fo
We built four chats. Obviously, that was the sensible thing to do. --- title: "We built four chats. Obviously, that was the sensible thing to do." description: "How a tiny hotel FAQ chat multiplied into four parallel chat implementations—and how we finally made them share a component." tags: webdev, javascript, architecture, ai canonical_url: chat.fodylabs.com cover_image: chat.fodylabs.com published: true --- Whenever a developer runs into a problem, the first question is not always “How do we solve it?” Often it is “What are we going to solve it with?” Build it ourselves, or use something already built? Open source, or a hosted service? Today, if you have AI, the answer seems obvious: “Build it ourselves! Ourselves, ourselves!” And why not? Why drag home some old, heavy, slow contraption, built twenty years ago—practically in the age of mammoths—when AI can produce a shiny new one before lunch? We had that choice in front of us. In retrospect, this is the comparison we should have made before enthusiastically opening the editor: | Option | What it brings | Public price (USD) | The small print / “weight” | |---|---|---|---| | Build it ourselves | Exactly the hotel FAQ flow we wanted; no inbox or support suite we did not need | No vendor fee; developer time sold separately (apparently) | Every bug, integration, update and future feature comes home with you | | Chatwoot | Open-source, self-hostable live chat and shared inbox; API and webhooks; optional AI features | Community self-hosted edition: $0 for the software. Cloud plans start free; paid plans are per agent | “Free” still needs Linux, PostgreSQL, Redis, and a production server. For production, Chatwoot recommends at least 4 GB RAM and 2 CPU cores. | | tawk.to | Hosted live chat, ticketing and knowledge base; AI Assist available | Widget: $0. Remove branding: $29/month. AI Assist: from $29/month | A very persuasive “why build this?” price. You still need to check which extras and workflows your use case requires. | | Crisp | Hosted chat and shared inbox; higher tiers add workflows, ticketing and AI tools | Free: $0 (2 seats); Mini: $45/month per workspace; Essentials: $95; Plus: $295 | Workspace pricing, not per agent. The amount buys a broader support platform, not just a chat bubble. | | Intercom | Messenger, shared inbox, help center, automation and Fin AI agent that can take actions on external systems | Essential: $29/seat/month; Advanced: $85; Expert: $132, plus $0.99 per Fin outcome | Seat cost plus AI outcomes. Excellent if you need that customer-service platform; a lot to adopt just to answer “Does the room include breakfast?” | This is a snapshot of public prices and product descriptions checked on October 16, 2026, not a universal benchmark. Plans, billing terms and included quotas change; the linked vendor pages are the source of truth. Chatwoot's Community code is MIT-licensed; its self-hosting guide documents the server requirements. And before anyone asks: no, this is not a bundle-size comparison. These vendors do not publish directly comparable widget JavaScript sizes on the cited pages. “Heavy” can mean downloaded bytes, a dashboard with a small city inside it, an invoice, or the operational burden of keeping Postgres and Redis happy. We did not measure all those things, so we will not invent a kilobyte column to make the table look more scientific. One thing we can measure, though: the embeddable widget script that ends up running on a hotel’s or a taxi company’s website is plain JavaScript, with zero npm packages pulled into the visitor’s browser. Not “minified to feel light”—there is simply no dependency tree to minify. We cannot audit anyone else’s supply chain, so we will not claim the competition is insecure. We can say that our widget has no third-party code to go wrong, which is a smaller, quieter kind of security than a vendor’s compliance page, but a security property all the same. Also, we did not actually complete this spreadsheet before building. We had a small, concrete need and wanted a small, concrete widget. The spreadsheet is the responsible version of the story; the real version is that we started coding and only later noticed the pattern. The small problem that started it We had a problem with our hotel websites: tourists were having to navigate them. They wanted to know the price, what was included, whether there was a transfer. The answers were on the site, of course. Somewhere. Usually behind a menu, a page, and a small but meaningful test of one's determination. We did not want to bring in a large, opinionated component just to answer “How much is the room?” So we made a little chat for our quick hotel sites. Put it on the page, give it the basic information, let the tourist ask in ordinary language. No grand strategy. No platform roadmap. Just fewer clicks between a question and an answer. This is how many grand strategies begin: by insisting there is no grand strategy. Meanwhile, in three other parts of the codebase… We were also building a taxi service. Passengers needed a way to talk to drivers. We were building a financial application. Customers needed support. And we were still building hotel sites, where that first little chat seemed like a pretty good idea. These projects did not politely line up and wait for one another to finish. They were happening in parallel. Which is a productive way to work, right up until you look around and discover that you are developing four chats at once. Four chats. Each one better than the other three. Naturally. That sentence should make an engineer reach for the fire alarm. We did not have one handy, so we reached for the architecture. The usual copy-paste strategy was working perfectly By “perfectly,” we mean every chat was improving—and none of them was improving in quite the same way. One had picked up a useful interaction. Another had better handling for its particular workflow. A third had learned something about support. Fix a small thing in one, and the other three remained serenely unaware. They were not broken; they were simply becoming four separate answers to the same question. Copying fixes between them was possible. So is maintaining four calendars by sending yourself increasingly stern emails. Possible is not the same as a plan. The important realization was that the products did not need the same behavior. They needed the same chat component—with a way for each host application to supply its own behavior. One chat, not one-size-fits-all We pulled the shared parts behind one embeddable interface. The host application still owns its data, business rules and decisions. The chat provides the conversation surface and can be configured to fit the job. For a hotel site, the starting point is deliberately boring: <script src="https://chat.fodylabs.com/chat-engine.js" defer></script> <script> window.addEventListener('load', function () { ChatEngine.mount({ endpoint: 'https://chat.fodylabs.com/api/chat', historyEndpoint: 'https://chat.fodylabs.com/api/history', title: 'Ask us anything', payload: { project: 'YOUR_PROJECT_ID', key: 'pub_YOUR_PUBLIC_KEY' } }); }); </script> Those two placeholders are the project's identifiers, not magic credentials you have to invent. In the FodyChat dashboard, create a project, add its FAQ or other knowledge, and copy the generated embed snippet. It supplies the project's ID and its pub_… public key. The ID tells FodyChat which project's settings and knowledge to use; the public key identifies that project when the widget calls the API. It is meant to appear in the page source, so it is not a password or secret. The project also needs to allow your website's origin. “Boring” is a compliment here. Add the business's FAQ or basic information, and a visitor can ask a question without taking the scenic route through the navigation. If the FAQ grows into a library, the same chat can use retrieval over a larger knowledge base. If the application has live data, it can call the application's API. If the application needs to perform an action, the host can explicitly allow that action and handle it itself. The chat can grow up. It does not have to arrive wearing enterprise architecture on day one. A conversation is not a transaction The taxi application taught us to be particularly careful about the difference between “the chat said so” and “the system did so.” A passenger can ask for an excursion, give a date and time, and say how many people are coming. That is a useful draft. It is not a booking. It does not mean the order was submitted, and it definitely does not mean a driver has accepted it. The assistant can help prepare the details. In our current flow, Taxi owns the booking form, validation, confirmation and actual order status. We chose that boundary; developers could authorize a different flow to submit the order. A driver is assigned because the dispatch system says so—not because a language model has become optimistic. The same boundary matters in financial support. A chat can help someone find information or navigate a workflow. The application still decides who is signed in, what they are allowed to do, and whether any operation actually happened. In other words: the assistant may be helpful, but it does not get promoted to database. Some useful problems were smaller than “build a chat,” but solving them well made the experience much better. A taxi passenger can dictate where they need to go instead of typing an address. The chat finds the place, shows it on an in-chat map, and passes the selected point into Taxi's booking form, where the passenger can review and confirm the order. Dictation also lets visitors speak instead of type, with the transcript placed in the message box for review before sending. And when a conversation reaches a human operator, messages are translated in both directions. Operators on Telegram or Slack can reply with a voice note; it is transcribed and translated into the guest's language like a typed response. And sometimes a chat is just a chat Once the chat and AI were connected to the same useful information, we could reuse that work in more than one place. For almost no additional infrastructure, a business can let visitors ask questions naturally instead of navigating the site—and use its well-structured knowledge as a practical starting point for generative engine optimization (GEO). There is an important distinction: an embedded chat does not automatically make a site visible to external AI search engines. It does not rewrite the site's pages or robots.txt, and it cannot promise that another AI will crawl or cite the business. We explain what this GEO foundation does—and does not—mean in the public integration guide. Where the job calls for AI clients to query live data directly, we can expose the relevant API through tools or MCP. We did that for Radioller's live station catalog. It is a specific integration, not a button that turns every chat into a universal MCP server. Looking a little further ahead, perhaps an AI will pick up our plans over morning coffee—or catch a half-formed thought—and order a taxi without a chat or a website anywhere in sight. That future may be a year or two away. Let's give it a little time. Until then, explore FodyChat and try the playground.