Feature Requests

We get emails that often come in from users that route to catchall if we don't have a clear contact record in our system. We would like Magic AI to route these tickets to the correct company automatically.

When the Triage Agent handles email-sourced threads, troubleshooting steps are sent one per reply (waiting for a response between each), matching the behavior used in chat. This results in end users receiving multiple separate emails for a simple 2-3 step fix, with potentially hours or days between each. Partner has configured rules to batch replies for email sources, which works correctly for questions (multiple questions sent in one reply) but does not apply to troubleshooting steps. Partner is requesting that the agent batch all troubleshooting steps into a single reply when the ticket source is Email, consistent with how question batching already works. If this is a platform-level behavior, partner would like email-source troubleshooting batching added to the roadmap.

Currently, the Reminder Agent only follows up based on the initial request and does not read or act on updated discussion notes or ticket context added after the first message. This causes confusion, especially in approval workflows where the context changes after the ticket is reassigned or new notes are added. Improving the Reminder Agent to reference the latest ticket context and discussion notes would ensure follow-ups are accurate and relevant, reducing manual intervention and streamlining approval processes for our team.

Request to enforce automatic escalation of any ticket to a technician whenever the agent does not have access to the information needed to resolve the request, across all Thread Magic Inc. tickets. The partner believes this could be improved by providing more insight or guidance on how to expose the AI to relevant data within existing systems, potentially reducing unnecessary escalations and improving resolution speed.

We want to build Super Magic Agents that manage tickets in Customer Updated status. The problem is that Super Magic can change the status but can't clear the ConnectWise Customer Updated flag. We have a ConnectWise workflow rule that sets the status back to Customer Updated whenever that flag is checked, so any agent that moves these tickets ends up in a loop. Right now this limits what we can automate. Please add a way for Super Magic to clear the flag, such as a customer updated option on update_ticket.

Within a thread, "Ask Magic" will not retrieve any user contact info. This includes: Any contact numbers for the owner of the thread Any other contact that has been added to the thread Any other user at the company. It cites "privacy concerns" as the reason for this. When asked to locate contact info within the current thread, it does not until prompted with "the info is in this thread". In one instance, it provided a contact number that was not present at all in the current thread (or anywhere else). Given that the information is already there, we should be able to retrieve it.

Partners need the ability to disable the Reminder Agent on a per-ticket basis. Currently, the Reminder Agent triggers globally based on ticket status, with no way to exclude individual tickets. Without this granular control, the partner has indicated they will stop using the Reminder Agent altogether.

Currently, the chatbot responds immediately to each individual message, which can cause disruptions when users are answering multiple questions. If a user accidentally presses Enter before completing all their responses, the chatbot processes the partial message and replies before the user has finished. This leads to fragmented conversations and out-of-order responses. Requested Feature: • Introduce a brief response delay (e.g., 5–10 seconds) to allow users to send multiple messages in quick succession before the chatbot processes them. • If multiple messages arrive within this delay window, group them as a single user response for better conversational flow. • Maintain real-time responsiveness but provide users with a buffer to complete their thoughts before the chatbot interprets and replies. Use Case Example: • The chatbot asks multiple clarifying questions in a single response. • The user starts answering but accidentally presses Enter too early. • Instead of immediately responding, the chatbot waits for a brief moment to see if another message follows. • If multiple messages come within the delay window, the chatbot treats them as a single response before processing. This approach improves conversation flow and prevents interruptions due to premature responses. It would be particularly useful for users who expect a more natural, fluid chat experience.

Currently, the master intent has a 3000-character limit, which restricts the number of commands and logic that can be included. I am already utilizing nearly all of this limit and need additional space to incorporate more commands without having to remove or condense existing ones. Requested Feature: Increase the character limit for the master intent beyond 3000 characters to allow for more complex and comprehensive command structures. Ensure that this expansion does not impact performance or response efficiency. Use Case Example: I have fine-tuned my master intent to function as intended and do not want to modify or shorten existing commands, as doing so could disrupt the chatbot's behavior. I need to add new commands to expand functionality, but I have reached the character limit. Expanding the limit would enable me to enhance the chatbot’s capabilities without the risk of breaking the current setup. Increasing the character limit would provide more flexibility for building robust and scalable chatbot logic without forcing users to compromise on existing functionality.

When a main contact forwards an email into Thread Inbox, the ticket is correctly generated under the forwarder. However, the triage agent often addresses the original sender (from the 'From' field) instead of the actual ticket contact (the forwarder). This causes confusion, as the ticket replies are directed to someone not on the ticket. Request: Ensure the triage agent always addresses the ticket contact (forwarder), not the original sender, in all ticket communications. This will prevent confusion and improve workflow clarity.