Feature Request

## Business Problem Since October 1, 2026, the new WhatsApp Business Platform pricing model has significantly increased the cost of human-to-human conversations for businesses with a consultative sales model. In our case, WhatsApp conversations often involve many individual messages exchanged between a sales agent and a customer. These are not automated or bulk conversations — they are genuine one-to-one sales consultations. We already use respond.io as our central inbox and would like our agents to continue working there. However, when an agent replies through the existing WhatsApp API channel, the message is sent through the WhatsApp Business Platform and is therefore subject to API message charges. With WhatsApp Coexistence, agents can avoid these API charges by replying directly from the WhatsApp Business App. The problem is that they then have to leave respond.io and work from the WhatsApp Business App, losing the benefits of having a centralized inbox. ## Desired Outcome We would like respond.io to support a WhatsApp Business App manual messaging channel or mode that allows agents to send and receive human messages from the respond.io Inbox without those messages being sent through the WhatsApp Cloud API. We fully understand and accept that this channel/mode could have important limitations: No Workflows No AI Agents or bots No automated messages No broadcasts or campaigns No API-triggered outbound messages No message templates Its purpose would be exclusively manual, human-to-human communication . Ideally, businesses using WhatsApp Coexistence could choose how a message is sent: API mode: for automation, bots, workflows and integrations. Business App / Manual mode: for messages manually written by an agent, without using the Cloud API messaging route. ## Use Case A business could use the same WhatsApp number with Coexistence: respond.io + WhatsApp API for automated conversations. WhatsApp Business App for human conversations. Today, when a conversation is transferred to a human agent, the agent must leave respond.io and open WhatsApp Business App to avoid API messaging costs. The desired experience would be: Customer → respond.io Inbox → Human Agent → WhatsApp Business App messaging route → Customer The agent would remain inside respond.io , while the message would behave as if it had been manually sent from the WhatsApp Business App. ## Business Impact This has become especially important for businesses with consultative sales or customer service models , where a single customer conversation may involve many short human messages. The recent WhatsApp API pricing changes can make these conversations disproportionately expensive, despite requiring no automation. Providing a manual Business App messaging option would allow companies to: Keep respond.io as their central customer communication workspace. Continue using automation where it adds value. Switch to human-only messaging when an agent takes over. Avoid forcing agents to work simultaneously in respond.io and WhatsApp Business App. Make WhatsApp Coexistence much more valuable for businesses affected by per-message API pricing. ## Current Workaround Use WhatsApp Coexistence and ask agents to reply directly from the WhatsApp Business App whenever a conversation becomes human-led. This avoids API messaging costs, but forces the team to leave respond.io and manage conversations in two different interfaces.

Business Problem: When agents (human or AI Agent) send several short messages in quick succession, WhatsApp delivers and bills each one separately. Since 1 October 2026, service messages are charged per message once a number passes its 1,000 free messages per month. Fragmented replies therefore use up the free allowance faster and raise costs, especially for high-volume teams. They also send customers multiple notifications for what is effectively one reply. Desired Outcome: Add an optional setting that briefly holds outgoing messages and combines rapid consecutive ones into a single message before sending. Ideally, Workspace Admins could: Set the wait time before messages are combined Turn the feature on or off per Channel Preview or cancel the combined message before it's sent When agents (human or not) send several short messages in quick succession from the Inbox, WhatsApp delivers and may bill them as separate messages. This could help businesses: Reduce unnecessary billable WhatsApp messages Make better use of the monthly free service-message allowance Lower messaging costs as service messages move to per-message pricing Avoid sending fragmented replies and multiple notifications Improve the customer experience with clearer, consolidated responses

Business Problem: Currently, the respond.io MCP server can add internal comments to a conversation, but it cannot read the comments already there (Help Center: Model Context Protocol (MCP)). Teams that keep internal notes in comments cannot include them when they ask an AI assistant such as Claude for reports or summaries. Desired Outcome: Through MCP, AI assistants can access the comments module: a conversation's internal comments, with the author and date. Access follows the user's existing permissions in respond.io .

Business Problem: Currently, each respond.io MCP connection can only be authorized for one Workspace. Users who manage several Workspaces have to disconnect and reconnect every time they need to work in a different one. This is especially limiting for agencies, consultants, and users managing multiple customer accounts. For example, one user manages 10+ Workspaces, which makes the MCP integration slow and impractical. Desired Outcome: Allow a single MCP connection to be authorized for multiple Workspaces at once. Each Workspace stays isolated, and the user's existing permissions in each Workspace still apply. Users can work across all their authorized Workspaces without reconnecting.

