Email: универсальный, но медленный
Сильные стороны:
- Не требует ничего изучать — все умеют писать письма.
- Подходит для длинных задач с приложениями, скриншотами, документами.
- Создаёт письменный след — полезно для последующего разбора.
- Асинхронный по своей природе — оператор не «спешит», думает.
Слабые стороны:
- Невозможен сложный многораундовый диалог (быстро становится длинной цепочкой forward).
- Сложно отделить «важно сейчас» от «можно к завтра».
- Spam и mail-bounce ломают workflow.
- Нет видимости статуса для пользователя: «решили ли мою заявку?»
Когда подходит: внешние клиенты, разовые обращения, обращения, требующие документов или подробного описания.
Портал с тикетами: структура и контроль
Сильные стороны:
- Шаблоны заявок собирают всю нужную информацию сразу (приоритет, услуга, custom-поля).
- Пользователь видит статус, историю переписки, прогресс.
- Категоризация автоматически разводит заявки по командам.
- SLA-таймеры стартуют точно с момента отправки.
Слабые стороны:
- Нужна авторизация — для внешних клиентов это барьер.
- Пользователь не любит «новые системы» — будет писать на email до тех пор, пока не запретите.
- Не подходит для срочных «горящих» проблем — пока заполнишь шаблон, проблема ещё больше.
Когда подходит: внутренняя поддержка с зрелыми процессами, обращения по плановой работе, типовые операции по чек-листу (заказ ноутбука, доступы), обращения, по которым важна аналитика.
Чат / мессенджер: быстрый, но грязный
Сильные стороны:
- Быстрая реакция «на лету» — секундная переписка.
- Удобно для коротких вопросов «как сделать X».
- Пользователь использует уже знакомый интерфейс (Telegram, MS Teams, WhatsApp Business).
- Идеален для конференций и видео при сложной диагностике.
Слабые стороны:
- Каждое обращение — заявка? Или не каждое? Без правил — хаос.
- SLA непонятно: «прочитал в 9:23, ответил в 9:28» — что считать реакцией?
- Контекст теряется после нескольких сообщений: «о чём шла речь?» — листайте 200 сообщений вверх.
- Невозможно прикрепить большой документ или провести экспертное обсуждение в полноценной нити.
Когда подходит: мелкие вопросы «как», уточнения по уже открытому тикету, начало диалога который потом всё равно перейдёт в тикет.
Как объединить в одну систему
Цель — чтобы оператор видел все три канала в одном интерфейсе, и каждое обращение, независимо от источника, попадало в тикет с историей.
- Email → тикет автоматически. Письмо на support-адрес создаёт заявку. Ответ оператора пользователю — отправляется письмом, ответ пользователя на письмо — комментарий в той же заявке (по номеру в теме). В TIQQET это реализовано из коробки.
- Портал → тикет напрямую. Самый правильный канал — заполненный шаблон сразу попадает в нужный статус.
- Чат → бот → тикет. Telegram-бот / Teams-бот собирает запрос, создаёт тикет с пометкой «из чата», далее общение через бота — комментарии в тикете в реальном времени.
- Видимость для пользователя. Пользователь в любой момент может перейти на портал и увидеть свои заявки независимо от того, откуда они пришли.
Рекомендации по каналам в типичной компании
| Тип обращения | Рекомендуемый канал |
|---|---|
| «Не работает почта» | Чат / телефон — нужна быстрая реакция |
| Запрос на нового сотрудника (10 заявок) | Портал — шаблон с автоматизацией |
| «Хочу обновить ПО на ноуте» | Портал — шаблон с выбором ПО |
| Сложная проблема с разработкой | Email — длинный текст с логами |
| «Как мне настроить VPN?» | База знаний → чат если не нашёл → тикет если нужна помощь |
| Жалоба, требующая разбора | Email — формальный канал с подписью |
Главное правило: не запрещайте каналы, но направляйте. На лендинге портала покажите, для какого вопроса какой канал быстрее.
Попробуйте TIQQET в деле
On-premise ServiceDesk с полным циклом заявок, SLA-контролем и мобильными приложениями. Развёртывание за 1 день.
Частые вопросы
Какой канал самый дешёвый для компании?
Сам по себе — портал. Но без обучения пользователей на портал не пойдут, и стоимость окажется выше. Поэтому в первый год часто email — основной (привычный) + портал параллельно.
Telegram-бот для поддержки — это нормально?
Да, для внутренней поддержки в РФ — нормально. Из плюсов: пользователи уже там. Из минусов: данные идут через серверы Telegram, не подходит для гостайны и чувствительных данных. Альтернатива — Mattermost / Rocket.Chat self-hosted.
Можно ли совсем отказаться от email?
Нельзя. Регуляторы и внешние организации присылают сообщения именно почтой. Минимум — оставить почтовый адрес для приёма входящих, даже если ответ пользователю всегда даёте через портал.
Как считать SLA для чата?
По первому сообщению оператора, видимому пользователю. Если бот сразу ответил автотекстом «приняли в работу» — это начало реакции. Дальше — обычный SLA-таймер.
Сколько каналов разумно поддерживать?
Два-три максимум. Email + портал + (опционально) один чат-канал. Больше — операторы не успевают переключаться, теряют контекст, страдает качество.