Discuss ideas, submit feedback, and track what's next
Help us understand your request
An intake-ready template
When users have view access to the Organization fields on a ticket they cannot view the value of the fields where the text in the field is long.
While the update for goal conversions is great to have in Analytics, I'd like to see goal conversions also apply to AI Agents. Without these conversions, we do not have a good way to provide data to executive leadership to show exactly how much our AI Agent is doing for us. Most companies are making decisions based on sales conversions and this is a missing piece of insight. We cannot show that our AI Agent is helping to generate sales, which would go a long way towards getting buy in for more features, like AI Agents Advanced. In addition, we need a more accurate way to track actual sales conversions with transaction totals. I understand that this would likely mean some piece of code added to our checkout process to capture the actual totals, but it would be very worthwhile to have this data to back up the AI Agent's performance.
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.]. (2-3 sentences)When you have a Problem ticket, you can click into the Incidents window to see all of the related Incidents to the Problem. We would like the ability to change the columns showing in that window (Ex: add the organization column so we can easily see where the tickets are sourcing from). What problem do you see this solving? (1-2 sentences) This would save our team leads time by being able to quickly gather relavant information rather than needing to click into each 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? (3-4 sentences)This is only an issue when we get Problem tickets. I would say maybe 1-2x month. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)Yes, we are clicking into each ticket to find the information we need and putting it down somewhere else so we can compare tickets. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)We would like the Incidents view to function as a regular view with the ability to update the columns, sort, and group. Totally fine if it is only accessible via admin.
We’re testing the Action Flows EAP and would like to send Zendesk CSAT surveys to end‑users via Slack direct message. Two additional variables would make this possible: Requester Email – exposes the requester’s primary email without adding a separate Look up user step. CSAT Placeholder – a variable (or support for classic {{satisfaction.rating_section}}) that renders the interactive survey block in Slack, just as it does in email. These additions would let us build a single, fully automated flow: Trigger: Ticket solved Slack DM to requester: “Hi {{requester.first_name}}, thanks for contacting us! Please rate your experience: {{csat_placeholder}}” Benefits Consistent CSAT delivery across channels (email + Slack). Fewer manual follow‑ups from agents. Cleaner flows (no extra user lookup or workarounds). Thanks for considering these variables for the next Action Flows update!
Hi, We had an app built. During testing, we used a simple API endpoint with GET. But later we enhanced our API endpoint to POST with Authorization Headers, and then when prompting the App builder to change the API method, it gets stuck on the part that App builder has access to index.jsx in read-only, so it creates App.jsx But the app itself both in test and publish, is still using the old GET endpoint as checked in the inspect tools. Can you please enable the functionality for App builder to have a reset on the index.jsx. I started with a new chat but that as well is stuck with no response.
We appreciate the new feature where ticket summaries are now accessible via reporting and API requests as it's something we've been hoping for since they were introduced. After speaking with support, it has been confirmed that only those tickets where an agent has clicked ‘generate’ summary will it be accessible. I understand this at a certain level, as ultimately the summaries don't exist unless they're generated. However, it's a little disappointing as we have no way of automatically generating the summary unless the agent explicitly clicks ‘generate’. Our core use case for reporting on ticket summaries is our general customer support team as this how we may identify trends in queries and potential issues. Summaries would give us more detail than intents or categorisation currently do. 90%+ of our customer support tickets are via messaging and resolved within 15 minutes and so agents rarely generate a summary. On top of this, we were hoping to utilise the API auto-note customer accounts on our backend. We can ask agents to manually generate a summary at the end of every conversation, however this adds another simple - but manual - step as we aim to reduce manual workload on agents whilst they focus on handling customer queries. Ideally, ticket summaries would be generated automatically without manual input and refreshing every 5 minutes or so to ensure they're not constantly changing (and therefore they would have a use in a ticket view as well). Alternatively, we could have a ‘Generate ticket summary’ trigger action so we could fire it whenever a ticket has been solved which would also be a step in the right direction.
We've learned that AI Agent tickets are open for four (4) days after after the last communication from the user. This duration length is not configurable. Four days duration between the AI Agent ticket being opened and then automatically closed is arbitrary and long, isn't it. A given user might have multiple, distinct questions during a given week. Imagine a case where a user has two questions - one on Monday and the second on Tuesday (or one in the morning and another in the afternoon). We think it would be better for each conversation to be a distinct ticket (rather than the initial AI Agent ticket being appended to). And having the initial ticket be in the Open status for a long period of time after the conversation has concluded is a bit confusing to an agent that is reviewing AI Agent tickets. Our bot's workflow is such that a user should be able to get their answer within a few minutes (any bot should answer the user quickly, not in hours or days). So it would be better for the bot (or channel, or brand) to specify the duration rather than it being a global default. And it might also be better if the workflow could be defined such that, if a user reaches certain steps of the flow, then the flow and the ticket should be considered solved. I.e. the logic of the flow has driven the user to receive the answer they seek and there is nothing more to do with the ticket. This is so the initial ticket is quickly solved/closed and a subsequent conversation becomes a different ticket.
Hello,I would like to hide a specific dropdown field value in the request form for End User ? How to proceed ? Thank you
Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue:In order for us to use Entity from the Zendesk CoPilot add-on effectively and for the Entity functionality to provide real added value for us, we would like the content of the agent signature to be ignored during entity detection.The agent signature contains information about which support unit a colleague belongs to, such as “Global <Product A> Support” or “EMEA <Product B> Support” or the public eMail for support group.However, <Product A> and <Product B> are values that should be recognized from the customer's ticket content via entity detection and should not be taken from the content of the agent signature.As can be seen in the following screenshots, Entity Detection in the ticket uses content from the agent's signature. What problem do you see this solving?Entity detection does not work as intended when using the “Values in all interactions” option because content from the agent's signature is included. 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?Since we cannot activate entities with the current state of implementation, we are constantly confronted with this limitation.As already mentioned, this leads either to a poor user experience or to a low degree of automation. Are you currently using a workaround to solve this problem?We are currently unaware of any workaround. What would be your ideal solution to this problem? How would it work or function?The ideal solution is for content from the agent signature to be automatically excluded from entity detection.Alternatively, it should be possible to configure whether content from the agent signature should really be included.
It appears that the contributor and light agent roles permit view access to custom objects and are not configurable to be otherwise. On the other hand, these permissions are configurable for other licenses. I understand that there are serious limitations to access governance with regard to custom objects (ie macro bypass of permissions on other roles), and I assume that is inherent to the architecture. However, since other roles can have their access configured, it seems like this restriction on modifications is arbitrary. Custom objects could include sensitive data relevant to work done by private groups and should not be accessible to our light agents, contributors, or other members not in the private group. In the same way as ticket access can be customized. To enforce effective user access governance, the custom object permissions should be configurable for light agent and contributor roles in the same way as ticket access can be customized. 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.]. (2-3 sentences) Custom objects are visible to users that should not have access. While full licenses for agents can have their custom permissions restricted, due to the fixed config of light agents and contributors, admins cannot customize their access to these data assets. What problem do you see this solving? (1-2 sentences) The lack of customization options for light agent and contributor roles impacts data governance and may expose sensitive data. This limits the usability of the custom objects feature altogether. 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 is an on-going issue. This impacts the ability for admins to control who access to what data. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences) The only workaround presently available is to not use custom objects to store sensitive data. What would be your ideal solution to this problem? How would it work or function? (1-2 sentences) Unlock the light agent and contributor role customization options to allow admins to restrict/customize access to custom object data. At minimum, for the sake of safest data governance, the default should prevent view access.
We would like more control over the Enhanced Writing feature in Zendesk AI.It’s currently possible to create custom prompts, but they cannot be saved for reuse.Additionally, the prompt options appear in a fixed order and cannot be reordered. Request: Allow admins to change the order of the Enhanced Writing options Allow admins to save custom prompts that can be reused by agents This would make Enhanced Writing faster to use and reduce repetitive manual prompt writing.
Hello, At the moment we use child ticket to create work for other teams, these teams will go back to the customer directly, rather than going to the advisor that raised the ticket. We raise child ticket via side conversations by using macros at the moment Currently, the advisor raising the ticket needs to manually change the requester of the child ticket to the requester of the parent ticket. The reason we need these to be the same is that we have automations off the back of the child ticket to email the requester (customer). I would like the ability to set the requester on a child ticket when using a macro. This would save advisors time and also reduce the risk of an automation emailing the incorrect end user.
Hi ZD team! We would like to see an internal commenting feature added to Zendesk guide articles. It would be something similar to Google Docs or Microsoft Word's ability to add comments to specific paragraphs, sentences, or words.As a technical writing professional, this is a must-have. It's a huge hassle for our team when we are reviewing articles, as we can't do the reviews in the same place where we write and publish the article. Since Zendesk doesn't offer us any viable options for reviewing articles, we have to use Google Docs to fill in the gaps in this current workflow. Our current process: We send our articles for review to subject matter experts (SMEs) at least once but sometimes more so that they can review for technical accuracy, but since there are no internal comments for articles, we have to copy and paste into a Google Doc to allow the SME to comment on what sections or lines need to be changed. Then, we can either make changes to the Google doc before passing it to someone on our team to review for grammar and clarity or we change it in Zendesk and then copy and paste the new version to GDoc. During this process, we lose the proper formatting we need in the article. It doesn't make sense to move content in and out of Zendesk to Google Docs and back to Zendesk. Additionally, it loses a proper "audit log" on the article since the small changes are not properly shown in Zendesk when items are moved in and out. It only shows a large copy/paste of information. Having the feature implemented into Zendesk would majorly streamline our process. Thanks, Katie
I do not use Zendesk AI Agents. I use Fin for ZD. Since we do not have any say in whether this feature is enabled or not, at least us merge the AI Agent tickets. Otherwise, we end up with open tickets that we can do nothing with. I can't assign them to someone in the case that bot isn't handling it correctly. I can't merge them with a duplicate ticket. This feature makes very little sense for those who do not use Zendesk AI Agents.
Hello Support Team, We are in need of view for agents. We believe this would be helpful for many support teams. We need a view for tickets that are less than pending status, that have had no public reply/comment in 72 hours or greater. Thank you in advanced for your time and attention to this feature request. Best Regards,
Hi please could we request French Canadian language support for AI Agents?We have a customer who has french canadian knowledge locale set up, but this is not supported through AI Agents for this locale.
Feature Request: Agent-Level Acceptance Rate for MessagingCurrently, the Acceptance Rate metric in Zendesk messaging is only available at the ticket level, making it challenging to evaluate agent-level performance accurately. This feature request is to implement an Acceptance Rate metric for individual agents, similar to what exists for Live Chat.Description/Use Case:The requested feature would enable tracking and analyzing Acceptance Rate for messaging at the agent level, providing insights into how effectively individual agents are engaging with incoming conversation offers. For example, this metric would allow managers to:-Identify agents who are consistently missing messaging offers.-Measure and improve agent responsiveness for messaging, especially in high-traffic environments.-Benchmark agent performance and set clear KPIs for acceptance behavior. This functionality would align messaging performance monitoring the same with Live Chat, where agent-level Acceptance Rate is already available and highly valuable for performance evaluation.Business Impact of Current Limitation:The lack of agent-level Acceptance Rate tracking in Zendesk messaging creates the following challenges:-Inability to Track Agent Responsiveness: Managers cannot accurately identify which agents are failing to accept messaging conversations. This can lead to missed opportunities and inconsistent customer experiences.-Reduced Accountability: Without an agent-level metric, it’s harder to hold individual agents accountable for their responsiveness to messaging offers.-Performance Optimization Limitations: Teams are unable to provide targeted coaching or performance improvement plans for agents, potentially impacting overall team efficiency and customer satisfaction.Adding this metric would enhance Zendesk’s reporting capabilities and ensure that messaging workflows are as robust and measurable as those for Live Chat.
Currently when Agent is using Auto-translation every message sent to the chat has “(translated)" text in a given language attached. The desired behaviour is to remove that text.Any other translation solution on the market has an option to NOT explicitly advertise the fact of translation. Users don't have to know that a text was translated. If Agent (or a business) would like to make explicit they can ad a disclaimer or user macros/bot flows to inform customers about translations.
We have 1300 macros we need to update to add another group who can view it, but I just learned with Support that bulk updates aren't possible. Even with API, the only thing that can be updated is the position, not anything else about the macros. Manually updating that many macros is going to take an enormous amount of time, so please consider this feature!
On Explore reports, Twilio's only metric for both calls and text is "Voice", please add more granular metadata.A workaround would be to use tags however these aren't available to Lite customers and these customers are then stuck and cannot access more granular data.
when chatbot is enabled on social media Direct channels the "ask for details" answer is not working as it works in Web Widget and this makes a huge difference. It really affects the agents as without this option they they have to fill the ticket fields manually and this have significant effect on time .another thing is that if I have dropdown menu how I supposed to make a workaround to show this so that requester can choose from it .another thing in Web widget I had the ability to route tuckets based on details now I can not do this in social media channels !
We noticed that there is not option to add add brand logos to the new dashboard builder. This limitation is a significant source of frustration for both our business and our customers, especially considering that this feature was available in the previous version. The capability to customize dashboards with brand logos is essential for maintaining brand consistency and enhancing the professional appearance of our reports. The absence of this feature adversely affects our ability to present data in a manner that aligns with our brand identity. It would be great if you could bring back the option to add logos to dashboards. This enhancement would greatly improve the user experience.
The Problem:Currently, the "Make more friendly" generative AI tool does not distinguish between Internal Notes and Public Replies. When used on technical internal notes (bulleted lists, system specs), the AI converts the format into a conversational email greeting/body. Impact on Workflow: Loss of Readability: Agents use bullet points for speed. The AI converts these into long-form paragraphs. Tone Mismatch: Internal notes require professional brevity; the current tool forces a "customer-facing" warmth that is unnecessary and time-consuming for agents to revert. Risk of Data Loss: In the process of rephrasing for "friendliness," specific technical details (like the "Windows 11 Home, version 24H2" in our example) risk being omitted or summarized incorrectly. Suggested Enhancements: Context Detection: The AI should detect if the agent is typing in the "Internal Note" tab and maintain a "Professional/Concise" format rather than an "Email/Friendly" format. Format Retention: Add a toggle or instruction to "Maintain Formatting" (e.g., keep bullet points) while adjusting the tone of the text within those bullets. Tone Selection: Instead of just "Make more friendly," offer "Professional Polish" or “Summarize for Internal Log.”
We would be very grateful for non-expiring API tokens either scoped to the permissions of a specific user or with a configurable scope (e.g., read or write). This would fill in the new gap created by recently announced changes requiring OAuth tokens to expire while improving the security of API tokens.Additional context: we like to enable some of our non-admin agents to make their own requests to the Zendesk API. This allows them to create notification scripts for their own use, extract ticket and article data for analysis, and so on.There are currently two primary methods for authenticating API requests: API tokens and OAuth tokens. API tokens: API tokens do not expire. However, they are not secure for non-admin agents to use, because the scope of the request is based on the email address supplied in the request. Consequently, anyone can use an admin's email address with an API token to gain admin-level API access. There is more discussion on this issue in the post Zendesk APIs - Token Security. OAuth tokens: OAuth tokens provide scoped, user-specific access to the Zendesk API. This is exactly what we need, and our users have been happily using non-expiring OAuth tokens in their own scripts. However, all OAuth tokens will begin expiring soon, with an original deadline of April 30, 2026 that was recently extended to April 1, 2027. Because of the email-based scoping described above, we cannot safely give our non-admin agents API tokens. Scoped API tokens would address this security concern.We can also no longer rely on OAuth tokens without building out an application to manage and refresh tokens. We understand how requiring OAuth tokens to expire improves security for typical integrations. However, it turns our lightweight, self-service scripts into a full-blown IT-managed application requiring central infrastructure, maintenance/support, monitoring, persistent storage, and so on.
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.]. (2-3 sentences)With complex workflows, we have adopted many custom statuses now. However, the limitation can be confusing when you have many custom statuses in the same category. It's confusing for support agents and engineers to quickly use the status they should. What problem do you see this solving? (1-2 sentences) Faster time to resolution, similar answer to above. 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)Every day. There are certain workflows that are status dependent, and if someone clicks the wrong one, it can cause a ticket to be orphaned or solved slower. Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)NoWhat would be your ideal solution to this problem? How would it work or function? (1-2 sentences)Just give a color selector/hex code field for us to set whatever color we want. If Zendesk is stuck on the colors for categories being consistent, at least give us different hueues/shades of the colors to pick from, within each status category.
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.
