Product feedback | The place for Zendesk users to come together and share
Skip to main content

Filter by feedback status

Filter by product

7809 Requests

Eric134Newcomer

PRODUCT FEEDBACK: Allow individual tasks within a Task List to be marked as requiredUnder review

Description:Zendesk’s native Task lists only completion control available is a single list-level setting, “Require all tasks to be marked as complete before solving,” which is all-or-nothing: either every task in the list blocks the ticket from being solved, or none of them do. There is no way to mark specific tasks within a list as required while leaving the rest optional. A single list may almost always mixes mandatory steps with steps that are conditional or only sometimes applicable. That leaves two poor options: make the whole list required — which blocks agents from solving whenever an optional or not-applicable step was not ticked — or make the whole list optional, which removes enforcement from the steps that must not be skipped.  Requested EnhancementPer-task required flag: allow admins (or role specified) to mark individual tasks within a task list as required, so that only those tasks block the ticket from being solved, while the remaining tasks stay informational and optional.Coexistence with the current setting: keep the existing list-level “Require all tasks to be marked as complete before solving” option as a shortcut, and let per-task settings take precedence when the list is not fully mandatory but specific tasks are.Clear solve-time feedback: when an agent attempts to solve with required tasks still open, name the specific outstanding required task(s) rather than returning a generic “complete all tasks” message.Consistency across automation: honor the per-task required rule regardless of how the list was added — manually by the agent or automatically through action flows — so enforcement does not depend on the assignment path. Business ValueLets a single reusable list serve several scenarios without forcing agents to tick irrelevant steps simply to clear the solve block.Enforces mandatory compliance and regulatory steps (identity/KYC verification, Responsible Gambling actions, document checks, recording a regulatory reference) while leaving genuinely optional steps optional.Reduces false completion — agents checking off steps they did not actually perform, only to be able to solve the ticket — which otherwise corrupts the record of what was really done.Cuts task-list sprawl: there is no longer a need to fork a near-identical list per scenario just to vary which steps are mandatory, keeping us well within the 100-list / 20-task limits.Gives agents clearer guidance and fewer solve-time errors, and gives us a defensible, per-step record of which required actions were completed on each ticket. Use CaseWe operate multiple brand instances in a regulated market, where many ticket types carry a mix of legally mandatory and best-effort steps on the same checklist. On a complaints, document-verification or Responsible-Gambling-flagged ticket, for example, verifying the player’s identity, logging the RG action taken and recording the regulatory reference are mandatory, while attaching a screenshot, adding an internal note or notifying another team are conditional or situational. With only all-or-nothing enforcement, we must either make the entire list required — in which case agents cannot solve a ticket when a conditional step legitimately did not apply — or make the list optional, which strips enforcement from the compliance-critical steps where it matters most. In a regulated environment the enforcement of those specific steps is the entire point of the checklist. Per-task required settings would let the compliance-critical steps hard-block the solve while the remaining tasks continue to guide the agent without blocking, giving us one reusable list per ticket type that is both enforceable where it has to be and flexible everywhere else.

Eric134Newcomer

PRODUCT FEEDBACK: Show task-list events in Explore — per-item completion reporting, ticket counts, and agent breakdownsUnder review