Business Problem: Currently, AI Agent instructions are limited to 10,000 characters. Businesses that run one detailed flow, such as support, sales or post-purchase help, fill this space with rules for edge cases, escalation, business hours and compliance. When they reach the limit, they must shorten or remove rules, and the AI Agent becomes less accurate. Desired Outcome: The instruction field accepts more than 10,000 characters, so one AI Agent can hold all the rules for its flow. Use Cases: An online store's post-purchase AI Agent covers order status, returns, exchanges, refunds and warranty in one set of instructions. A support AI Agent gets new safety and escalation rules without losing existing ones. Current Workaround: Shorten the instructions, or split one flow across several AI Agents, which breaks the context between them.

Business Problem: The new conversation sentiment rating is useful, but managers want to see it across the team: how many conversations were positive, neutral or negative, overall and for each agent, in real time. Desired Outcome: The Dashboard shows live sentiment totals, overall and by agent. The Reports module to compare sentiment between Teams, Agents, Conversation Categories

Business Problem When a contact reacts to a message (e.g. 👍, ❤️, 😂, 😢), AI Agent doesn't receive the reaction at all. Contacts often use reactions as a quick reply: a 👍 on "Can I proceed with the order?" or a ❤️ on a resolution message. AI Agent misses that signal, so the conversation stalls, AI Agent follows up on a question that was already answered, or it can't tell whether the contact was satisfied. Desired Outcome Pass contact reactions to AI Agent as conversation context so it can respond and act on them. To achieve this, AI Agent should: Receive the reaction emoji along with the message it was attached to Read the reaction as the contact's reply to that message (e.g. 👍 on a confirmation question counts as approval) Be able to trigger actions from a reaction when relevant (e.g. close the conversation after a 👍 on a resolution message), and notice when a contact removes or changes a reaction

The official WhatsApp API currently doesn't support Group Chats. Other platforms supporting WhatsApp Groups use unofficial APIs that often break. We will consider building this feature once it is released officially for WhatsApp API. 🔴 Important Note : As of February 2026, Meta has released native Group Chat support through WhatsApp cloud API. However, there's significant restrictions at this time: The Groups API is now available to all businesses with an Official Business Account (OBA). It is not available for Coexistence users yet Because of this, once Meta expands eligibility and releases full documentation for all account types, we can consider to move forward. This is NOT a limitation on respond.io . This is a limitation set by Meta's team to all WhatsApp API accounts.

Use case and desired outcome: Customers can ask questions about their messages and get qualitative information or insights about their messages in real-time. For example, the customer could ask “What are the top 3 things contacts complained about yesterday?”

Business Problem: The current role-based permissions structure (Agent, Manager, Admin) does not provide enough flexibility for organizations with complex operational workflows. Many businesses — especially those with multiple internal departments — require fine-grained control over what each user can view, edit, or do inside the platform. This leads to risks such as accidental customer replies, unauthorized data edits, or exposing sensitive information to users who should not have access. Desired Outcome Introduce a granular permission system that allows workspace admins to customize access levels per user or per role. This should include the ability to enable or disable specific actions, modules, or permissions, such as: Access to Dashboard, Contacts, Messages, Snippets, Users & Teams (but not Workflows or advanced settings) Read-only access to conversations Restricting ability to reply to contacts Restricting ability to send files, surveys, or voice notes Allowing comments only for inter-team collaboration Use Cases Multi-Team Operational Workflows Some customers (e.g., online stores) have an operations team that reviews cases internally. The desired flow: Customer care assigns a contact to the operations team Operations team reviews history Leaves internal comments Contact is returned to the agent However: The operations team should not reply directly to the customer Replies must be text-only for some agents Operations team should have limited permissions (no surveys, no attachments, no voice notes) Restricting Access to Sensitive Contact Fields Currently, contact fields marked as hidden are only collapsed behind a dropdown — but are still accessible and editable. Organizations need stronger control over field visibility to protect internal or confidential data. View-only fields: Users (at least agents) should be able to see certain fields but not edit them. Fully hidden fields: Some fields should be completely invisible to certain roles (not displayed anywhere in the interface). This is important for companies storing sensitive customer data (financial info, internal IDs, CRM-synced fields, etc.), where only a subset of users should have access or edit rights.