Так. Krokul CRM інтегрується з GitHub. Запит клієнта, записаний у Krokul, відкриває issue в потрібному репозиторії. Issues, які створив клієнт, стають зверненнями Krokul з терміном SLA, а закритий issue чи злитий pull request закриває відповідну задачу чи звернення. Команди налаштовують це через застосунок Krokul у Zapier, Make чи n8n або через вебхук репозиторію й API Krokul.
Платформи автоматизаціїZapierMaken8n
Менеджер клієнта записує запит на зміну як задачу Krokul, привʼязану до угоди клієнта. GitHub App відкриває Issue в репозиторії, зіставленому з цим клієнтом, з назвою, терміном, міткою для таких запитів і посиланням назад у Krokul. Номер issue лишається в задачі, тож обидві сторони вказують на один запис.
Деякі клієнти повідомляють про помилки прямо в спільному репозиторії. Issue, відкритий там з їхнього акаунта, стає зверненням Krokul на контрагенті з терміном відповіді з ваших налаштувань SLA. Підтримка бачить відлік часу в Krokul, а розробники далі працюють у GitHub.
Коли зливають Pull Request з посиланням на issue або закривають сам issue, привʼязана задача Krokul переходить у done, а звернення в resolved. Якщо issue знову відкривають, звернення повертається в in_progress, і звіт SLA далі рахує його час.
Опублікований Release у репозиторії клієнта додає в угоду клієнта коментар із тегом і посиланням. Відділ продажу знає, що вийшло, ще до наступного дзвінка, і не читає нотатки до релізу в GitHub.
| GitHub | Напрям | Krokul | Коли |
|---|---|---|---|
| Issue | Krokul → GitHub | Задача | Запит клієнта записано як задачу |
| Issue (відкритий клієнтом) | GitHub → Krokul | Звернення з терміном SLA | Подія issues, дія opened |
| Issue (закритий чи знову відкритий) | GitHub → Krokul | Статус задачі, статус звернення | Подія issues, дії closed, reopened |
| Pull Request (злитий) | GitHub → Krokul | Задача done, звернення resolved | Подія pull_request, дія closed з merged: true |
| Коментар в issue | GitHub ↔ Krokul | Коментар у зверненні чи угоді | Коментар додано з будь-якого боку, і він пройшов фільтр |
| Release (опублікований) | GitHub → Krokul | Коментар в угоді | Подія release, дія published |
task.created, перевіряйте його заголовок x-crm-signature, відкривайте Issue через API GitHub і зберігайте номер issue в задачі через externalRef/api-upsert.issues, issue_comment, pull_request і release із секретом.X-Hub-Signature-256, беріть подію з X-GitHub-Event і викликайте роути Krokul, наприклад ticket/api-create, ticket/api-update чи task/api-updateStatus.Так. Krokul інтегрується з GitHub через застосунок Krokul у Zapier, Make і n8n, а також через свої API й вебхуки. Issues і pull requests лишаються привʼязаними до задач і звернень Krokul.
Основні події: issues (opened, closed, reopened), issue_comment, pull_request (closed і merged) і release (published).
Ні. Застосунок просить доступ до issues, pull requests і releases у вибраних вами репозиторіях. Код і диффи лишаються в GitHub.
В issues GitHub немає поля для часу. Години надходять із вашого трекера часу, і Krokul привʼязує їх до звернення, яке закрив цей issue.
Ні. Вебхук репозиторію з невеликим сервісом і API Krokul покривають звичні потоки. Застосунок Krokul у Zapier, Make чи n8n позбавляє потреби хостити такий сервіс.
Код, гілки, рев’ю й CI лишаються в GitHub. Krokul читає події issues, pull requests і releases з репозиторіїв, до яких ви дали доступ, і веде клієнтський бік кожного запиту: хто попросив, до якого терміну й що випущено.
Напишіть, яким сервісом ви користуєтесь і що має ходити між ним і Krokul. Ми відповімо способом і строком.
Запит отримано. Відповімо на вашу пошту.
GitHub є торговою маркою GitHub, Inc. Krokul не афілійований з GitHub.