Description:Zendesk’s native Task lists guide agents through predefined steps inside the ticket, but the activity they generate cannot be reported on. There is no Explore dataset, metric, or attribute for task-list events, so it is not possible to build a report or dashboard showing task completion. As a result, once task lists are in use we have no visibility into whether the steps they define are actually being completed, by whom, or on which tickets, unless we open each ticket individually. Requested EnhancementTask events in Explore: expose task-list activity as a reportable dataset (or as metrics and attributes within the Support datasets), including task completed, task not completed / skipped, and the agent and timestamp for each event, so that reports and dashboards can be built on task activity.Per-item granularity: make each task item individually reportable — not only list-level totals — so a specific step can be reported on its own, identified by its task list and task name.Completion counts: provide counts of tickets on which a specific task-list step was completed, and conversely not completed, filterable by task list, task item, date, group, brand, form and ticket status.Agent breakdowns: allow task completion to be sliced by the agent who completed or did not complete each item, and by assignee and group, so we can distinguish agents who did versus did not complete a task list or a given task item. Business ValueGives visibility into whether defined steps are actually being followed, instead of configuring lists blind and having no feedback on adoption or adherence.Lets us evidence completion of mandatory compliance and regulatory steps (identity/KYC verification, document checks, etc) at the individual-step level — a requirement for a regulated operator.Supports QA and coaching by identifying agents or groups who consistently skip specific steps, rather than only seeing aggregate ticket outcomes.Enables process-health and adoption dashboards (which lists and steps are used, completed, or skipped), so task lists can be refined on evidence instead of assumption. Use CaseWe run multiple brand instances in a regulated market and use task lists to standardize the mandatory steps on complaints, document-verification and risk processes. Once a list is live, we currently cannot tell whether agents completed the steps, which steps are routinely skipped, or how completion differs between agents, groups or brands — the data is neither in Explore nor, in any usable form, in the audit log, which only shows when the list templates themselves were edited. For compliance we need to show, per step, on how many tickets a required action (identity verification, action logged, regulatory reference recorded, etc) was actually completed and by whom, and to flag agents who solve tickets without completing specific items. Per-item task reporting in Explore, with ticket counts and agent/group/brand breakdowns, would let us build a single dashboard to monitor process adherence and produce defensible evidence of compliance-step completion, instead of having no reportable record of task activity at all.

Eric134Newcomer

PRODUCT FEEDBACK: Add role-based permission controls for task lists — managing lists and adding them to ticketsUnder review

Description:Zendesk’s native task lists have no role-level access control. There is no custom-role permission governing who can create, edit, or delete task lists, and no permission or per-list setting governing which agents can add a task list to a ticket. The full custom-role permission set contains no task-list entry under any category, and task lists themselves expose no access configuration. In practice this means managing task lists is gated only by whether a team member has admin-level access to the Admin Center at all, and adding a task list to a ticket is available to any agent in the Agent Workspace who has lists available. We cannot scope task-list creation, management, or usage to specific roles or groups, even though every adjacent object — views, macros, triggers, ticket forms and fields — can be governed this way.Requested EnhancementRole-based permission to manage task lists: a dedicated custom-role permission (view / create / edit / delete) for task lists, so managing them can be granted to specific roles without granting broader Admin Center access.Control over adding a task list to a ticket: a setting — per role, or per task list — that determines which roles or groups can add a given list to a ticket, so a list meant for one team isn’t available to everyone.Per-list scope: optionally scope each task list to specific brands, groups, or roles, so a brand- or team-specific checklist only appears where it applies.Business ValueEnforces least privilege: only the people responsible for process design can change the checklists agents are required to follow.Keeps the right lists on the right tickets in a multi-brand instance, instead of every list being addable to every ticket regardless of team or brand.Protects the integrity of mandatory and compliance steps — in a regulated operation, who can alter a required-steps list matters as much as the steps themselves.Reduces clutter and error, because agents only see and add the lists relevant to their role and brand.Brings task lists in line with the role-based control model already applied to views, macros, triggers, forms, and fields.Use CaseWe run multiple brand instances in a regulated market, with distinct teams  and brand-specific processes. Task lists encode the steps each team must follow, including mandatory compliance steps. Today any agent with workspace access can add any available task list to any ticket, and task-list management is not scoped by role. We need to let only designated process owners create and edit task lists, without handing them broader admin rights, and to scope which roles or groups can apply a given list. Role- and group-based controls for task lists would bring the feature in line with how we already govern views, macros, and forms, and make it safe to roll task lists out across brands.

Create a ticket (with call recording) when an IVR routes a call to an external numberAccepted

When an IVR menu option routes a caller to an external phone number, Zendesk Talk stops recording and no ticket is created. Zendesk support has confirmed this is by design. We'd like an option — ideally a per-route toggle — to keep recording and generate a ticket for these calls, matching the behavior that already exists when the same external number is configured as a fallback number.We use Talk for daytime support and route after-hours callers to an external number that fronts our on-call paging system (PagerDuty Live Call Routing), so a responder is reached directly.Originally that number was set as the fallback for when agents were unavailable. In that configuration Zendesk created a ticket with the call recording attached, so every after-hours call landed in Zendesk automatically.We then moved this to an explicit IVR menu option, which is the correct setup for us — callers choose after-hours support rather than reaching it by falling through an unanswered queue. Since that change, no tickets are created and no recordings are retained. The routing works, but the record of the call disappears.The inconsistency is the core issue: the same external destination produces a full ticket record via fallback routing and nothing at all via IVR routing, even though the business event is identical.Business impactNo audit trail. After-hours calls exist only in the external system. There is no Zendesk record that a customer called, when, or about what. Lost agent context. Daytime agents or after-hours responders pick up with no ticket, no caller ID, and no recording to reference. Reporting gaps. After-hours volume is invisible in Talk and Explore reporting, so we can't size on-call coverage or justify staffing. QA and compliance. We can't review after-hours call handling, and recordings we're expected to retain aren't captured. Manual reconciliation. Someone has to cross-reference the paging system against Zendesk and open tickets by hand. 

