One of the highlights of Zendesk AI is Agent Copilot with its suggested replies and auto-assist procedures. They offer comments to agents, alongside with actions within Zendesk or in third party platforms and remove repeated actions from an agents' workday. Instead agents can validate the suggestions from Copilot, or see replies with context pulled from your CRM or webshop, before submitting them.

These Agent Copilot actions work across channels. They're perfect for handling email conversations which often require a lot of back and forth to collect all the order numbers, product serials and problems descriptions you need before handling a ticket.

For Messaging tickets they're perfect to summarize the conversation, validate the input from the AI Agent and customer, and have your procedures to handle refunds or order changes take over.

There's a third kind of ticket though which often shows up in Zendesk – and no I'm not talking about Voice. These are API tickets. They can originate from integrations with your website, from tickets created via Zapier or even tickets created via Marketplace apps like Nextmatter or Sweethawk's Tasks and Recurring ticket app.

These tickets too are ideal for running procedures on. If you've got a noisy status monitoring tool, you can use procedures to set the priority of those tickets based on the contents, or copy over relevant information into custom fields. And you can even quickly solve those tickets after triage.

Similar, website submissions are often very database and structured emails, but might not be easily triaged via triggers to set a category, pull in a customer name e.a. Here too procedures can help to get the context out of the comments and into the ticket fields.

Two kinds of API Tickets

Tickets created over API come in two kinds. There's requests, and there's tickets. And while both results in a ticket in Zendesk, there's subtle differences.

Requests are created by end-users. The requester is the one who creates the ticket and the initial comment is assigned to their name. Requests are created when an end-user emails, chats or calls. Once created they result in tickets in Zendesk on their name.

Tickets on the other hands are based on the agents point of view. When an agent creates a proactive ticket from Agent Workspace, even though the end-user is still the requester, the first ticket is on the agents' name.

And while it's perfectly possible to create a ticket over API for an end-user, there's an important distinction to be made, and that distinction becomes very clear when using Agent Copilot.

Agent Copilot

When an end-user creates a request, the resulting ticket shows up in Agent Workspace and auto-assist kicks in to propose a response.

When an agent creates a ticket in Agent Workspace, we won't see a suggested reply from Agent Copilot. Since the original comment from the agent will be send to the customer, there's no point suggesting replies. Auto-assist will only suggest responses after our customer replies to the agent message.

And if we use the Zendesk API to create a ticket on behalf of an end-user, we often end up with this exact same scenario, where even though the ticket is created, auto-assist does not suggest a response. Even worse it seems Agent Copilot is waiting for a customer reply.

Why? Well, that's because of the difference between requests and tickets.

Two API options

Creating tickets

Most platforms that integrate with Zendesk use the POST /api/v2/tickets.json endpoint to create a new ticket. And while this works perfectly file, it does create the issue with Agent Copilot where the system might think this ticket comes from an agent, and not a customer, and Copilot will not fire.

{
    "ticket": {
        "requester": {
            "name": "Alan Grant",
            "email": "[email protected]"
        },
        "subject": "Reflections and Concerns Following Recent Events",
        "comment": {
            "html_body": "<p>Dear Jurassic Park Customer Care Team,</p><p>I hope this message finds you well. My name is Dr. Alan Grant—paleontologist—andrecently, I served as a consultant for the Isla Nublar project. I’m writing todaynot merely to report issues—but to offer clarity and suggestions moving forward.</p>..."
        }
    }
}

There's "hacks" to work around this by provided a ticket.via.channel value in the payload, but in 99% of the cases, even though your ticket is created properly, your Agent Copilot won't run (and neither will your first reply time in SLA if you use default settings.)

So if your integration uses POST /api/v2/tickets.json and you're having troubles with Agent Copilot, keep reading!

Creating requests

Zendesk requests are the better API endpoint to use if you want to create tickets on behalf of your users. By making API calls to POST /api/v2/requests.json you'll create tickets that behave exactly the same as tickets created via email, messaging or voice.

The syntax for these API calls is nearly identical to those for tickets, you basically need to replace ticket with requests at the start of your payload. So by replacing that key and adapting the request URL, you're good to go!

{
    "request": {
        "requester": {
            "name": "Alan Grant",
            "email": "[email protected]"
        },
        "subject": "Reflections and Concerns Following Recent Events",
        "comment": {
            "html_body": "<p>Dear Jurassic Park Customer Care Team,</p><p>I hope this message finds you well. My name is Dr. Alan Grant—paleontologist—andrecently, I served as a consultant for the Isla Nublar project. I’m writing todaynot merely to report issues—but to offer clarity and suggestions moving forward.</p>..."
        }
    }
}

There's more information available via the Developer Documentation.

Conclusion

One final piece of advice before we wrap up this article: by default Intelligent triage with its Intents, Sentiment and Language detection does not identify tickets creates via API. You can enable this channel via the Admin Center (along with plenty of other channels)

Extra - Employee Service Suite

There's a fun little edge case that this Agent Copilot behavior causes for customers that use Zendesk for Employee Service.

Let's say you have two departments, IT and HR, that both use Zendesk. If an agent from the HR department sends an email to IT for assistance with their laptop, this will create a ticket in Zendesk.

From the point of view of Zendesk, that ticket will be created by an agent since the person creating the ticket is an agent in the HR department.

Which means that Agent Copilot will not fire for that ticket. Even though there might be a perfectly valid procedure available for the IT team, since the person creating the ticket is an Agent, your Agent Copilot will be stuck on "Waiting for a customer reply" forever.