Як створити систему helpdesk: заявки, статуси, призначення та email

Helpdesk-система заявок перетворює розпорошені запити (листи, повідомлення, «швидкі питання» в коридорі) на заявки: один запис на одну проблему з власником, статусом, пріоритетом і повною розмовою. Щоб її створити, потрібні спосіб створити заявку, спільна черга з фільтрами, призначення, гілка, яка відокремлює публічні відповіді від внутрішніх нотаток, і сповіщення, щоб ніхто не чекав без відповіді. ШІ-конструктор застосунків може за один день створити непогану першу версію для внутрішнього ІТ-, HR- або господарського відділу. Підтримка клієнтів з потоками листів, цільовими строками відповіді та звітністю потребує більше уваги, і саме тут готові helpdesk-продукти виправдовують свою ціну.

Що має вміти система

Дані

Зберігайте часові позначки першої відповіді та вирішення від самого початку. На них спираються всі звіти, а відновити їх потім неможливо.

Сторінки

• Заявник: форма «подати запит» з категорією та вкладеннями, список «мої запити» та гілка кожної заявки.
• Агент: черга (мої заявки, без виконавця, усі відкриті), фільтри та пошук, перегляд заявки з полями відповіді, нотатки, статусу, пріоритету і призначення.
• Адміністратор: категорії, команди, агенти, шаблони відповідей і простий звіт.

Права доступу

Заявники бачать лише свої заявки і лише публічні відповіді. Агенти бачать заявки своєї команди та внутрішні нотатки. Керівники й адміністратори бачать усе та керують налаштуваннями. Витік внутрішніх нотаток клієнту — класична катастрофа helpdesk, тож забезпечуйте це на сервері, а не просто приховуванням вкладки. Див. рольовий доступ.

Рішення та компроміси

Форма, email чи обидва способи

Веб-форма — найпростіша і дає чисті дані: категорія, пріоритет, обов’язкові поля. Прийом email — коли люди пишуть на support@ і з’являється заявка, — це те, чого очікують клієнти, але для цього потрібен провайдер email, який уміє приймати листи та передавати їх вашому застосунку, а також ланцюжки, щоб відповіді прив’язувалися до правильної заявки (зазвичай номер заявки в темі або унікальна адреса для відповіді). Почніть з форми, а email додавайте, коли робочий процес перевірено. Надсилання email із застосунку описує вихідну частину.

Призначення

Варіанти: агенти беруть заявки з черги без виконавця; циклічний розподіл у межах команди; призначення за категорією. Вибір із черги працює для невеликих команд. Автоматичне призначення допомагає, коли заявки довго лежать без власника.

Пріоритети та цільові строки відповіді

Визначте два-три пріоритети з ціллю для першої відповіді («терміново: 1 година, звичайний: 1 робочий день»). Показ часу, що лишився, на кожній заявці корисніший за місячний звіт, який ніхто не читає. Робочі години ускладнюють розрахунки, тож рано вирішіть, чи враховуються ночі та вихідні.

Об’єднання та дублікати

Одна й та сама проблема, повідомлена тричі, — звичайна ситуація. Дія «об’єднати з заявкою №» позбавляє агентів необхідності відповідати на одне й те саме кілька разів, тож її варто створити рано.

Перший промпт, який працює

Створи внутрішній ІТ-helpdesk для компанії з 60 працівників. Співробітники подають запити через форму: тема, категорія (обладнання, програми, доступ, мережа, інше), пріоритет (низький, звичайний, терміновий), опис і вкладення. Кожна заявка отримує номер і статуси: нова, відкрита, очікує на заявника, вирішена, закрита. ІТ-агенти бачать чергу з вкладками «без виконавця», «мої» і «усі відкриті», фільтри за категорією, пріоритетом і статусом та пошук. Сторінка заявки показує гілку з публічними відповідями та внутрішніми нотатками, чітко розділеними; співробітники ніколи не бачать внутрішніх нотаток. Агенти можуть призначати, змінювати статус і пріоритет, використовувати шаблони відповідей і об’єднувати дублікати. Відстежуй час першої відповіді й вирішення та показуй час від останнього оновлення на кожній заявці. У співробітників є сторінка «мої запити». Ролі: співробітник, агент, адміністратор. Усе зберігай у базі даних. Простий, щільний і швидкий інтерфейс: швидкість важливіша за оздоблення.