Madalina11
Madalina11Newcomer

Automatic translations for embedded templates in Advanced AIFeedback submitted

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)The embedded templates supported by the Advanced AI do not currently support automatic translations, compared to the Essentials bot builder. I would like to suggest for this feature to be added for embedded templates. What problem do you see this solving? (1-2 sentences)Withe the Essentials bot builder we only had to create the flow in English and could rely on the automatic translations for all the languages we support in. We have two brands, one supporting in 16 languages and another one supporting in 39 languages. While I understand that some industries may wish to use manual translations due to sensitive terms being used, I find that removing completely the automatic translations from this feature is impacting a lot of customers who could actually benefit from this in the embedded templates.We could make a lot of use of these embedded templates, but are currently limiting our workflows to use as few as possible because manual translations are time consuming especially in our case. Not to mention that whenever we make a small change in the default English template this has to be manually changed for each language individually.  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)The embedded templates have been released without automatic translation and impacted us as soon as we started migrating to Advanced AI as our planning did not take into account time needed and costs for manual translations. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)As a workaround, we are trying to avoid using templates and have only created them if absolutely necessary. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Ideally, the templates should support automatic translations with the possibility to add manual ones for customers who might require precise translations for more sensitive areas as health or IT services.This would allow all customers to benefit from using templates in the best way suitable for their business. 

YoanNewcomer

Include Zendesk subdomain or account identifier in all account-specific automated emailsUnder review

We manage multiple Zendesk instances and regularly receive automated Zendesk communications relating to account-specific changes, required actions, product updates, or reminders. These emails often do not identify which Zendesk instance they apply to, making it difficult for administrators managing multiple accounts to determine which environment requires attention.Account-specific automated emails should clearly identify the affected Zendesk account. Without the subdomain or another unambiguous account identifier, administrators must investigate separately or contact Zendesk Support to determine which instance the communication relates to.This is a recurring issue across different types of Zendesk communications. Most recently, we received an “Important Zendesk reminder: Transition to OAuth refresh token flow and token expirations” notification that did not clearly identify the affected instance. We have experienced the same issue with notifications concerning the removal of the Help Panel for accounts with Admin Copilot, outbound SMS pricing, and an incorrect Zendesk QA notification. In several cases, we had to contact Zendesk Support to identify the relevant subdomain, and in one case the initially provided subdomain was incorrect and later had to be corrected. Zendesk Support has also previously acknowledged that the lack of a subdomain or account ID makes these notifications unclear.Administrators currently have to investigate the applicability of each notification internally or contact Zendesk Support to identify the affected account. This creates unnecessary administrative overhead and can delay action on time-sensitive communications.Our ideal solution is that whenever Zendesk sends an automated communication relating to a specific account, the affected Zendesk subdomain or account identifier is included. Ideally, the subdomain should appear directly in the email subject, for example: “[example.zendesk.com] Important Zendesk reminder: Transition to OAuth refresh token flow and token expirations.” At minimum, the affected subdomain or account ID should be prominently displayed in the email body.

Heather24Newcomer

Customer's chatbot messages truncated in ticketsFeedback submitted

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)Many of our customers start their Support journey through the chatbot/AI agent tool on our help site. This gives them the option to continue the conversation with a human agent via ticket through a ‘Get in touch’ form.We logged on this morning to find that how these forms are displayed in the resulting ticket has changed. Previously, we could see, at one glance, the entire message the customer submitted through the form. Now the message is truncated after 33 characters. My human agents now have to hover their cursor over the truncation to see the rest of the message in full – in a tooltip. Why did this change happen? And how do we undo it? What problem do you see this solving? (1-2 sentences)No idea what problem this change was apparently solving. It’s now more difficult for my human agents to read the most important part of the customer’s message, and we had no need to save any space in the ticket (which truncation is typically for). Please undo this change so that my human agents don’t need to spend time hovering their cursors and reading the most important part of the customer’s message from tiny tooltips. 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)This changed occurred for us on October 21st, 2026. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)Hovering over the truncated message to read the rest in a tooltip. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Undo the change where chatbot/AI agent form messages are truncated in the ticket to 33 characters. 

