Zendesk integration the ticket wired into the rest of the company
A ticket in Zendesk is a record with fields, not an email in a thread. We wire those fields to what you already hold in the CRM, the sales system and accounting: an order number pulls in the shipment status, the customer is matched to a company in the CRM, and a billing case knows which document it is about. Zendesk stays the one place support works in, only now the data arrives on its own.
- 4 prioritiesis all a Zendesk ticket has in the API: low, normal, high, urgent. Everything else that tells your cases apart has to go into a custom field. Zendesk API documentation
- 14 daysfrom the workshop to the first automation running on your own tickets from the last few weeks
- 2 to 6 weeksfor the full integration: fields and forms, the link to CRM and sales, SLA policies, escalations and the export to a warehouse
- 5 to 10 secondsis how long an AI agent takes to answer a question about your tickets, asked in a plain sentence, with no report to build
The problem
Why does a ticket start with a question about the order number?
A customer writes “my parcel never arrived”. The ticket lands in Zendesk as one sentence with no order number, because the form never asked for one. The support rep replies with a question, the customer answers three hours later, and the first reply clock has already started and stopped in the meantime. The case has two exchanges behind it before anybody starts solving it.
The second thing hurts more than the lost time. Zendesk knows everything about the ticket and the rest of the company knows nothing about it. A sales rep calls with an offer to a customer who filed a complaint yesterday, and the warehouse cannot see that the same batch is coming back for the third time this week.
At the end of the same list stands the board. It asks what customers complain about most often and gets an answer built out of impressions, because counting it by hand would take two days. The tags are there in Zendesk, only nobody knows which of them were applied consistently.
The reason is technical and it can be removed. The Zendesk API documentation describes a ticket as a record with closed sets of values: four priorities (low, normal, high, urgent), four types (question, incident, problem, task) and six statuses, from new to closed. Everything that tells your cases apart from each other sits in custom fields and tags. A custom field the form does not require stays empty exactly when it is needed, and an empty field will not feed a rule or a report.
- A support rep asks for an order number that already sits in the sales system
- A sales rep calls with an offer while a complaint is still open
- A ticket filed after hours eats the first reply window before anyone opens it
- A question about the most common complaints ends in counting tags by hand
Why now
What changed, so Zendesk can be wired to the rest of the company in weeks?
Zendesk hands a new ticket over through a webhook and takes a change back through the API, on the same resources the panel works on: tickets, users, organizations, custom fields, macros, SLA policies. Nobody has to replace the helpdesk or move the history. The integration plugs in alongside and writes data onto a case that already exists in Zendesk.
The division of labour is clear today. A trigger fires the moment a ticket is created or updated, and it is good at what stays inside Zendesk: applying a tag, assigning a group, notifying the agent on the case. An automation runs on an hourly cycle, so it is no use for anything that has to happen now.
The rest goes outside. Steps that have to look into a second system, retry after a failure and leave a log behind move to n8n, Make or a direct API integration. Zendesk stays the place where the ticket lives and does not turn into the process engine it was never meant to be.
The third change is on the data side. Tickets can be exported to BigQuery or a SQL database together with their custom fields, tags and the times from the SLA policy. Then the question of what people complain about most stops being a topic for the quarterly review. BOND, our company AI agent, answers it from your data in 5 to 10 seconds, and a full rollout takes around 2 months.
What changes
What does a team working in Zendesk get?
The ticket arrives with the order number already on it
The form picks its fields to match the type of case and makes the ones nobody can work without mandatory. An order number for a return, a photo and a purchase date for a complaint, a document number for a billing case.
A separate form for returns, complaints and billing, each with its own set of fields required on submit
An order number turns into a history
Once the ticket is saved, the integration queries the sales system and writes the order status, the carrier and the tracking number onto the case. The support rep reads it inside the ticket instead of opening a second panel.
Data from Shopify, WooCommerce, Magento or BigCommerce written into custom fields and an internal note
Sales can see support without logging into Zendesk
The Zendesk user and organization are matched to a contact and a company in the CRM by email address and domain, and the ticket id lands on the customer record. Plan and account value travel back the other way, so priority stops depending on the tone of the message.
A link in HubSpot, Pipedrive, Salesforce or Zoho, with the Zendesk id in a custom field
The SLA clock watches itself, including after hours
The SLA policy measures first reply and resolution time in the business hours of the customer's market. An approaching deadline goes out as an alert to Slack or Microsoft Teams, and a breached one escalates to a manager with a link to the case.
An alert before the deadline instead of a report after it, and the reason for the escalation written onto the ticket
A macro that does more than paste text
The macro sets fields and tags in one click, a trigger catches that change and runs the rest: the refund in the sales system, the credit note in accounting, the task for the warehouse. The rep never leaves Zendesk.
One macro instead of three logins: Zendesk, the order panel, the invoicing tool
An answer to what customers complain about most
Tickets travel to BigQuery or a SQL database with their custom fields, tags and reply times, and stay there after the case is closed. A complaint category stops being a tag somebody once applied and becomes a number in a table.
Complaints split by category, channel and week, from a question put to the AI agent in a plain sentence
And in your company
What if we have had Zendesk for six years and everything in it works?
Four sentences we hear most often from teams working in Zendesk, and how we answer them.
Zendesk has triggers and automations, so why would we need anything next to it?
For anything that stays inside Zendesk you do not need us, and we will say so. A tag, an assignment to a group, a notification for the agent on the case: a trigger handles all of it. An outside integration starts where a step has to look into a second system, retry after a failure and leave a log. Zendesk automations run on an hourly cycle, so for anything that has to happen now you would not use them anyway.
We have custom fields, they just never get filled in.
Because the rep fills them at the end of the conversation instead of the customer filling them at the start. Fields the customer knows go into the form as required on submit. Fields the system knows are pulled in by the integration: order status, plan, invoice number. The rep is left with one field to pick instead of eight to retype.
We are not migrating six years of tickets.
And we do not. Zendesk stays the place where the ticket lives, and an incremental copy goes to the warehouse so trends can be counted without loading the panel. The history stays where it is, and the report stops depending on how long Zendesk takes to assemble an export.
Our customers write by email and chat, almost nobody uses the form.
That is normal and we do not force it. A ticket from email or chat arrives with no fields, so we pull the missing data from the sender's email address and from an order number found in the body. The form stays for the cases where you genuinely need something from the customer: returns, complaints, billing.
- Zendesk and ticket channels
- Zendesk Support, email, chat, web form, phone
- CRM
- HubSpot, Pipedrive, Salesforce, Zoho
- Orders and sales
- Shopify, WooCommerce, Magento, BigCommerce, Stripe
- Invoicing and accounting
- Xero, QuickBooks, Sage, sevDesk, Chargebee
- Team work
- Slack, Microsoft Teams, Google Workspace, Microsoft 365, Jira, Notion, ClickUp, Asana
- Data and automation
- BigQuery, Google Sheets, GA4, SQL databases, n8n, Make, Zapier, custom API integrations
What we add to a ticket and where the value comes from
The fields we usually start from on a Zendesk project. The third column is there so you can price what one missing field costs, instead of guessing at it.
| Part of the ticket | Where the value comes from | What happens when it is missing |
|---|---|---|
| Order number | a required field on the form, or a match on the email address in the sales system | the ticket goes back to the customer with a question and loses the first reply window |
| Shipment status and tracking number | Shopify, WooCommerce, Magento, BigCommerce, the carrier API | the rep opens a second panel for every question about a parcel |
| Customer and company in the CRM | HubSpot, Pipedrive or Salesforce by email address and domain, with the id written both ways | a sales rep calls with an offer while a complaint is still open |
| Invoice and payment due date | Xero, QuickBooks, Sage, sevDesk | an argument about an amount gets settled by email between departments |
| Type and priority of the case | the form, the customer's plan from the CRM, the text of the ticket | the order of the queue is decided by the hour a ticket arrived |
| SLA clock and escalation | the SLA policy in Zendesk, a trigger and an alert to Slack or Microsoft Teams | a breached deadline shows up at the weekly review |
| Category for reporting | a tag and a custom field copied into BigQuery or a SQL database | a question about the most common complaints ends in counting by hand |
The rows are a starting point. A first rollout usually covers three to four of them, and the rest go in once the first ones have passed the 30-day measurement.
How we work
Five steps from a one-sentence ticket to a record with data
Every step ends with something you can judge before you decide on the next one.
Workshop
We take your tickets from the last few weeks and look at what is missing in them: which cases go back to the customer for data, how many times the rep leaves Zendesk, where the SLA clock breaks. We also go through what already sits in your triggers, macros and forms, so that nothing gets built twice.
The ticket model
We agree the set of custom fields and forms: what is required on submit, what the integration pulls in, what stays a choice for the rep. On top of that the mapping onto the CRM and the sales system, and the scope of personal data allowed to leave Zendesk.
Integration next to Zendesk
A scenario in n8n, Make or a direct API integration, running alongside your current setup. We switch nothing off. We test the data writes and the escalations on real tickets, including the ones with no order number and the ones filed at night.
Switch-over and training
Once it checks out we move to production with error monitoring. Whoever administers Zendesk learns to add a field, change a form and raise an SLA threshold on their own, without filing a ticket with us.
Warehouse and measurement
Tickets are exported to BigQuery or a SQL database and the first report follows: the split of categories, first reply times, the share of cases that go back to the customer for data. After 30 and 90 days we compare that with the starting point.
Before and after
How one ticket changes
Before
- The case starts with a question about the order number
- The rep keeps three panels open to answer one ticket
- The company hears about a breached deadline from the customer
- A question about the most common complaints ends in counting tags by hand
After
- The ticket arrives with an order number and a shipment status
- CRM, sales and accounting data sit inside the ticket, with nothing to click through
- The alert reaches Slack before the deadline, the escalation carries a link to the case
- The split of complaint categories is a number in a table, refreshed daily
Fields and forms work from switch-over day. We judge the category split and the reply times after 30 days, and after 90 we check whether the cases going back to the customer for data have actually gone.
For the person signing this off
What the person who owns Zendesk gets out of it
You stop being the only place where the configuration is understood. Fields, forms, triggers and everything that happens outside Zendesk are written down in one document, and you make the changes yourself. Your holiday stops meaning that nobody touches a form until you are back.
The second thing is useful in a conversation with the board. From the warehouse you know how many cases went back to the customer for data, how many breached a deadline and which categories are growing month over month. That is an argument for a headcount or for a change in the product, and today you have nothing to back it with.
- The Zendesk configuration written down together with what happens outside it
- The integration runs in parallel, so your current triggers keep working until testing ends
- You change a field, a form or an SLA threshold yourself, without filing a ticket with us
- The split of categories and reply times comes from the warehouse, not from what the team remembers
What it costs
The workshop has a published price, the integration is quoted after it
The process workshop costs EUR 3,500 net per week, and runs from one to seven weeks. One Zendesk usually needs a single week, two when several brands, several queues or several sales systems are in scope. We quote the integration after the workshop, once it is clear how many fields and forms are in scope and what state the data on the other side is in.
You pay for your Zendesk plan directly to the vendor, with no margin from us. The same goes for n8n, Make and the model cost, which the provider charges at roughly EUR 0.005 to 0.07 per query. If the scenarios sit on your own infrastructure, you pay nobody beyond the hosting you already have.
Process workshop
EUR 3,500 net
per week, and one Zendesk usually needs a single week
A self-contained piece of work. It ends with a ticket model and a list of changes in Zendesk you could make without us.
- A review of tickets from the last few weeks: what is missing and what it costs
- The ticket model: custom fields, forms and what is required on submit
- The division of labour: what stays in Zendesk triggers, what goes outside
- Metrics for the 30-day measurement and the list of fields the warehouse needs
- Most popular
Workshop and Zendesk integration
Quoted after the workshop
scope follows from the number of systems and forms
The option most companies choose. Zendesk wired to the CRM, sales and accounting 2 to 6 weeks after the workshop.
- Everything in the workshop
- Custom fields and forms built in Zendesk, with validation on submit
- A scenario in n8n, Make or an API integration, wired to the CRM and the sales system
- SLA policies, alerts before the deadline and escalations to Slack or Microsoft Teams
- Parallel rollout, switch-over with error monitoring and admin training
Zendesk, a warehouse and an AI agent
Quoted after the workshop
for companies that ask about the queue and the complaints every day
Everything in the integration plus ticket data in a warehouse and BOND, which answers questions about it in a plain sentence.
- Everything in the Zendesk integration
- An incremental export of tickets to BigQuery or a SQL database, with custom fields and tags
- An AI agent answering from that data in 5 to 10 seconds, in English or Polish
- A BOND rollout takes around 2 months, running alongside the live integration
The workshop ends with a document that stands on its own: a ticket model and a list of changes to make in Zendesk. If it turns out that your triggers and two new fields are enough, we say so and show you how to set them up. The engagement then ends at the workshop, rather than at an integration you do not need.
Frequently asked questions
How is a Zendesk integration different from its triggers and automations?
A trigger fires the moment a ticket is created or updated and copes well inside Zendesk: it applies a tag, assigns a group, sends a notification. An automation runs on an hourly cycle, so it is no use for anything that has to happen now. Steps that go out to a second system, with a retry after a failure and a log, move to n8n, Make or a direct API integration.
Do we have to migrate our ticket history?
No. Zendesk stays the source of truth about tickets, and the integration writes data onto cases that are already in it. An incremental copy goes to the warehouse, so trends can be counted without loading the panel. The history stays where it is and nobody retypes it.
How long does a Zendesk integration take?
A week of workshop, then 14 days to the first automation running on your own tickets. The full integration with fields, forms, SLA policies and the warehouse export takes 2 to 6 weeks, depending on how many systems stand on the other side. If BOND for the whole company is in scope, count on around 2 months.
How does a ticket link to the customer record in the CRM and to an order?
The Zendesk user and organization are matched to a contact and a company in the CRM by email address and domain, and we write the ticket id into a custom field on the CRM side. The order is matched on the number from the form, and when there is none, on the buyer's email address in the sales system. Cases with no unambiguous match go to manual review instead of being tied to the first hit.
Can fields be made mandatory when a ticket is submitted?
Yes, and it is the cheapest change on the whole list. The form picks its fields to match the type of case, and we mark some of them as required, so a return cannot come in without an order number. Fields the system knows and the customer does not are pulled in by the integration after the ticket is saved, so the form never grows to twenty boxes.
How do you measure SLA and what happens when a deadline is breached?
First reply and resolution time are measured by the SLA policy in Zendesk, in the business hours of the customer's market. An alert about an approaching deadline goes to Slack or Microsoft Teams, and a breach escalates to a manager together with a link to the case and the reason written onto the ticket. Night and weekend queues are settled against the working calendar, not against a 24-hour day.
How do we know what customers complain about most?
From the warehouse, not from what the team remembers. Tickets travel to BigQuery or a SQL database with their custom fields, tags, channel and reply times, and stay there after the case is closed. Then the split by category, channel and week is an ordinary query, and the AI agent answers the same question in a sentence, in 5 to 10 seconds.
How much does a Zendesk integration cost?
The process workshop is EUR 3,500 net per week and it is the only price we publish up front. We quote the integration after the workshop, because the cost depends on the number of fields, forms and systems on the other side. Your Zendesk plan and the cost of tools and models go to those vendors directly, with no margin from us.
Let us find out what is missing from your tickets
The free consultation takes 30 minutes and you talk to Paweł, the founder. You tell us how many tickets come in each week, which custom fields you use and what the rep has to check outside Zendesk to answer. We show you what can be added in the first 14 days, and what needs the data on the other side sorted out first. You do not have to share your systems at this stage.
We run at most two rollouts at a time, so that someone is genuinely sitting on each of them.
Book a free consultationPS. If a ticket went back to a customer this week with a question about an order number, that is exactly the problem. A field the form does not require stays empty, and an empty field will not feed a rule or a report. That is why we start with the ticket model and not with the tool.