Discuss ideas, submit feedback, and track what's next
Help us understand your request
An intake-ready template
I’ve been using Zendesk for 10+ years and have always considered it to be one of the better Support CRMs out there. However, the current implementation of their AI-fronted support is a step backward in my opinion. While their Support has always been less than stellar, it seems to have degraded with the introduction of their AI tooling. The 'help' chat currently suffers from high latency, often taking more than a day for an agent response, which fundamentally breaks the 'real-time' promise of a chat channel - the only channel you offer. Most frustratingly, the handoff lacks persistence; having to recap an entire history every time you need to spin up a new chat is a friction point we shouldn't see in 2026. As a Zendesk user myself, I know there is a way to check a customer's history and locate past conversations - there is no need for me to reiterate a conversation that has already occurred - this is a failure in your support processes. If you're going to lead with AI, the transition to human support must be seamless, easy, responsive, and not a barrier to entry. Given the experience I have had with their current AI tooling, I would not consider using it myself.
We use Glean to find, summarize, and connect customer data across our apps, including Zendesk Support. We need to include customers' Help Center search results and article views in the dataset. Request: Either make the event data available via API or include it in data sent to Segment.
We use Glean to find, summarize, and connect customer data across our apps, including Zendesk Support. We need to include customers’ Help Center search results and article views in the dataset. Request: Either make the event data available via API or include it in data sent to Segment.
From the macro preview screen, when I press Ctrl + A to select all of the comment section, it used to select only the comment portion, but recently the entire browser has been getting selected.When I contacted Zendesk support, they said the behavior changed due to an update.Therefore, I strongly request countermeasures such as adding a comment copy button.マクロプレビュー画面から、コメント部分を全選択しようと Ctrl + A を押すと今まではコメント部分のみ選択になりましたが、最近ブラウザ全体が選択されるようになりました。Zendeskサポートに聞いたところ、アップデートにより挙動が変わったとのことです。ついてはコメントコピーボタンの追加などの対策を強く要望します。
We use 3d party telephony with Talk Partner Edition. The CTI integration is using the Calls API. I've seen it mentioned as planned, but I can only see a few digits available in the new real-time dashboards, and nothing in the Voice datasets. Is there any progress for TPE reporting?
Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue: We use custom metrics and attributes extensively across multiple dashboards in Zendesk Analytics (Explore). When a custom attribute is updated in one report, the change is reflected in that specific dashboard (after publishing) but does not automatically apply to other dashboards using the same attribute unless they are manually republished. This primarily affects admins and analysts who manage reporting, as well as leadership teams who rely on accurate, up-to-date dashboards. What problem do you see this solving? Automatically syncing updates to shared custom attributes across all dependent dashboards would eliminate the need for manual republishing and prevent outdated or inconsistent data from being displayed. It would significantly reduce administrative overhead and the risk of reporting discrepancies. 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? This occurs every time we update a shared custom attribute (for example, adding a new brand condition such as OR [Ticket brand] = "Brand13"). The update appears in the original dashboard immediately, but other dashboards using the same attribute do not reflect the change unless we enter Edit mode, introduce a minor unrelated change, and click “Publish changes.” Browser refreshes, cache clearing, and even device reinstalls do not resolve the issue. Because we maintain tens of dashboards, this creates a repetitive and time-consuming process and increases the risk of missing dashboards that should reflect updated logic. Are you currently using a workaround to solve this problem? (If yes, please explain): Yes. We manually edit each affected dashboard, make a temporary irrelevant change to enable the “Publish changes” button, and then republish the dashboard so that the updated custom attribute is applied. What would be your ideal solution to this problem? How would it work or function? Our ideal solution would be for all dashboards to automatically recognize and apply updates made to shared custom attributes or underlying reports without requiring manual republishing. Alternatively, there could be a “Republish/Sync all dependent dashboards” option that updates every dashboard using the modified attribute in one action
Now that MFA is required daily it would be really helpful if the MFA request could accept ENTER after entering the number instead of requiring to click on the verify button (or TAB, TAB, ENTER as I tend to do). Setting the verify button as the default for the form feels like a simple change
Feature Request Summary: Zendesk Support should have a button that allows Followers for LIGHT AGENTS or AGENTS to be activated BUT turns OFF EMAIL notifications. Description/Use Cases: Our LIGHT AGENT AND AGENT receive notifications in the iOS Zendesk Support app AND can get notifications in the Web Browsers as well, so there is simply no need for email. Business impact of limitation or missing feature: Currently it is basically spam to them as they read their notifications else where. Finally, like many companies these days, Email is simply not used internally so it makes things even more confusing for light agents, agents using email only for external use with business partners. Other necessary information or resources:
Hi Team, We are requesting several enhancements to the Approval feature to address current rigidity in the workflow, specifically the ability to restrict public replies during pending statuses and the support for more complex request logic. This issue affects our support agents and managers who require a controlled and flexible authorization process before we can fully adopt this feature. Addressing these limitations would allow our team to handle sign-offs more efficiently and would prevent the manual overhead currently required to manage typos, parallel workflows, and sequential authorizations. During our evaluation of the approval request feature, we have identified that the "Single Active Request" limit and the lack of automated sequential chains would prevent us from managing tickets that require multiple internal sign-offs. Furthermore, the inability to edit a request once sent means any typo would require a full withdrawal and restart of the process. Without a "hard lock" on public replies during these pending states, there is a significant risk of agents communicating with customers before the internal authorization is finalized, which currently prevents us from rolling this out to our team. Our ideal solution is an updated approval interface within the Agent Workspace that supports editing sent requests, parallel and sequential approval logic, and a toggle to "Disable Public Replies" until the final approval is granted. This would provide the necessary control to ensure agents only communicate with the customer once all required internal sign-offs are officially secured.
Now that MFA is required daily it would be really helpful if the MFA request could accept ENTER after entering the number instead of requiring to click on the verify button (or TAB, TAB, ENTER). Setting the verify button as the default for the form feels like a simple change
Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issueZendesk have recently launched an app for Workday. It would be great to have a similar app for SuccessFactors, as our agents are frequently going between the systems.What problem do you see this solving?To improve agent efficiency by getting the necessary information directly in Zendesk instead of going between the different systems.Are you currently using a workaround to solve this problem?We have added several custom user fields to help workaround this.What would be your ideal solution to this problem?A similar app to what you have created for Workday.
Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.]. The spelling checker might be a useful addition for many, but admins should be able to enable or disable it globally. What problem do you see this solving? A global switch to enable or disable the feature would stop the internal spelling checker from interfering with our system-wide 3rd-party solution.Currently, it always runs in the background without an option to disable it globally. The "disable" option is only per ticket. 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? The issue is present for every agent and every ticket. Are you currently using a workaround to solve this problem? (If yes, please explain) The workaround is to instruct every agent to go into the settings and disable the individual options for spelling, grammar, and style guide to stop the built-in checker from interfering with the external solution. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences) Please add an option in the Admin Center to allow admins to disable this feature globally.
Hi team, Sharing a customer request for your consideration. The customer is implementing complex Liquid logic within webhook triggers and has encountered limitations related to size and reusability.They are requesting a way to define reusable Liquid components or objects that can encapsulate complex logic and be referenced across multiple places (such as webhooks, triggers, or dynamic content). This would help reduce duplication, increase flexibility, and make advanced implementations easier to maintain. Primary use cases include rendering HTML content for emails and outputting full ticket conversations for CSAT workflows.Thanks for taking a look!
We've recently noticed this feature on our account and while this can be a very helpful tool for our agents, I feel there should be an option to manage this in admin centre. We've noticed a dictionary option but so far it looks like the possibility to create one is not enabled. We were wondering if there are any plans to allow this feature to be managed in admin centre rather than leaving it down to each agent to enable/disable.
Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.]:To leverage the Entity functionality of the Zendesk CoPilot add-on effectively and generate real business value, we require the ability to scope Entities to specific ticket forms. Ideally, Entities should also be configurable per brand.In our current setup, Entities are relevant for certain ticket forms but not for others. Since Entities currently apply globally across the entire Zendesk instance, they create confusion in ticket forms where they are not applicable. As a result, agents experience friction and have developed strong resistance toward using the Entity functionality.This primarily impacts agents and administrators, and indirectly affects customers due to inconsistencies in data capture and automation. What problem do you see this solving?Being able to scope Entities to specific ticket forms (and ideally brands) would significantly improve usability and agent acceptance. It would enable us to automatically extract relevant structured information without introducing confusion in unrelated workflows. 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?This limitation affects us continuously, as we are currently unable to activate Entities productively in our environment.Because Entities cannot be restricted to relevant ticket forms, we are forced to choose between a poor user experience (due to irrelevant entity prompts) and a lower degree of automation (by not enabling Entities at all). This directly impacts efficiency, agent satisfaction, and our ability to standardize and scale structured data capture.Background: We support a wide range of different software product families in a central Zendesk brand. Each product family is represented within its own ticket form. These are different product families, but they have similar products and modules.Unfortunately, an entity that makes sense for product A (= ticket form A) not only fails to produce good results for products B, C, D, etc., but also leads to incorrect classification. Are you currently using a workaround to solve this problem?At present, agents must manually enter structured information into custom fields. This process is time-consuming, prone to human error, and reduces the overall automation potential of Zendesk CoPilot. What would be your ideal solution to this problem? How would it work or function?Entities should be configurable at the ticket form level, and ideally at the brand level.The current implementation, whereby an entity applies to an entire Zendesk instance, is not effective if you support many similar products with similar custom tickets in a Zendesk brand.
Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.]:To use the Entity functionality of the Zendesk CoPilot add-on effectively and generate measurable business value, we require the ability to deactivate/remove individual entity values that are automatically derived from Custom Fields (Drop-down or Multi-select types).Not every selectable value in a custom field is suitable for entity detection. Some values are intentionally designed for manual selection by end users or agents (e.g., fallback or generic options) and should not be considered for automatic entity recognition.This limitation primarily affects administrators and agents and indirectly impacts customers due to reduced automation accuracy and consistency. What problem do you see this solving?The ability to deactivate specific entity values would significantly increase the precision of entity detection and prevent incorrect or misleading automatic classifications. This would improve both automation quality and agent trust in the CoPilot functionality. 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?This issue affects us continuously, as we cannot productively activate Entities in their current implementation state.Certain generic or fallback values (e.g., “unknown” or “independent”) are detected disproportionately often, resulting in inaccurate classifications across tickets. Consequently, we are forced to either accept poor automation quality or disable Entities entirely, limiting efficiency and scalability. Are you currently using a workaround to solve this problem?Currently, agents must manually correct or define the relevant structured information in custom fields. This process is time-consuming, error-prone, and undermines the intended automation benefits of the Entity functionality. What would be your ideal solution to this problem? How would it work or function?Administrators should be able to deactivate individual entity values so that they are excluded from entity detection while remaining available in the underlying custom field.Example:If entity detection is used to automatically determine the relevant module or component, the entity may include a full list of modules (A–Z) as well as fallback values such as “unknown” or “independent.” These fallback values should remain selectable in the custom field but be excluded from automated entity detection.Without this granularity, generic values are over-detected, leading to systematic misclassification across the Zendesk instance.
Hello, First of all, the latest Agent Workspace updates are really appreciated — especially the tab highlighting for the currently active ticket. Great improvement! However, in our daily operations, many agents regularly work with 15 to 25+ open ticket tabs simultaneously. This is common across multiple teams as agents need to cross-reference tickets, follow up on ongoing cases, and handle several topics in parallel. The request: It would be extremely helpful to have the ability to group open ticket tabs into sub-groups within the Agent Workspace, similar to what modern browsers like Chrome or Edge offer natively with their tab grouping feature (collapsible, color-coded groups). Use case examples — how our agents would use tab groups: "Urgent / Prioritaire" — quickly isolate and visually identify critical tickets that require immediate attention, avoiding them getting lost in a crowded tab bar "Same customer / organization" — group all open tickets from the same customer to get a full overview of their ongoing issues and avoid redundant communication "Ongoing escalations" — keep track of tickets escalated to L2/L3 or linked to external tools (e.g. Jira), waiting for resolution "Pending customer reply" — tickets awaiting a customer response, to check back on regularly without cluttering the active workspace "Portability / Orders" — group tickets tied to multi-step processes (number porting, order fulfillment) that require continuous follow-up over several days "By ticket form" — group tabs by form type (Incident, Service Request, Portability, Order…) to naturally compartmentalize different workflows Expected benefits: Faster navigation and better visibility for agents handling many tickets at once Reduced risk of losing track of critical or time-sensitive tickets Improved productivity, especially for teams that rely on keeping multiple tickets open for verification and cross-referencing Flexible grouping adapted to each agent's workflow — by priority, customer, process, form type, or any custom criteria Context: We are a B2B telecommunications operator with agents who frequently juggle numerous tickets throughout the day across different brands and workflows. The current flat tab bar becomes very difficult to navigate beyond 10-15 tickets. A collapsible, color-coded tab grouping system — similar to browser tab groups — would make a significant difference in daily efficiency and agent satisfaction. Thank you for considering this enhancement
Hi,We’re using Intent detection, and one limitation we keep running into is that intent seems to be based only on what the requester writes.In many cases the real intent becomes clear after the agent has asked follow-up questions, or when the agent summarizes the issue in their reply.It would be really useful if intent could be generated based on: the full ticket conversation, and/or the agent’s messages (agent-side intent) This would improve both routing and reporting, especially for more complex tickets where the first customer message is vague.
Hi all,Is it possible to have a timestamp for call answer and call end times? I would have expected these to be very basic fundamental things to report on, but apparently not. Has anyone else tried to report on this?After working with ChatGPT a little I was able to work out how to create a custom attribute for a rough end time by subtracting the call duration from another timestamp, but I think the timestamp I had to work with was the call connection to ZD not the time the agent answered. If I can get an accurate representation of the actual answer time (Leg - Timestamp covers too many things imo) then I can subtract just fine, but I don't know if I can even get that.I really don't understand why these two values are seemingly so difficult to do.
I need help. There are a lot of things I don't know about the zendesk set up. I try to reach for support. And someone has the audacity to reschedule and cancel the session at the appointment time wihtout communication as to why.
Our forms would benefit from a conditional Multi-select field. We currently have multiple check boxes that are conditional (opens another text box). This is a bit unappealing to the customer/end-user-facing form. I'd like to request that this and all other fields are added to be used conditionally.
SummaryEnhance Zendesk Support triggers and automations to provide: The ability to dynamically evaluate Help Centre User Segment membership as a condition Clear and granular conditions to distinguish between Requester, Submitter, Agent creator, and System/API-created tickets Full conditional control over CC identification, addition, and removal These enhancements would materially improve notification accuracy, SLA precision, compliance control, and customer experience.1. Help Centre User Segments as Trigger ConditionsProblemHelp Centre User Segments are a powerful mechanism for controlling content visibility in Guide, but they cannot currently be used as dynamic conditions within Support triggers or automations.There is no way to: Evaluate whether a requester is in a specific User Segment Use segment membership as logic in notification workflows Select segments from a dropdown list within trigger conditions This creates a disconnect between: Knowledge visibility strategy Support workflow logic Proposed SolutionAdd a trigger/automation condition:Requester is in User Segment → [Selectable Segment(s)]With capabilities to: Dynamically evaluate membership Select one or multiple segments Use both positive and negative logic (is / is not in segment) Use CaseSegment-based customer groupings (e.g. Partner, Regulated Client, Premium Tier) should be usable to: Deliver different notification wording Adjust SLA logic Control escalation workflows Currently, organisations must duplicate logic via custom fields or external systems, creating governance risk and duplication.Impact Stronger alignment between Guide segmentation and Support workflows Reduced reliance on custom workaround fields More scalable enterprise-grade workflow governance 2. Expanded Ticket Origin Attribution in TriggersProblemZendesk currently limits trigger conditions primarily to the Requester and provides insufficient granularity for distinguishing: Submitter (ticket creator) vs Requester Full Agent manually creating a ticket Light Agent forwarding/creating a ticket System/Automation/API-created tickets Email-forwarded tickets where creator differs from requester For organisations that frequently create tickets on behalf of customers, this creates significant workflow limitations.Primary impact: Notification wording must differ depending on who created the ticket Current condition sets are insufficiently granular Secondary benefit:SLA policies could be more precisely appliedProposed SolutionExpand trigger/automation condition sets to include: Ticket Created By Type End User Full Agent Light Agent Automation API System Forwarded Email Explicit conditions for: Submitter role Submitter vs Requester mismatch Agent-created-on-behalf-of scenarios Example condition:Ticket creator role is Full AgentAND Requester role is End UserThis would enable deterministic workflow control.Use CaseIf: A full agent manually creates a ticket and sets an end user as the requester A light agent forwards an email on behalf of a customer A ticket is generated by API or automation Then: Confirmation wording must differ Autoresponders may need suppression SLA policies may differ Currently, this requires brittle workarounds or cannot be reliably achieved.Impact More accurate and context-aware notifications Reduced customer confusion Improved SLA governance Better enterprise workflow transparency 3. Conditional CC Identification, Addition, and RemovalProblemTriggers can add CCs in limited ways but cannot: Reliably detect whether a specific user is already CC’d Remove specific CCs conditionally Dynamically manage CC lists based on compliance or workflow logic This creates operational and compliance challenges.Example scenario:A customer emails both the support team and a regulator in a single message (as required by regulation).Current issue: The regulator receives Zendesk autoresponses The regulator continues receiving agent updates Agents must manually remove them Regulators have complained about unnecessary email noise There is no robust trigger-based method to detect and remove a specific CC address once the ticket is created.Proposed SolutionEnhance trigger/automation capabilities to:Add conditions: CC list contains [specific user/email] CC list does not contain [specific user/email] Add actions: Add specific CC Remove specific CC Remove CC if condition met Allow this to be used in both triggers and automations.Use Cases Regulatory compliance communications Contractual stakeholder visibility Partner-based notifications Suppression of autoreplies to third-party recipients Operational routing control Impact Improved compliance governance Reduced email noise for regulators and partners Improved customer experience Reduced manual intervention and agent error Business ContextSuite Enterprise customers require deterministic workflow control aligned with: Regulatory obligations Contractual requirements Complex multi-party communications Enterprise-grade notification logic Current limitations require API-based workarounds or manual processes for functionality that logically belongs within triggers and automations.Current Workarounds Custom fields duplicating segment logic External reporting tools (e.g. Power BI) to infer creation context Manual CC removal Suppression rules that are brittle or incomplete API middleware to retrofit missing logic These add operational overhead and governance risk.Overall ValueThese enhancements would: Close the gap between Guide segmentation and Support workflows Provide enterprise-grade workflow determinism Reduce integration complexity Improve customer and partner experience Strengthen compliance and SLA control
Quick overviewI would like to request a way for Zendesk Admins to manage a centralized dictionary or glossary that can be deployed across the entire organization. Currently, this affects our Admins/Content Team, who cannot ensure brand consistency, and our agents, who find the tool distracting when it flags correct technical terms or companies/customers names as errors. Problem this would solve This would allow for organization-wide consistency in communication by ensuring that specific industry terms and brand names are recognized as correct for every agent instantly. It would increase adoption of this native feature and allow us to move away from third-party alternatives. Last time we were affected by this lack of functionality; what happened and how often does this problem occur. Impact on our business We were affected by this since the recent rollout of the new spelling and grammar checker. Because we have no way to pre-load our technical glossary, agents are seeing constant error flags for correct brand-specific terms, which disrupts their workflow. This problem occurs daily and prevents the tool from being a viable replacement for our current paid software, as the manual effort required to "train" the dictionary individually is too high and not reliable. Current workaround we use to solve this problemBecause agents find the manual dictionary updates tedious and we are not encouraging to create their own dictionaries, they are simply disabling the native tool entirely. Instead, they continue to use a separate paid application that we are currently forced to maintain to ensure our technical terms are correctly handled. Ideal solution to this problemI would like to see a "Global Dictionary" setting in the Admin Center closer where we can find the other Writing tools settings. Ideally would be a place where we can upload a CSV file containing our specific glossary of terms. These words should be automatically recognized and pre-approved for all agents across the account without requiring individual manual updates.Thanks!Luiza Maués
In Zendesk, each comment on a ticket a time the comment was made on the right side of each comment. However, if the comment was made in the past 7 days, Zendesk only shows the DAY the comment was made and not the DATE. For example, a comment made two weeks ago will show something like "Mar 02 17:49". But a comment made 6 days ago will show as "Thursday 08:47". I do not like this latter version. How do I get all comments to show like this: "Mar 02 17:49"?
Currently, I use the "Actions and Events" feature for Inactivity with a trigger that, if a user becomes inactive, activates a use case that directly transfers the call to a human agent.The point is: often, my human agent sends an active WhatsApp message with two buttons that activate use cases, one of them being "I can't talk now," which triggers a thank you -> closing use case. The problem is that after triggering the use case, the bot understands that the user has become inactive and performs the transfer anyway, because I can't choose which use case I want to apply this action + trigger to, since it's at the AI Agent level.I would like it to be possible to select in which use cases this action + trigger is applied.
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.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