Zendesk Merge Tickets UI Improvement RequestAccepted

What is your request?We would like Zendesk to improve the new Merge Tickets UI so that it does not interfere with an Agent’s ability to answer incoming phone calls. Agents should be able to access incoming call controls at any point during the ticket merge process. (See Image below)What problem would this solve?Currently, the new Merge Tickets sidebar drawer obscures the phone controls, preventing Agents from easily answering an incoming call while merging tickets. Agents must either exit out of the sidebar drawer or complete the merge before they can answer the call. This creates an unnecessary conflict between routine ticket management and the ability to provide timely live customer support.When did this issue last affect you? How often does it happen and what impact does it have?This issue started with the ticket merge enhancements rolled out on 9/2/26. It continues to affect our teams during normal Talk workflows whenever an Agent is merging tickets and receives an incoming call. Because an Agent may need to exit or complete the merge process before answering, incoming calls can be missed, potentially increasing customer wait times and disrupting Agent workflow. A routine ticket-management task should not prevent an Agent from responding to a live customer.Are you using any workarounds?We do not currently have an effective workaround. Agents can wait until they are in Away status before merging tickets, which prevents live calls from being routed to them. However, this requires Agents to interrupt their normal availability simply to perform a routine ticket-management task and does not provide a practical solution during normal Talk workflows.What would your ideal solution look like?Ideally, Zendesk would ensure that incoming call controls remain visible and accessible throughout the Merge Tickets process, and the sidebar drawer would no longer block Agents accepting live calls. Live calls should remain actionable regardless of whether an Agent is in the middle of merging tickets, allowing them to answer an incoming call without having to cancel, exit, or complete the merge first.   

Petra11Newcomer

Admin Co-Pilot MisinformationFeedback submitted

1. What is your request? Who does it affect in your organization? Please improve the accuracy of Admin Copilot when it gives step-by-step guidance on analytics, triggers, automations and similar configuration. It currently suggests conditions, fields or data sets that don't exist in Zendesk. This affects me and my colleague, who both administer Zendesk.2. What problem would this solve? Admins would be able to rely on Copilot's instructions without first checking whether the functionality exists. It would also stop us wasting time following steps that lead nowhere.3. When did this issue last affect you? How often does it happen, and what impact does it have on your work? It last affected me today, and I've attached screenshots of the example. It happens in about 2 out of 3 of my requests for guidance, usually after I've already tried to find the solution myself. Copilot gives confident steps, and I only find out they're wrong when I can't locate the condition or data it names. When I point this out, it recognises the error and reassesses. The impact is lost time and less trust in Copilot for admin tasks.4. Are you using any workarounds? Yes. I check each suggested step in Zendesk as I go, then tell Copilot in the chat when something doesn't exist so it corrects itself.5. What would your ideal solution look like? Copilot would only recommend conditions, fields and data sets that exist in Zendesk. Where it isn't sure a feature exists, it would say so rather than present it as fact. 

Kirill12Newcomer

PRODUCT FEEDBACK: "Mark all as complete" button for task listsFeedback submitted

