Feature Request

Business Problem: As a manager, I want call transcription capabilities, so that I can have accurate, searchable records of conversations for reference and training purposes. Desired Outcome: Real-time transcription during calls. Accurate, formatted transcripts available immediately after calls. Use Cases: Record keeping for client interactions. Generating transcript archives for team collaboration. The Current Workaround: N/A

Business Problem : Many customers possess a substantial amount of knowledge sources for generating responses, surpassing the current character limit. Desired Outcome : Enhance customer experience by raising the character limit for knowledge sources, enabling the addition of more sources for response generation.

Business Problem: Currently, the AI Agent replies immediately to each individual user message. When users send multiple messages in a short period of time, the AI replies to each one individually. This can make the conversation feel broken or unnatural. As a result, the interaction may feel rushed, robotic, and less natural. For example: User: “I’m interested in Product A.” User (immediately after): “Does it work with Shopify?” AI responds instantly after Step 1: “Great! Here’s more information about Product A.” In this case, the AI responds too quickly and doesn’t wait to see if the user had more to say. As a result, it misses the full context and gives an incomplete answer. Desired Outcome: To create smoother, more natural conversations, the AI should pause briefly and respond once with full context when multiple messages arrive close together. To achieve this, the AI should: Detect new incoming user messages before and during response generation, and briefly wait to see if additional messages arrive. When a new user message comes in before the AI finishes replying, cancel the current reply and create one new response that includes everything the user just said. Introduce a short waiting period (e.g., 3 seconds) before generating the response to give users a chance to add follow-up messages and provide more complete context.

Business Problem: Currently, users have limited control over how website content is crawled for the Knowledge Source feature. This can result in unwanted pages being indexed, inefficient crawling of deeply nested content, and unnecessary reliance on sitemaps that may not always be optimal. Without configuration options, users face challenges with crawl efficiency, content relevance, and overall crawl performance. Desired Outcome: Provide advanced crawl configuration options to give users greater control over the crawling process. Specifically: Set Maximum Crawl Depth: Allow users to specify how deep the crawler should follow links from the seed URL. Define URL Inclusion & Exclusion Rules: Enable users to create rules or patterns (e.g., path, query string) to include or exclude specific URLs from being crawled and indexed. Enable or Disable Sitemap-Based Crawling: Give users the choice to enable or disable sitemap-based crawling. These enhancements will improve crawl efficiency, content quality, and user confidence in the Knowledge Source feature.

Business Problem: Currently, we only supports text extraction from image as input for its knowledge source. This limits its ability to generate accurate and helpful responses in scenarios where essential information is provided in image formats—such as product photos, or visual instructions. Without image support, our AI Assist and AI Agent features cannot reference or reason over visual content, leading to incomplete responses and reduced automation potential in image-heavy workflows. Desired Outcome: Enable AI to process and utilize image data uploaded to the knowledge source. The system should be able to extract and index relevant information from images and make that information accessible to both AI Assist and AI Agent for generating contextually rich responses. This enhancement will extend Respond AI’s capabilities beyond text and support more use cases.

Business Problem: Currently, the Website Knowledge Source (KS) allows only a single seed URL per source, limiting flexibility and coverage—especially for websites with content spread across multiple domains. As a result, users are forced to create multiple Website Knowledge Source to achieve broader coverage, which increases setup overhead. Desired Outcome: Allow users to define and crawl multiple seed URLs within a single Website Knowledge Source, so the AI can aggregate content from all specified entry points in one crawl session.

Business Problem The AI Agent may sometimes send duplicate responses in a conversation. This can confuse customers, make interactions feel less professional, and clutter the chat with repeated messages. Desired Outcome Avoid sending duplicate replies to customers Provide a smoother, more professional experience Reduce unnecessary message volume for both customers and agents

Business problem: As a manager, I want to restrict call capabilities for agents and align incoming call menu visibility with agent user restrictions so that I can ensure compliance and improve call handling efficiency. Desired outcome: Ability to configure call permissions per agent role Incoming call menu visibility aligns with agent restrictions Improved control over call-handling capabilities Use Cases: Managers restrict outbound calls for certain agents Agents only see call options relevant to their permissions The current workaround: N/A

Business Problem: Currently, users must wait for each knowledge source to finish ingesting before they can upload the next one. This sequential process slows down onboarding and makes managing multiple knowledge sources inefficient, especially for teams handling large volumes of content. Desired Outcome: Enable users to upload and initiate ingestion for multiple knowledge sources at the same time, without having to wait for each to complete. This will streamline the setup process, save time, and make it significantly easier to manage and scale knowledge management within the platform.

Business Problem: Currently, when a crawl times out before completion, the platform treats the entire crawl as a failure—discarding all content collected up to that point. This leads to unnecessary data loss and a frustrating user experience, especially for large websites or slow-loading pages. Users are left with no visibility into what was successfully crawled before the timeout, and they must reinitiate the crawl from scratch, wasting time and resources. Desired Outcome: Enhance the crawl logic to support graceful handling of timeouts by: Returning a “Partially Completed” status when the crawl fails midway Storing and indexing all successfully crawled content up to the point of timeout This improvement would help users retain partial progress and reduce repeat crawling efforts.