Discuss ideas, submit feedback, and track what's next
Help us understand your request
An intake-ready template
Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue [ex. agents, admins, customers, etc.] (2-3 sentences)Requesting to add an option for a sound when an agent is sent a message as part of automation in Zendesk WFM as well as an option to customize the actual message. What problem do you see this solving? (1-2 sentences)Some agents can forget to even read the message or not see it at all if it doesn’t have a sound or alert, voiding its purpose altogether. As much as we’d like to keep tracking honest, some activities if locked for too long skews metrics so having customization options would be helpful. When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)Since May when we launched WFM. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)No - there is no workaround. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)
Feature Request: Implement hover tooltips on Ticket Fields in the Agent Workspace when viewing a ticket, leveraging the Ticket Field Description text. Similar to the hover option to see Macro Descriptions. Here is what this could look like: Use Case: We often use shortened or simplified Ticket Field names for agents for various reasons but they can leave agents, especially new hires, struggling to understand the intent. Shortened internal field names also make for prettier reporting and save hassle renaming attributes in Explore. Reasoning: Showing users the Ticket Field Description (that already exists in Support) or at least giving Admins a checkbox to use it as a tooltip would alleviate user confusion when completing forms and improve user effectiveness or accuracy documenting fields correctly. I'm sure there are many Zendesk admins that prefer shortened Ticket Field names while also struggling to convey enough detail to internal users/agents. Tooltips would solve these problems and improve the Agent Workspace.
Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue [ex. agents, admins, customers, etc.] (2-3 sentences)We would like Zendesk’s real-time AI suggestions for voice calls to support Auto assist procedures as a source, not only help center content. This affects agents who rely on live suggestions during customer calls, admins who maintain approved procedures, and customers who need accurate, complete guidance during live support interactions. Zendesk’s current documentation shows that real-time voice suggestions search help center content, while Auto assist procedures are a separate feature and cannot currently be configured on voice channels. [support.zendesk.com], [support.zendesk.com], [support.zendesk.com]What problem do you see this solving? (1-2 sentences)Real-time voice suggestions can paraphrase or simplify information from help center content instead of following our exact operational procedures. Allowing voice suggestions to use Auto assist procedures would help agents receive step-by-step, admin-approved guidance during calls, improving consistency and reducing the chance that important procedural details are missed. [support.zendesk.com], [support.zendesk.com]When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)We are affected by this problem every time an Agent uses Real-time AI Suggetions in a call. This problem is especially important for voice calls because agents need concise, accurate guidance in real time and do not have the same opportunity to review long articles while speaking with a customer as they do during Messaging or Email tickets. Zendesk’s voice suggestion documentation currently describes help-center-based suggestions, while the Auto assist documentation says procedures are the primary knowledge source for Auto assist and that Auto assist cannot be configured on voice. [support.zendesk.com], [support.zendesk.com], [support.zendesk.com]Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)Yes. We are trying to maintain help center content and procedures separately, but that creates a gap: real-time voice suggestions rely on help center content, while our more precise step-by-step guidance lives in Auto assist procedures. Zendesk’s documentation says procedures can include macros, actions, agent instructions, help center content, other procedures, and ticket fields, but the real-time voice suggestion documentation does not indicate that those procedures can be used as a source for live voice suggestions. [support.zendesk.com], [support.zendesk.com]What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Ideally, Zendesk would allow admins to enable Auto assist procedures as a source for real-time AI suggestions during voice calls, either globally or by group, line, brand, intent, or call reason. During a live call, Copilot should use the real-time transcript to identify the relevant procedure, then surface the procedure’s approved steps, macros, actions, and agent instructions in the Knowledge or Copilot panel without requiring the agent to leave the call workflow. [support.zendesk.com], [support.zendesk.com]
Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue [ex. agents, admins, customers, etc.] (2-3 sentences)Hello, we are adding Zendesk to our site but noticed that the close company message button has a scrollbar overflow and since the issue is inside the iframe we cannot add an overflow hidden to it, not sure if other people had the same issue, having an overflow hidden in the body solves it but since it is inside the iframe I can’t fix it What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Have an overflow hidden in the body of this iframe, not sure if other people have the same issue
thank you for choosing us .
A bug I've noticed across multiple different sites which use Zendesk for managing conversations between clients and support requests is that, if I reply to e-mails from Zendesk, the e-mails get silently dropped without getting added to the conversation thread. As some sites don't appear to expose Zendesk's web interface, this leaves me having to open a new ticket for each reply, mentioning the previous ticket as what I'm replying to. While I can't be certain, I believe the problem is that Zendesk assumes replies must come from the e-mail address they were sent to, rather than embedding some kind of identifying token in the message as a backup measure. (My anti-spam measures are based around giving a different inbound e-mail alias to each person and then setting up a mail filter that trashes any messages sent directly to my inbox without going through an alias, thus allowing me to treat the e-mail addresses I hand out like revocable API tokens.)
Is there a way to reorder the Ticket Status within the Status Category? For example, we added a new Ticket Status under the Solved Status Category and it is now listed as the last option when Submit as. We would like the default Solved Ticket Status to show last.
We tried the “Suggested assignees” EAP and quickly noticed that when a ticket is already assigned to a group, the feature still suggests agents who are not members of that group.In larger Zendesk instances with multiple brands and groups, this can be quite confusing, as many of the suggested agents are not actually eligible to handle the ticket.It would be great if, whenever a ticket is already assigned to a group, the suggested assignees were limited to agents who are members of that assigned group.
I want to create a rule or automation in Support wherein any message that comes in with a specific keyword will never be identified as Spam and inadvertently end up in the Suspended ticket folder. Example: any request that comes in with the word "arbitration" does not get overlooked and is routed to our legal team for review. I confirmed with Zendesk Support that triggers and automations don't work on these requests because they are stuck in the spam filter and not yet considered proper tickets. Also, whitelisting based on a single word is not an option; the allowlist feature only works for specific domains or email addresses.
Follow-up fromhttps://support.zendesk.com/hc/en-us/articles/8037649972634-Summarizing-ticket-comments-using-generative-AI OverviewWe would like ticket summaries to be automatically generated for all tickets, without requiring agents to manually click “View Ticket Summary.”Currently, the summary field only populates once an agent triggers this action, which leaves the field blank until that point. As a result, summaries are unavailable in Views, Explore reports, and the API until manually created. This affects agents, admins, and analytics teams who rely on complete, consistent summaries for reporting, automation, and intent analysis. ProblemOnly a small fraction of tickets (approximately 3% of the thousands we receive daily) currently have summaries. Most tickets (e.g. “Where is my order?” enquiries) are resolved quickly and never trigger manual summarization.Without these summaries, it’s difficult to perform meaningful, large-scale analysis of customer interactions beyond the assigned intent predictions. The missing summaries create significant blind spots in analytics, automation, and performance benchmarking. Problem SolvedAutomatic summarization would ensure every ticket includes a generated summary, allowing it to appear consistently in Views, Explore, and API exports.This would deliver full data coverage for analytics, intent validation, and automation, without requiring any manual agent intervention. Impact & FrequencyWe handle thousands of tickets per day, but only ~3% contain summaries due to the manual process.This limitation impacts us daily, hindering:Automation workflows dependent on the summary fieldLarge-scale analytics and intent modellingAccurate reporting and performance insightsThe lack of automatic summaries results in incomplete datasets and reduced reliability in Zendesk Explore and API-driven reports. WorkaroundWe developed an internal ZAF app (“AI Summary Auto-Trigger”) that attempts to simulate the summary click. However, ZAF does not allow interaction with UI elements outside its iframe, making this workaround technically infeasible. Ideal SolutionTicket summaries should auto-generate automatically upon ticket creation or update, with results immediately available via API, Views, and Explore datasets, eliminating any manual dependency.This would:Enable complete coverage for intent and topic modellingImprove anonymized analytics and performance insightsAllow validation of Zendesk-assigned intent taxonomy accuracy Without automated summarization, these capabilities remain limited to roughly 3% of our data, and manual triggering is not viable at enterprise scale.
Feature Request Summary: Zendesk Community should allow customization of the community post email notification from address. Currently it uses noreply@<domain>.zendesk.com. Zendesk Support allows this customizations for ticket email notifications. Description/Use Cases: A user subscribes to a community post and receives email notifications. They aren't confused by the from address including "zendesk.com" Business impact of limitation or missing feature: This is important for our business to preserve our branding.
Problem I’m trying to solveMy Zendesk Help Center includes system-generated pages (such as /hc/*/requests/*, including /requests/new) that are served by Zendesk and not by my own website. These pages are currently crawlable and indexable by search engines, and I have no way to control this behavior.Why the current functionality isn’t sufficient Zendesk’s robots.txt file is shared across all customers and cannot be customized at the account level. While noindex meta tags can be added via the Help Center editor, they are applied globally and cannot be configured on a page-by-page basis. Requesting URL removal via Google Search Console is only a temporary workaround and does not prevent future crawling or re-indexing. Desired outcomeI’d like a way to prevent specific Zendesk Help Center system paths from being indexed, such as: A Zendesk-managed robots.txt disallow for paths like /hc/*/requests/*, or An account-level option to apply noindex to specific system routes, or Any supported mechanism that allows customers to opt out of indexing for low-value or sensitive system pages. Business impact / contextThese system pages are not intended to be landing pages from search engines and provide little to no SEO value. When they appear in search results, they can: Confuse users who expect informational content but land on a ticket submission form Surface operational or sensitive pages that were never meant to be indexed Degrade overall SEO quality by allowing low-value pages into the index Being able to reliably prevent indexing of these pages would help ensure that only intentional, user-facing content appears in search results and would align Zendesk Help Centers with standard SEO best practices.
The ‘Auto-reassign open tickets’ setting in Zendesk applies globally across the entire account, affecting all groups and agents, regardless of whether a group uses Omnichannel Routing. What We Need:We’d like the ability to exclude specific groups or agents from auto-reassignment when they go offline (or hit a defined status). Currently, the only exclusion option is based on ticket priority, which is too limited. Ideal Solution: Ability to exclude by group — so select teams aren’t affected by auto-reassignment. Even better: allow exclusion via a tag — enabling agents to use a macro to tag tickets they want to retain, effectively ring-fencing them from reassignment.
Feature request summaryAllow customization of the text and button label on the anonymous request email-verification success page (/requests/verification/success).DescriptionWith the anonymous help center request verification workflow, end users land on a verification success page after confirming their email. This page (e.g. https://help.teamnext.de/hc/de/requests/verification/success) is rendered outside the Guide theme – it loads no theme assets (no script.js, no theme CSS, no document_head.hbs). As a result, the on-page text and button label cannot be customized by any supported means. Theme code, JavaScript redirects, and CSS overrides all fail here because the page never loads the theme. Zendesk support confirmed there is currently no supported way to edit this text.Business impactThe fixed wording doesn't match our brand voice. We use "Helpdesk" instead of "help centre" and refer to our "support team" rather than "an agent". Crucially, the page uses the formal German address form ("Sie"), while our help center consistently uses the informal form ("Du") — and we can't change it. The text also can't be localized per language (DE/EN). As the final step of the request flow, this mismatch is visible to every anonymous requester.Requested solutionA supported way to edit the heading, body text, and button label of this page — ideally per language, and with control over the formal/informal address form (German "Sie" vs. "Du") — so the text matches our brand's tone of voice. For example via an editable field in Admin Center, inclusion in the Guide theme, or translatable text strings / dynamic content.Who is affected?Affects all anonymous help center requesters since the March 2026 verification rollout.Screenshots/hc/en-150/requests/verification/success/hc/de/requests/verification/success
When an article is verified I would like the verification date shown in the article details in Guide Admin. Currently, we only see that the article is "verified" but no indication as to when it was verified.
Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue.I’m requesting more actionable Admin insights for Auto-Assist performance. The current insight uses full resolution time, which can include broader ticket lifecycle time and may not accurately reflect agent handling or response speed. This affects admins and CS leadership who review performance insights, and agents when those insights make it appear that their workflow is slower than it actually is.What problem do you see this solving?This would help teams understand whether Auto-Assist is actually improving or slowing agent workflows. It would also prevent misleading performance alerts caused by customer wait time, Pending time, reopened ticket behavior, or other lifecycle factors outside the team’s direct control.When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business?We were affected recently when Zendesk Admin showed an Auto-Assist insight indicating that resolution time for the “Enable Auto-Assist (Non-API tickets)” trigger rose by 859%, from 39 minutes to 6 hours, for the June 7 to June 14 insight period. After reviewing Explore reports for the same time frame, we found that reopened Auto-Assist tickets had a median requester wait time of 24 minutes, and reopened auto-reply tickets had a median requester wait time of 12 minutes. This made the Admin insight difficult to act on because the 6-hour figure appeared to reflect full ticket lifecycle time rather than typical agent response or handling time. This can impact our business by creating confusion around whether Auto-Assist is helping or hurting performance, and it requires additional manual reporting to validate the insight.Are you currently using a workaround to solve this problem?Yes. We are using Explore reports with requester wait time to better understand how long customers are waiting once tickets are back with CS. This helps, but it requires manual validation and does not change the Admin insight itself.What would be your ideal solution to this problem? How would it work or function?The ideal solution would be for Auto-Assist Admin insights to offer a metric focused on agent-controlled time instead of only full resolution time. For example, the insight could measure from when Auto-Assist is enabled, or when the ticket enters a support-owned status, to when the agent replies, solves, or otherwise moves the ticket forward.
Hi team,Currently, a suspended user can successfully place and complete a phone call through Zendesk Voice, but no corresponding ticket is created. Zendesk Support has confirmed that this behavior is expected: user suspension only prevents ticket creation, not phone calls, and calls from suspended users do not generate tickets.As a result, agents can handle lengthy customer interactions without any ticket record being created, leaving the interaction outside the standard support workflow.Business ImpactThis creates significant compliance, governance, and auditability concerns:Customer interactions can occur without any corresponding ticket record. There is no centralized audit trail containing the conversation details, agent actions, or interaction history. Quality Assurance, compliance reviews, and operational audits cannot reliably verify that the interaction occurred. Call recordings are not retained for suspended users, further reducing traceability. Organizations operating in regulated environments may be unable to demonstrate complete customer contact records.In our case, an inbound call from a suspended user lasted approximately 88 minutes and was successfully handled by an agent. The call was visible in Voice metadata but no ticket was generated, no interaction record was available through standard workflows, and the recording was unavailable.Expected BehaviorOrganizations should have the ability to retain an auditable record of calls from suspended users. At minimum, Zendesk should:Create a suspended ticket when a suspended user places or completes a call. Preserve call metadata and interaction details within Zendesk. Retain call recordings according to account retention policies. Clearly surface that the requester is suspended while maintaining a record of the interaction.Current BehaviorSuspended users can call Zendesk phone lines. Calls are connected to agents and can be completed successfully. No ticket is created. Call recordings are not retained. Interaction visibility is limited to backend Voice metadata.Why This MattersSuspension is typically used to restrict or control user activity, often for risk, fraud, abuse, compliance, or security reasons. Allowing successful voice interactions without generating a traceable record creates a gap in governance and customer interaction auditing.Even if the current behavior is technically expected, organizations should have the option to maintain a ticket-based audit trail for all customer interactions, including those involving suspended users.Requested EnhancementProvide a configurable option that allows administrators to:Automatically create suspended tickets for phone calls from suspended users. Retain call recordings and associated metadata. Ensure all customer interactions remain auditable and discoverable within standard Zendesk workflows. Generate reporting and analytics for these interactions in the same way as other customer contacts.
I manage 3 teams who are contactable using 1 number. Each team has it's own option on the IVR.2 of the teams have identical business hours.The other team has different business hours. I have been advised that it is not possible to set a different schedule to their IVR option which seems to be a fairly basic request. Can this be looked at in development.
Feature Request Summary: I like to be able to restrict a zendesk talk line to a specific group. Description/Use Cases: Our operations team is divided in several groups (Delivery Service, Partner Service and Customer Service) each team has their own talk line. To prevent that, Customer Service is using the Talk line which belongs to Partner Service I would like to restrict the lines so whenever Customer Service is making an outbound call, they can only use the talk lines which have been assigned to the Customer Service team. Business impact of limitation or missing feature: The current setup can lead to confusion. Customers are being called with incorrect phone numbers, which means when a customer calls back they are reaching the wrong department, which will have an impact on the workflow and productivity.
With three different brands and multiple departments each having their own phone number, along with direct dials for agents, we currently have 73 phone numbers associated with our account. When agents make outbound calls to customers, they often need to switch phone numbers depending on the brand they are calling from. While the new feature of searching for an outbound phone number is helpful, it still causes delays as agents have to navigate through or search among the 73 numbers. If we could implement group-specific outbound phone numbers, agents would only need to select from a small dropdown menu, simplifying the process and speeding up calling a large customer list.
We're about to roll out Zendesk Talk to our Team but the ring tone is not being well received by our agents. Is there anyway to provide control over the ring tone or volume other than having agents turn down their system volume or muting the site? We're coming from a system that provides ring tone customization and volume control. Thanks!
Our team is a month in to using Zen Voice. We would love to be able to change the ringtone for incoming calls. Our reps have nightmares of the default ringtone after work away from the phones. A choice of ringtones or being able to upload our own ringtones would be fantastic. Also, do you think it'd be possible to give us some keyboard shortcuts for Voice? For example: hanging up.
Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue [ex. agents, admins, customers, etc.] (2-3 sentences)More control over Entity detection - include plurals, not include words as “misspellings” if they are a different word with a different meaning OR allow adding antonyms, so similar words could be proactivelly expluded. This affects the admins and data team. What problem do you see this solving? (1-2 sentences)Reporting is a really key feature for us and has to be precise, the more control we have over how entities get detected, the more acurate the data and reporting. When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)We are currenly setting up our instance and noticed this in testing, we have to get this right as there can be a serious organisational impact if we don’t. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)As far as we know there isn’t a workaround for this. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Entity is able to detect synomyms and plurals of synonims, correctly notes misspellings and we could add antonyms too - words to be activelly excluded because they are similar to other words and captured as misspellings or because they can have multiple meanings.
Currently, we can configure and populate most ticket fields dynamically through Sunshine Conversations Actions. However, the ticket form selection itself cannot be defined this way. Accorditng to Product, the curren alternative is to use triggers to change the form after ticket creation — which forces us to maintain two separate configurations: One Action in SunCo for ticket creation; One Trigger in Zendesk Support to adjust the form afterwards. This creates duplication and makes maintenance more complex, especially when multiple forms or brands are involved.Proposed SolutionAdd support for a "ticket_form_id" parameter in Sunshine Conversations Create Ticket Actions, allowing us to define the form directly at ticket creation time. Benefits Simplifies setup by removing the need for additional triggers Reduces risk of misalignment between Actions and Triggers Makes Sunshine Conversations actions more powerful and self-contained Streamlines implementation for multi-brand or multi-form environments
ProblemAction Flow branching today supports only a binary split: If condition is met / Else.When a value can be one of many options (for example channel, brand, group, status, or any categorical field), there is no native way to route the flow into N paths in a single step.Current workaroundWe nest multiple Branch steps under each Else path (if A → … else if B → … else if C → …). This works, but it quickly becomes hard to read, maintain, and review—especially as the number of cases grows. It also increases the risk of configuration mistakes and makes simple process changes expensive. Requested improvementAdd a multi-way branch step (switch / case), for example:Evaluate one variable once Define multiple cases (value equals A, B, C, …) Provide a default / else pathIdeal extras (nice to have):Match operators beyond exact equals (contains, is one of, is empty) Reusable case labels for clarity in the canvas Clear validation when cases overlap or a default is missingWhy it mattersMany real support processes are categorical (“for each X, do Y”), not binary. A native multi-way branch would reduce nesting, improve readability of production flows, and make Action Builder closer to how teams already model these processes.Expected benefitCleaner flows, fewer nested branches, faster edits, and lower maintenance cost for automations with multiple mutually exclusive paths.
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