PRODUCT FEEDBACK: "Mark all as complete" button for task listsDescription:Agents can currently mark task list items complete only one at a time, by ticking each task individually. There is no way to complete all tasks in a list at once, and no corresponding way to reset them all. When all steps have already been done, or are not applicable to a particular ticket, the agent still has to click through every task before a task list configured to require completion lets them solve the ticket.Requested Enhancement"Mark all as complete" button: add an action at the task list level (a button or an entry in the task list options menu) that marks every task in the list as complete in one click, together with a matching "Mark all as incomplete" action to undo it.Admin control: add a setting on each task list that lets admins disable bulk completion, so lists that require per-task confirmation can keep that behavior.Audit trail: record a separate completion event for each task affected by the bulk action, so the task list history and the Task List Events API look the same as when tasks are ticked individually.Business ValueRemoves repetitive clicks from every ticket where the steps are already done or do not apply, which saves agent time at scale.Keeps the required-completion control intact where it matters: admins decide per list whether bulk completion is allowed, and every task still produces its own audit event.Brings task lists in line with checklist tools in the Zendesk Marketplace, some of which already offer a "set all to done" action.Use CaseWe use task lists to give agents a standard set of steps for common ticket types, and some lists require every task to be marked complete before the ticket can be solved. In many tickets the agent has already completed the work, or several tasks do not apply, but the only way to satisfy the requirement is to tick each task one by one. A "Mark all as complete" button would let the agent confirm the whole list in one action. A per-list admin setting would let us turn it off for lists where individual confirmation is mandatory, and per-task audit events would keep our reporting and traceability unchanged. We use a GDPR cleanup task list that support engineers must complete before a ticket can be solved. Its items cover cleaning up customer files and data once the interaction is over. On some tickets the list is not really applicable, or there is nothing to purge from the customer's files, but the engineer still has to open the list and click every item separately before the ticket can be solved. A "Mark all as complete" button would let the engineer confirm the whole list in one action when nothing needs to be removed. A per-list admin setting would let us disable it on lists where individual confirmation is mandatory, and per-task audit events would keep our traceability unchanged.

Jakub20Employee

.md files support in Messaging sessionsFeedback submitted

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)The customer would like .md files to be supported as attachments in messaging sessions. Support agents are affected when they need to exchange Markdown files with customers; customers may also be affected when those files are part of a support request.What problem do you see this solving? (1-2 sentences)It would let agents and customers share Markdown files in messaging without receiving an “extension is not allowed” error. The account’s allowed file types setting currently lists .md, but messaging uses a separate fixed list that does not include it.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)The issue was reported on October 15, 2026, after an agent received an error while trying to upload a .md file during a messaging session. The customer confirmed that other agents had experienced the same issue and that it happens with all .md files they tried. The audit does not specify how often agents attempt these uploads, but the issue occurs whenever they try to attach a Markdown file in messaging. The customer described the issue as slowing them down.Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)No workaround was mentioned in the audit.What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Allow .md files to be attached in messaging sessions, ideally honoring the file extensions configured in the account’s allowed file types setting.

Web11
Web11Newcomer

FEATURE REQUEST: End users to manage contactsFeedback submitted

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 request self-service contact management capabilities for end users within the Support Portal. This directly impacts our internal support agents and Zendesk admins, who spend hours on repetitive data entry. What problem do you see this solving? (1-2 sentences)We are B2B and the majority of our end users are schools or managed service providers. This means their contacts change either from staff members leaving or a new contact being assigned to them via an MSP. We get a high amount of tickets (300+ this year so far) and our admin team spends a lot of time adding / updating and deleting end user contacts. Serving B2B clients with high turnover (schools and MSPs) requires constant contact updates. Without self-service user management, our internal support team must manually add, edit, and delete end users rather than focusing on core support issues. 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)This occurs daily; we average at least 6 tickets per week and have logged over 300 user-management tickets this year alone. It artificially inflates our ticket backlog and burns significant agent hours on low-value data entry. That’s over 300 tickets for our support team that are only generated because we’ve decided to use Zendesk. 300 tickets that should never have to be logged. 300 tickets that are not to do with the product suite we provide. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)We have end users submit a specific form that goes to our Zendesk admin team when they need to add/update or delete a contact at the organisation. This still generates support tickets and is an unnecessary addition to our backlog. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)There’s two parts to this request. My ideal solution and a solution I can live with.Solution 1:On an end user’s profile within Zendesk we have the following options:Can view and edit own tickets only Can view tickets from user’s org.We propose a third option:Can view and edit end user’s within their org.With this option enabled they can go to Organisation:(This is a mock image generated)That would then take them to a User Management page that would look like this:(This is a mock and obviously replicates our current theme)​​​​​​This would allow the “Super Admin” to be able to see who is able to log tickets for their organisation, view their profile (see what tickets they have raised, what role they have i.e can they only raise tickets themselves? or for the organisation?), they can edit the user (optional can live without this) or they can delete/ archive a user.Solution 2:We can settle for just visibility of users that way they can stay on top of this list more often, we can add it to start of year checklists and we don’t run the risk of incorrect data. We very rarely get end users telling us when someone has left the organisation as they have no idea who can represent their organisation.   Additional:Not required but a “would be nice” would be giving end users the ability to add users via CSV.

