Create a Zendesk Ticket From Slack, Properly

Someone drops a customer problem into a Slack channel and it needs to become a ticket. Here is how to create a Zendesk ticket from Slack without opening Zendesk at all.

Start free trial All guides

Three ways to create a Zendesk ticket from Slack

The message action. Hover the Slack message, open the more actions menu, pick the Zendesk option. The message text goes into the ticket and Slack keeps a link back to the thread.

The slash command. Type the Zendesk command, fill in a short form, submit. Useful when the request is in your head rather than already written down in a channel.

A workflow. Slack Workflow Builder collects a few fields and hands them on, either through the Zendesk app or through a middleware step. Best for repeatable internal requests where you want the same fields every time.

All three produce an ordinary Zendesk ticket. What changes between them is how much context arrives with it, and that difference matters more than it sounds.

The shortcut most teams miss when they create a Zendesk ticket from Slack

Most teams install the app, learn the slash command, and stop. That's the weakest of the three.

The message action wins because it starts from something that already exists. The customer complaint, the screenshot, the stack trace someone pasted at two in the morning: all of it comes across, and the ticket keeps a pointer back to the Slack thread so the next agent can read what happened before the ticket existed. A blank form recreates that from memory, badly.

If your team lives in Slack, demo the message action first and mention the slash command second. It takes about ninety seconds and it changes the quality of every ticket that arrives this way.

The other half of the trick is pre-filling. A workflow can set the form, group, priority and tags before the ticket is created, so requests land already triaged instead of sitting in the general queue waiting for someone to sort them. Pair it with a purpose-built ticket form and the routing takes care of itself.

Who ends up as the requester

This is the trap, and almost every team hits it once.

A ticket raised from Slack is normally created with the Slack user as the requester. For an internal request that's exactly right. For a customer issue it's wrong, because now the notifications, the satisfaction survey and the first response clock all point at your colleague rather than the person who actually has the problem. Reporting quietly goes with them.

You have two options. Change the requester right after creating the ticket, though that's a manual step somebody will forget on a busy Friday, and it's worth reading what changing the requester does and doesn't move. Or draw a line: Slack creation is for internal work, and customer issues come in through email, messaging or the web form.

Pick one and say it out loud. Teams that leave it ambiguous end up with a reporting set that nobody trusts.

When a ticket is the wrong answer

Not every Slack message deserves its own ticket. Two patterns to watch for.

Chatter about a ticket that already exists. Someone pastes a complaint that arrived by email an hour ago. Raising it from Slack creates a second record for one problem, and now two agents are typing different answers to the same customer.

Work that belongs to another team. If engineering or finance owns the task but the customer conversation stays with you, a side conversation on the existing ticket is the right tool. A new ticket just splits the history.

A single line in the channel topic prevents most of it. Search first, raise second.

Setting it up without a mess

A Zendesk admin and a Slack admin both need to be involved, because the connection has to be authorised on both sides. Install from the Zendesk marketplace, connect the workspace, then decide which channels the app lives in. Check the current marketplace listing for the exact permissions and any plan requirements, since those move around.

Two decisions are worth making before you announce it. Which channels can create tickets, because "all of them" means tickets raised from the social channel at eleven at night. And whether creation is open to everyone or restricted to a group, because unrestricted creation in a four hundred person workspace produces a queue nobody staffed for.

The broader picture of what the connection is for, including the notification side, sits in the Zendesk Slack integration guide.

FAQ

Frequently asked questions

Can anyone raise a Zendesk ticket in Slack, or just agents?

Anyone in the channel can raise a Zendesk ticket in Slack once the app is installed, which is the point and also the risk: colleagues without Zendesk seats can create work nobody has agreed to own.

Can you create a Zendesk ticket directly from a Slack message?

Yes. Use the more actions menu on the message itself and pick the Zendesk ticket option. The message body comes across and the ticket keeps a link back to the Slack thread.

Does the whole Slack thread come across?

Usually just the message you acted on, plus a link back. If the thread matters, paste the relevant replies into the ticket description or add them as an internal note afterwards.

Who is the requester on a ticket created from Slack?

By default the Slack user who created it. That's correct for internal requests and wrong for customer ones, so change it or restrict Slack creation to internal work.

Can I set the form and group automatically?

Yes, through a Slack workflow that supplies those values, or with a Zendesk trigger that fires on the tag the app applies. Pre-filled tickets need far less triage.

Do I need a paid Slack plan?

Basic ticket creation works broadly, but Workflow Builder capabilities and app permissions vary by plan. Check the current marketplace listing and your Slack plan before you promise anything.