Feature Request

Business Problem There is no native time-based trigger in respond.io that fires based on inactivity in an open conversation. Teams cannot automatically detect when a contact has gone quiet mid-conversation, or when an agent has not replied to a contact within a defined period — and take action on it. Desired Outcome A native Workflow Trigger that fires when no message has been sent within a configurable time window (X minutes/hours) on an open conversation, with the ability to specify the direction: Contact inactivity — time since last incoming message (contact hasn't replied) Agent inactivity — time since last outgoing message (agent/AI hasn't replied) Use Cases When a contact goes quiet mid-conversation, there is no native way to trigger a follow-up. Agent follow-up accountability: A team receiving 30–40 new leads daily cannot manually check each conversation to see if agents have replied. An inactivity trigger would alert or reassign automatically when an agent hasn't responded within X hours High volume support: Teams want to automatically send a holding message when no agent has replied within 30 minutes, before the contact loses patience

Issue Description: Currently, when an AI Agent updates a contact field (e.g., $contact.specific_start_time) and immediately triggers a HTTP request that references that same contact field in the request body, the HTTP request does not reflect the updated value. Instead, it sends the previous/stale value of the contact field. Current Behavior: AI Agent executes: Update $contact.specific_start_time = "13:45" AI Agent executes: Trigger HTTP request with body containing "specific_start_time": "$contact.specific_start_time" HTTP request payload receives the old value (e.g., "12:00" or empty) instead of "13:45" Expected Behavior: The HTTP request should automatically wait for the contact field update to be fully persisted and then use the latest value of that contact field in the request payload. Impact: This synchronization issue prevents reliable sequential workflows where: A contact field must be updated first An HTTP request must immediately follow using that updated field value The external API/system depends on receiving the correct, up-to-date data Requested Solution: Implement a synchronization mechanism that ensures contact field updates are persisted before executing HTTP requests, or provide a way for users to explicitly wait/confirm that the contact field is updated before triggering the HTTP request. This would guarantee data consistency between the contact record and external API calls.

Problem Statement: Currently, our AI features can’t send images or files to customers. This is a major roadblock for both sales and support teams, who often need to share product images, brochures, guides, or troubleshooting documents to give customers the full context or help them solve problems. Without this, customer interactions are less effective and require manual intervention for something as simple as sending a file. Desired Outcome: AI should be able to recognize when an image or file is needed and send the appropriate material automatically, based on the conversation. This would allow customers to get complete answers and resources instantly, boosting satisfaction, speeding up resolutions, and letting teams focus on more complex tasks—without having to jump in just to attach a file.

Business Problem: Currently, the AI Agent will wait for 1 second before starting generate a response when it detects an incoming user message. If a new message arrives while it’s preparing a reply, the generation process is aborted—this can avoid. Desired Outcome: Allow users to configure the waiting time before the AI Agents starts generating a response. This way, teams can adjust the delay to better match their chat patterns, reducing unnecessary interruptions and improving the overall conversation flow.

Adding a one-click Outlook integration as a new Email channel. This post refers only to the email Outlook integration, to see the progress with other emails integrations visit the other posts: Gmail: https://respond.canny.io/feature-request/p/new-channel-email-gmail Released IMAP/SMTP: https://respond.canny.io/feature-request/p/new-channel-email-imapsmpt Released

Business Problem Currently, users are forced to close conversations individually, which is a slow, repetitive, and labor-intensive process. For organizations dealing with high message volumes, this manual requirement creates a significant bottleneck. When large volumes of conversations are left open due to the time required to clear them, it results in: Inbox Overload: Relevant, active conversations are buried under "stale" or resolved chats, reducing agent productivity. Operational Fatigue: Supervisors spend hours on manual "inbox cleanup" instead of focusing on team performance and strategy. Desired Outcome To introduce a Bulk Close functionality within the Messages module. This feature will allow users to select multiple conversations simultaneously—or apply filters to a specific segment—and close them all with a single action.

I would like to be able to delete or edit a message that I sent by mistake on the Messages module, and for it to also be removed for edited rom the recipient's device. 🔴 Important Note: This is NOT a limitation on respond.io . This is a limitation set by Meta's team to all WhatsApp API accounts.

Business Problem Right now, AI Agent keeps up to 20 messages as context—even after a conversation has been closed. This can lead to responses feel outdated, irrelevant, or overly influenced by past conversations the user didn’t intent the AI to recall. For example, a Contact previously asked about refund. When they return later to ask about pricing, AI Agent references refund-related context, causing confusion and irrelevant responses. Desired Outcome Provide an option that allows users to disable historical context. When enabled, AI Agent should only reference the messages in the current conversation, ensuring responses stay fresh, relevant, and scoped to the active interaction.

Business Problem Currently, AI Agent instructions support up to 10,000 characters. While this is an improvement from the previous 5,000-character limit, it can still restrict users who need to define: Detailed persona and brand voice guidelines Complex behavioral rules and escalation logic Business-hours-based responses Edge-case handling (e.g. file failures, coexistence scenarios, channel-specific behavior) Compliance or regulatory messaging requirements As AI Agents are increasingly used as first-line support, users need more space to accurately reflect real operational workflows and brand communication standards. Desired Outcome Increase the AI Agent instruction character limit from 10,000 to 20,000 characters. This will allow users to: Create richer, more precise AI personas Reduce ambiguity in AI responses Centralize complex logic within the instruction set instead of relying on workarounds Improve AI response quality, consistency, and alignment with business needs

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.