Convert Internal Notes to Public Comments & Disable Auto‑Internalization for Non‑ParticipantsAccepted

Hello Zendesk Product Team,Our organization relies on email‑triggered workflows in Zendesk and also, we have to manage long‑running tickets that involve many collaborators. We have encountered two key pain points that hinder visibility and slow down our processes: No “Make Public” for Internal NotesOnce the system action converts a comment into an internal note, there is no built‑in UI or API method to revert that note back into a public reply. Agents must manually copy & paste note content into a new public comment, which is time‑consuming and error‑prone. Automatic Internal Note for Non‑ParticipantsBy default, any inbound email from a user who is neither the ticket requester nor on CC is automatically classified as an internal note. This prevents requesters or CC’d collaborators from seeing important updates from third‑party respondents, causing confusion and delays in collaborative threads. Requested Enhancements “Convert to Public” Functionality: Provide a way—either via the UI (a “Make Public” button) or an API endpoint—to convert existing internal notes back into public comments without manual copy‑paste. Configurable Auto‑Internalization: Add a tenant‑ or user‑level setting to disable or customize the rule that automatically marks non‑participant replies as internal notes, so teams can choose to treat all replies as public by default when appropriate. Implementing these features will significantly improve cross‑functional visibility and streamline our ticket collaboration. Thank you for your consideration!

Elsa12
Elsa12Newcomer

Filter which users the AI agent responds to by tag or segmentFeedback submitted

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 need a way to exclude specific users from the AI agent (Advanced) on a given channel, based on criteria such as user tags, user segments, organization or custom user fields. For example, on WhatsApp we want customers with a specific tag to skip the AI agent entirely and go straight to a human agent. This affects our admins, our agents, and the customers who should never be handled by the bot. What problem do you see this solving? (1-2 sentences)As an intermediary between customers and ticket and activity providers, some of the people contacting us need a human from the first message, and an automated conversation creates friction for them. Being able to filter who the AI agent responds to would let us keep the bot for the general public while protecting these specific relationships. 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)This happens every time one of these tagged users contacts us through WhatsApp, because the AI agent activates for everyone on the channel with no way to filter. They have to go through the bot before reaching an agent, which delays resolution and gives a poor experience to contacts we want to treat with priority. Since we can’t segment the AI agent, we are forced to choose between deploying it on the whole channel or not using it there at all.  Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)No, we haven’t found a reliable workaround, since the AI agent’s activation can’t be conditioned on user data. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)An audience or eligibility setting per AI agent and per channel, where admins can include or exclude users based on tags, user segments, organizations or custom fields. Excluded users would bypass the AI agent and be routed directly to a human agent. 

Elsa12
Elsa12Newcomer

Allow removing or customizing the “automatically generated using AI” footer on AI agent replies, per channelFeedback submitted

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 to user an AI agent (Advanced) to reply to customer reviews that arrive through the Trustpilot channel integration, and every reply it publishes ends with a fixed footer: “This email was automatically generated using AI.” There is no setting at account, agent or channel level to remove or customize it, and “Display sources for generative replies” is disabled. This affects our admins, who can’t control the content of public replies, and our customers and prospective customers, who read these replies on Trustpilot. What problem do you see this solving? (1-2 sentences)It would let us publish AI-generated review replies with wording that is accurate for the channel and consistent with our brand. Today the footer refers to an “email” on a public review platform and stays in English regardless of the reply’s language. 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)It happens on every single reply the AI agent publishes on Trustpilot, so we are affected daily. Each reply appears publicly with a footer that calls it an email, which looks like an error to anyone reading our reviews. Since review replies are one of the most visible parts of our brand to potential customers, this undermines the quality of our public communication. It also makes it hard to justify using AI agents on public-facing channels at all. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)No, we haven’t found any workaround, since the footer isn’t part of our instructions or procedures and can’t be edited. Our only alternative would be to stop using the AI agent on this channel. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)An option to enable, disable or customize the AI footer per AI agent and per channel, with support for localized text. We’re happy to disclose AI use; we just need to control the wording and where it appears. 

Aaron11
Aaron11Contributor

Allow option for automatically setting agent status to Online when the agent is active in Zendesk WorkspaceAccepted

