Zendesk

Your assistant can list the tickets, read your saved views, and count what is in each one, then describe the state of the queue in a sentence instead of a dashboard. Because it reads the tickets themselves it can answer follow-ups you did not build a view for, like which of the open ones have gone quiet for more than four days. It writes nothing back.

What you end up with. A plain description of the queue right now, broken down the way you asked rather than the way the views were set up two years ago.

Start with it bringing you the information and you deciding.

Never without. Treat the counts as approximate and expect a large queue to take a while. Zendesk returns approximate counts on its count endpoints, and the ticket list only filters server-side on external_id, so status, priority and assignee filters are applied after the whole set is pulled.

Built on: List Tickets / List Views / List Tickets From View / Count Tickets in Views / Count Tickets in View

There are separate reads for the tickets assigned to you, the ones you requested, the ones you are CC'd on, and the ones you are only following. Pulled together, that is the real load, which is usually larger than the assigned count and is the reason the assigned count feels wrong. Read only, so you can do this as often as you like.

What you end up with. One list of everything with your name on it, split by whether you own it, are copied on it, or are just watching.

Start with it bringing you the information and you deciding.

Never without. Keep this pointed at your own work. The same reads run against a colleague's user ID produce a workload comparison, which is a different thing entirely and needs their knowledge and a reason.

Built on: Get User's Assigned Tickets / Get User's Requested Tickets / Get User's CC'd Tickets / Get User's Followed Tickets / Get User

Zendesk keeps a chronological log of everything that happened on a ticket, comments and status changes and reassignments together, and that log is readable. The assistant can pull the ticket, its comments and its conversation log, then lay out where the time went: waiting on the customer, waiting on a reassignment, or sitting untouched. That is usually a different story from the one in the comments.

What you end up with. A timeline of the ticket showing each handoff and each waiting period, with the specific gaps that account for most of the elapsed time.

Start with it bringing you the information and you deciding.

Never without. Read the timeline as a record of the system, not of a person's effort. The log shows when a field changed, not why, and using it to explain someone's week without asking them is how a useful read turns into a bad conversation.

Built on: Get Zendesk Ticket / Get Ticket Comments / Get Ticket Conversation Log / Count Ticket Audits

The assistant can search across tickets, read the comment text rather than just the subject lines, and group what it finds by the real problem instead of by the tag someone picked in a hurry. It can also read satisfaction ratings and the tag list to see where the existing categories and the actual complaints have drifted apart. Nothing is retagged unless you ask for that separately.

What you end up with. A grouped picture of this month's contact reasons, with example ticket IDs under each group so you can check the grouping yourself.

Start with it bringing you the information and you deciding.

Never without. Open two or three tickets from each group before you believe the grouping. The categories are the assistant's reading of the text, not a field in Zendesk, and a plausible group name can hide two unrelated problems.

Built on: Search Zendesk / List Tickets / Get Ticket Comments / List Satisfaction Ratings / List Tags

It can read the ticket and the customer's history, find how similar tickets were resolved before, preview what one of your existing macros would do to the ticket without applying it, and then write the response. The reply action adds a comment to the ticket, and a comment is either public or internal. Internal notes stay inside Zendesk, so a draft left as an internal note is a draft.

What you end up with. A drafted response sitting on the ticket as an internal note, grounded in how your team answered the same question last time.

Start with it doing the work and checking with you.

Never without. Say explicitly that comments must be internal until you approve them. A public comment on a Zendesk ticket emails the requester the moment it is written, and there is no recall: the correction arrives as a second email.

Built on: Get Zendesk Ticket / Get Ticket Comments / Search Zendesk / List Active Macros / Apply Zendesk Macro Preview / Reply to Zendesk Ticket

Bulk ticket updates and tag updates are both available, so the assistant can work through a set of tickets and bring the fields into line with whatever convention you are trying to hold. Bulk updates run as a background job and return a job status you poll rather than an immediate result. Ticket updates fire your triggers and automations exactly as if an agent had made them.

What you end up with. A consistently tagged and correctly statused batch of tickets, plus the job status showing which ones the update could not apply to.

Start with it doing the work and checking with you.

Never without. Check which of your triggers and automations fire on the fields you are changing, and run the batch on five tickets first. A status change across two hundred tickets can send two hundred customer notifications, and a tag update that replaces rather than appends silently drops the tags that were already there.

Built on: List Tickets / Get Ticket Tags / Update Zendesk Ticket Tags / Update Many Tickets / Get Job Status

It can list the suspended tickets and the soft-deleted ones, show you what is in each, and then permanently delete them in bulk. These deletions are irreversible: Zendesk removes the records and there is no recovery, in the connector's own words. This is the boundary worth being deliberate about, because everything upstream of it is recoverable and this is not.

What you end up with. A cleared suspended queue and an emptied deleted-tickets bin, with a record of what was removed kept outside Zendesk.

Start with it doing the work and checking with you.

Never without. Have it export the ticket IDs, requesters and subjects to a file you keep, and approve that list before anything is deleted. Permanent deletion in Zendesk cannot be undone, a genuine customer request does land in the suspended queue from time to time, and retention obligations do not care that a ticket looked like spam.

Built on: List Suspended Tickets / List Deleted Tickets / Bulk Delete Zendesk Suspended Tickets / Bulk Delete Soft-Deleted Zendesk Tickets / Delete Deleted Ticket Permanently

Duplicate end users are readable by search and mergeable by the connector. The merge keeps one user as the primary and folds the other one into it, and the source user is deleted in the process. The assistant is good at finding the duplicates and bad at knowing which of two similar records is the one your billing system points at.

What you end up with. A shortlist of likely duplicate customer records with the evidence for each pairing, and the merges you approve carried out.

Start with it doing the work and checking with you.

Never without. Choose the primary user yourself for every pair and confirm the direction before each merge. The source user is deleted and its data moved into the primary, the merge cannot be reversed, and picking the wrong primary destroys the record that other systems reference by ID.

Built on: Search Zendesk / List Users / Get User / Merge Users