CRMUSТікет підтримки в Zendesk відкривається з уже видимими угодами клієнта, розв'язаний тікет потрапляє в історію клієнта в CRM, а продажі дізнаються про скаргу раніше, ніж клієнт їм подзвонить.
Zendesk — там, де живе підтримка: тікети з пошти, чату, телефону й соцмереж, агенти, правила відповідей. CRM — там, де живуть клієнт, угода і гроші. Між ними зазвичай є розрив — підтримка не бачить, що людина, яка пише, є клієнтом із відкритим продовженням, а продажі не бачать, що в клієнта три нерозв'язані тікети. Під'єднання закриває цей розрив: новий тікет зіставляється з карткою клієнта за поштою чи телефоном і показує агенту угоди й менеджера клієнта; розв'язаний тікет записується в історію клієнта в CRM; тікет, позначений як терміновий або як скарга, одразу показується менеджеру клієнта; а виграна в CRM угода може відкрити вітальний тікет для онбордингу. Агенти й далі працюють у Zendesk, менеджери — у CRM, і обидві сторони бачать того самого клієнта.
Було клієнт пише в підтримку, агент не знає, хто це, відповідає як незнайомцю, і лише потім дізнається від продажів, що це ключовий клієнт посеред продовження.
Стало тікет зіставляється з карткою клієнта за поштою, і агент бачить менеджера клієнта, відкриті угоди й останнє замовлення просто в тікеті — і відповідає відповідно.
Було менеджер телефонує клієнту з пропозицією апгрейду, не знаючи, що клієнт минулого тижня сперечався з підтримкою.
Стало кожен розв'язаний тікет записується в історію клієнта в CRM з темою, результатом і посиланням, тож менеджер читає останні три тікети, перш ніж узяти слухавку.
Було агент ставить на тікет тег «скарга», а продажі дізнаються за тиждень, коли клієнт відмовляється продовжувати.
Стало щойно тег поставлено, менеджер клієнта отримує задачу в CRM із посиланням на тікет і телефонує клієнту того ж дня.
Було після продажу менеджер пише підтримці в чат «будь ласка, проведіть онбординг цього клієнта», і прохання губиться серед інших повідомлень.
Стало щойно угоду позначено як виграну, у Zendesk у черзі онбордингу з'являється тікет із даними клієнта й домовленостями; підтримка починає, нікого не питаючи.
Для тих, хто перевіряє: кожен пункт веде на сторінку офіційної документації, звідки він узятий.
Support API Zendesk (Ticketing API) працює з тікетами, користувачами, організаціями та бізнес-правилами; тікети можуть приходити з пошти, Help Center, чату, телефону, соцмереж або API.
Джерело: developer.zendesk.com ↗ перевірено 2026-09-28Створення тікета підтримує ключ ідемпотентності, тож повторний запит не створює дубль тікета.
Джерело: developer.zendesk.com ↗ перевірено 2026-09-28Вебхуки надсилають HTTP-запит на обрану адресу, коли в Zendesk Support щось стається — наприклад, створено тікет; невдалі запити повторюються, а запобіжник захищає зламані адреси.
Джерело: developer.zendesk.com ↗ перевірено 2026-09-28Тригери тікетів виконують дії при створенні чи оновленні тікета, якщо виконані умови; усі тригери перевіряються по порядку при кожній зміні тікета.
Джерело: developer.zendesk.com ↗ перевірено 2026-09-28Запити до API можуть робити лише верифіковані користувачі; Zendesk підтримує OAuth-токени доступу і вимагає TLS 1.2 для всіх з'єднань.
Джерело: developer.zendesk.com ↗ перевірено 2026-09-28Zendesk виводить API-токени з обігу: з 28 липня 2026 невикористані 30 днів токени видаляються, а до 30 квітня 2027 усі API-токени перестануть працювати — інтеграції мають перейти на OAuth.
Джерело: support.zendesk.com ↗ перевірено 2026-09-28Zendesk обмежує, як часто до нього можна звертатися: кількість запитів за хвилину залежить від вашого тарифу, а при перевищенні Zendesk відповідає помилкою 429 і вказує, скільки секунд зачекати; вищий ліміт доступний окремим доповненням. Один агент може оновити той самий тікет не більше 30 разів за 10 хвилин, а одночасно в черзі чи в роботі може бути не більше 30 масових завдань, тож масові зміни йдуть порціями. Сповіщення від Zendesk налаштовує лише адміністратор або агент із власною роллю, що це дозволяє; вони доставляються максимально близько до реального часу, але іноді із затримкою, повторюються до трьох разів, якщо наш бік не відповідає, не гарантують порядку надходження, а повідомлення, яке надсилає Zendesk, не може перевищувати 16 000 символів. Сам Zendesk попереджає не оновлювати тікети прямо зі сповіщення, бо це спричиняє конфлікти й помилки ліміту, — тож записи назад у Zendesk ідуть через чергу. Пробні облікові записи обмежені 10 сповіщеннями і 60 викликами за хвилину. Старіші ключі-паролі (API-токени) вимикаються: невикористані 30 днів токени видаляються з 28 липня 2026, а всі вони перестають працювати до 30 квітня 2027, — тож ми від початку будуємо під'єднання на вході з явною згодою, для якого адміністратор має його зареєструвати.
Три кроки від першого повідомлення до роботи над вашим проєктом.
Опишіть задачу у формі — текстом або голосом. Бюджет і строки — за бажанням.
Розробник вивчає ТЗ, уточнює незрозуміле й надсилає оцінку.
Щойно обсяг і ціну узгоджено, починаємо роботу.
або напишіть на info@coreviaflow.space
Опишіть задачу текстом або голосовим. Ми подивимось, що у вас є, і відповімо планом.
Чотири послуги, з якими до нас приходять найчастіше. На кожній сторінці — що робимо, як іде робота і з чого почати.
Підібрати систему, налаштувати воронку, перенести дані, навчити команду.
Детальніше →Облік, телефонія, сайт, оплати й месенджери самі наповнюють CRM.
Детальніше →Замовлення, заявки та відповіді цілодобово, одразу у вашу CRM.
Детальніше →Сценарії між CRM, поштою, таблицями, оплатами та ШІ на вашому сервері.
Детальніше →
Маркетинг та email-розсилкиUSЧати з сайту й месенджерів, які стають контактами в CRM: ШІ-помічник на першій лінії, менеджер — на гарячих
Дивитись сценарії →
CRMUSCRM для ринку США з вбудованими дзвінками та автоматизацією без коду, готова підключитися до інструментів, якими ви вже користуєтесь
Дивитись сценарії →
Автоматизація та робочі інструментиUSSlack як пульт команди: ліди, угоди й дзвінки з CRM потрапляють у канал, і команда реагує, не виходячи з чату
Дивитись сценарії →
Автоматизація та робочі інструментиUSЛисти клієнтів потрапляють у картку угоди в CRM, відповіді йдуть з адреси менеджера, а ШІ готує чернетку — але не надсилає сам.
Дивитись сценарії →
Автоматизація та робочі інструментиUSZapier з'єднує сервіси без коду: ми налаштовуємо зв'язки або замінюємо їх власним кодом, коли кроків стає забагато
Дивитись сценарії →
CRMUSКорпоративна CRM з живою стрічкою подій і автоматизацією без коду для будь-якого типу записів
Дивитись сценарії →Впровадження · Розробка · Інтеграції →
Zendesk — товарний знак правовласника. CoreviaFlow не афілійована з ним, якщо не вказано інше. Скриншоти взяті з відкритих матеріалів розробника, джерело — під кожним.
