Feature Requests

Problem: MSPs that run a dispatcher-first model (dispatcher answers all inbound calls, then hands the work to the technician who'll own it) have a clunky experience with Voice AI's attendant call handoff today: the call reaches the Voice agent, which hands off to the service desk; the dispatcher answers and has to state their name as part of the handoff; the resulting ticket gets created and assigned to the dispatcher, not the technician who'll actually do the work; the dispatcher then has to manually reassign every single ticket to the right technician. Impact: a manual reassignment step on every inbound call rather than an occasional exception; ticket ownership, assignment, time entries, and per-technician reporting are all wrong from the moment the ticket is created; there's no way to hand off the live call itself from dispatcher to technician, only the ticket, and only after the fact. Request: a warm transfer that carries the ticket along with the call when the dispatcher hands off to a technician, plus a dispatcher role/mode whose answering doesn't automatically claim ticket ownership.

The Voice AI system currently cannot map multiple contacts to the same phone number, which creates awkward interactions when calls originate from shared or office numbers. This is a common scenario for organizations with many facilities, such as nursing homes, where outgoing calls often use a default number. The lack of support leads to misidentification of callers and reduces the fluidity of voice interactions. The requested feature would allow the system to recognize and correctly handle shared numbers, improving accuracy and user experience during calls.

Current Behavior: The "Technician Briefing" setting is an all-or-nothing toggle. When enabled, the voice agent announces the ticket number and prompts the technician for their name to auto-assign the ticket. When disabled, both functions are lost — the ticket number announcement and the name capture/assignment are removed together. Problem: Some teams have technicians who take calls but are not the appropriate person to own the ticket (e.g., they work a different phone system type). In those cases, the team wants the call transferred without triggering ticket assignment. However, they still want the ticket number announced so the call context isn't lost entirely. Requested Enhancement: Split the Technician Briefing setting into two independently toggleable controls: Announce ticket number — read the ticket number to the technician receiving the transfer. Capture name & assign ticket — prompt the technician for their name and auto-assign the ticket to them. This would allow teams to receive the ticket number on transfer without being prompted for a name, and without triggering an assignment to a technician who shouldn't own that ticket type. Business Impact: Affects teams with mixed-skill technicians handling inbound call transfers. Current workaround is to leave the full briefing on (causing repeated name prompts for users who don't need assignment) or turn it off entirely (losing ticket number context).

Current Thread Voice AI has too much call latency/lag. The partner is requesting direct routing support as it would eliminate the lag by removing the additional hop in the call path. This would improve call quality and overall experience for their team.

Add automated pre-flight checks and monitoring for configuration settings to detect missing or invalid defaults before calls fail. In this case, voice agent calls rang with no answer because the default contact assignment had been removed, and restoring the catchall contact immediately resolved the issue. The platform should validate critical routing settings such as default contacts, alert users when configurations become incomplete or change unexpectedly, and provide proactive warnings or diagnostics to prevent service interruptions.

Add the ability to define which technicians can receive calls for specific agents within the Voice AI Attendant. Customers want more control over routing so the system does not incorrectly assign calls to similarly named technicians. The current behavior can misroute calls even when the correct name is clearly recognized, especially after routing all calls through the Voice AI Attendant first. A configurable mapping or restriction system would reduce incorrect assignments by limiting which technicians are eligible for each agent’s calls.

Partners need the ability to control whether the Voice AI announces the company name in greetings. Currently, even when the prompt explicitly instructs the AI to say only a specific phrase, it still inserts the company name. For white-label clients, the greeting should be fully customizable, for example saying "Thanks for calling support" without any company name. At the same time, partners should still be able to include the company name when providing white-glove support for specific clients. The request is for a toggle or prompt-level control that gives full flexibility over whether the company name is announced.

Kelvin Rosario requests that Thread only send Teams alerts and create tickets for after-hours calls when a voicemail message is left. Currently, the system notifies and creates tickets for all calls, even those where callers hang up without leaving a message. This results in unnecessary alerts and workload for on-call technicians. Adding this feature would ensure that only actionable calls trigger notifications, improving efficiency and reducing alert fatigue.

Add a feature to the Afterhours voice chat system that allows agents to confirm with the client whether they accept additional afterhours charges before proceeding with the call. If the client declines, the call should be ended automatically. This would enable afterhours calls to be handled differently from regular calls and ensure proper charge acceptance prior to continuing.

Request to enable the afterhours AI bot to make outgoing phone calls to specific numbers for urgent support notifications. This would ensure that the on-call technician receives notice when a user reaches out after hours, as phone calls are more likely to wake them than Teams notifications. The bot should be able to call and, if necessary, follow up with additional calls to ensure the technician is alerted. This would greatly improve responsiveness and client experience during afterhours incidents.