Overview Similar to Agent Status switching to Offline when an agent signs out of Agent Workspace, we would like to see an option for agents to be automatically set to Active when they sign into Agent Workspace and are actively working on tickets, with an option to override the status as needed. This would be similar to functionality that already exists in Tymeshift. What problem do you see this solving?  With the introduction of Omnichannel routing, many of our agents have been requesting that Zendesk Agent Workspace automatically mark them as online when they are actively working within the application, with an option to override this if they need to go offline. Agents often forget to toggle their status back to online, as they have been used to Tymeshift doing this for them automatically.  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? It is mostly an ease-of-use/agent experience request, though this does have some impact on customer response times when agents are accidentally offline. I get asked 1-2 times per week if this is a feature that could be added.  Are you currently using a workaround to solve this problem?  Frequent reminders to teams via group chats and close monitoring of Explore Live Data dashboards.  What would be your ideal solution to this problem? How would it work or function?  When an agent signs into Zendesk, they would receive a prompt, asking them to set their status. This would prevent any potential barrage of auto-assignments if they are just logging in to review something and are not actually available to have work assigned. If the agent has been idle for a long time and comes back online, the same prompt would be presented to them.     

Critical Feature Request: Auto-Reopen Tickets on Email Delivery FailureAccepted

Dear Zendesk Support Team,As a company that relies heavily on Zendesk for both outbound and inbound email communications, including customer support and collections outreach, we have identified a major issue that impacts our operational efficiency and customer responsiveness.Current Issue:When we send an outbound email from a ticket, the initial message status shows as "Delivered." However, after a few minutes/hours, the status may update to indicate a delivery failure. The problem is that the ticket does not automatically reopen when this failure occurs. Instead, it remains in its previous status (e.g., "Solved"), leading to critical delays in resolution and follow-up.This issue has significant consequences: Delayed Follow-Ups: Agents are unaware of the failure until they manually check the ticket, leading to prolonged response times. Missed Customer Engagements: Customers expecting a response may never receive it, impacting satisfaction and resolution time. Operational Inefficiencies: Agents must manually monitor email statuses, increasing workload and reducing productivity. Revenue Impact: In collections outreach, undelivered messages that go unnoticed can lead to delayed payments and financial losses. Proposed Solution:We request that Zendesk implement an automation or trigger that detects email delivery failures and reopens the corresponding ticket. Specifically, we need: Automatic Ticket Reopening: If an email fails to deliver (bounce, rejected, blocked, etc.), the ticket should revert to an "Open" status to alert agents for further action.  Trigger-Based Actions: The ability to set up custom triggers or workflows based on failed email deliveries, such as escalating tickets or assigning them to specific teams. This feature is critical for teams that rely on email communications as part of their customer support and collections processes. The inability to automatically reopen failed email tickets leads to missed interactions, reduced efficiency, and revenue impact.By implementing this feature, Zendesk would significantly enhance its email management capabilities, ensuring businesses can proactively address communication failures and improve customer engagement.We appreciate your attention to this request and look forward to any updates on potential improvements in this area.Thanks in advance,Avan

Georgi11Newcomer

Product Feedback: Ability to Open Admin Center Pages in a New TabAccepted

With the introduction of the new Admin Center navigation experience, administrators can no longer easily open configuration pages in a new browser tab directly from the left navigation menu.Previously, users could use standard browser functionality (such as Ctrl + Click, middle mouse button click, or right-click → "Open link in new tab") to open multiple configuration pages simultaneously. In the new UI, many navigation elements behave as application controls rather than standard hyperlinks, preventing this workflow.Business Impact:Reduces administrator efficiency when working across multiple configuration areas. Makes it more difficult to compare settings between different pages, such as Roles. Increases navigation time, as administrators must repeatedly leave and return to pages instead of working in parallel tabs. Creates a poorer user experience for teams that perform frequent Zendesk administration and configuration tasks.Requested Enhancement: Please restore support for opening Admin Center navigation items in a new browser tab by:Supporting standard browser actions such as Ctrl + Click, Command + Click, middle-click, and right-click → "Open link in new tab". Ensuring all Admin Center menu items have accessible URLs that can be opened independently. Preserving the ability for administrators to work with multiple configuration pages simultaneously.Expected Outcome: Administrators can efficiently navigate and manage Zendesk configurations by opening multiple Admin Center pages in separate browser tabs, improving productivity and aligning the experience with standard web navigation behavior.