Кроки побудови

1. Модель заявки і форма. Подати, переглянути список, відкрити заявку, відповісти.
2. Черга і фільтри. Без виконавця, мої, усі відкриті; фільтри та пошук; сортування за пріоритетом і віком.
3. Ролі та вхід. Заявник, агент, адміністратор — із внутрішніми нотатками, прихованими від заявників на сервері.
4. Керування призначенням, статусом і пріоритетом з журналом активності кожної зміни.
5. Сповіщення. Надсилайте заявникові повідомлення про публічні відповіді, а агентові — про нові призначення, через власного провайдера email.
6. Шаблони відповідей і об’єднання.
7. Цільові строки та простий звіт: відкриті заявки за віком, час першої відповіді, заявки за категоріями.
8. Прийом email, коли решта вже працює, із ретельним тестуванням ланцюжків.
9. Пілот з однією командою протягом двох тижнів, перш ніж переводити всіх.

Типові помилки

• Внутрішні нотатки видно заявникам, бо їх приховали лише в інтерфейсі.
• Забагато статусів і категорій. Агенти вибирають перший, який здається схожим. Починайте з не більше ніж п’яти кожного.
• Немає часових позначок першої відповіді та вирішення. Ці цифри знадобляться в день, коли хтось запитає, чи ми швидшаємо.
• Відповіді на email створюють нові заявки замість прив’язки до старих. Тестуйте відповідь із поштового застосунку на телефоні, бо він часто змінює теми.
• Усі призначені, ніхто не відповідає. Одна заявка — один виконавець; для решти використовуйте спостерігачів.
• Вкладення з публічними посиланнями. Скріншоти повідомлень про помилки часто містять приватні дані. Тримайте файли приватними і віддавайте їх лише тим, хто бачить заявку.

Коли краще готовий продукт

Для підтримки клієнтів через email, чат і соцмережі, з відстеженням цільових строків, опитуваннями задоволеності, макросами, звітами та інтеграціями, спеціалізований helpdesk-продукт майже завжди краще вкладення. Такі продукти роками відточували прив’язку листів, спам, маршрутизацію і звіти, а це не та частина бізнесу, якою ви відрізняєтеся. Наш гід альтернатив Zendesk порівнює варіанти.

Власна розробка підходить для внутрішніх служб (ІТ, HR, господарський відділ, запити фінансового відділу), нішевих процесів, де заявка насправді є роботою з конкретними кроками, і команд, яким потрібно пов’язувати запити з іншими даними, які вони вже ведуть. Вона також позбавляє від оплати за кожного агента, коли багато людей час від часу обробляють заявки. Гід із внутрішніх інструментів ширше розглядає цю категорію.

Створення з Mythex

У Mythex ви описуєте helpdesk у чаті, переглядаєте його в живому прев’ю і публікуєте для команди. Заявки зберігаються в базі Postgres, яку агент додає, коли потрібно зберігати дані, а вкладення — у сховищі файлів проєкту. Входи для заявників і агентів, а також вся пошта вхідна й вихідна працюють через власних провайдерів: Mythex не має вбудованого продукту для входу кінцевих користувачів чи email. Рецепт надсилання email показує підхід. Члени команди можуть допомагати створювати застосунок через спільний робочий простір без оплати за місце самим Mythex.

Як стартовий промпт спробуйте шаблони внутрішня черга запитів або трекер багів, а helpdesk поєднайте з базою знань, щоб типові питання вирішувалися самі.

Запитання