Служба поддержки без кода: как собрать хелпдеск с ИИ

Чтобы сделать службу поддержки без кода, опишите в промпте, кто создаёт обращение, какие у него статусы и кто их разбирает, а ИИ-билдер соберёт приложение сам. В Zugo сборка стоит 6 кредитов и занимает около минуты. Базу и вход агентов даёт коннектор Supabase, письма клиентам уходят через Resend.

Хелпдеск это не форма обратной связи. Это очередь с состояниями, ответственными и историей, и именно эти три вещи нужно описать до того, как что-то собирать.

Когда нужен свой хелпдеск, а не готовый сервис?

Готовые системы поддержки хороши и их много. Свой имеет смысл в трёх случаях: когда процесс не укладывается в чужую логику, когда за каждого агента платить дорого при небольшой нагрузке, и когда обращения содержат данные, которые не хочется отдавать наружу.

Четвёртый случай самый частый и самый честный: вам нужна не поддержка, а внутренняя очередь заявок. Заявки на ремонт от арендаторов, обращения сотрудников в бухгалтерию, запросы на доступ. Промышленный хелпдеск здесь избыточен, а таблица уже не справляется.

Граница проходит по объёму. До нескольких десятков обращений в день собственное простое решение выигрывает по стоимости и по точности соответствия процессу. Дальше начинают быть нужны SLA, отчётность и интеграции, и разумнее смотреть на готовые системы.

Zugo не заменяет команду разработки на большом продукте поддержки. Он хорошо закрывает первый год жизни процесса, пока вы ещё выясняете, как он вообще должен работать.

Что написать в промпте?

Билдер сам придумает раскладку и оформление. Ваши статусы, роли и правила видимости он не угадает, поэтому их надо перечислить прямо.

Сделай веб-приложение «служба поддержки».
Роли: клиент и агент. Клиент видит только свои обращения,
агент видит все.
Обращение: тема, описание, категория ([оплата, доставка,
техническая проблема, другое]), приоритет ([низкий, обычный,
высокий]), автор, дата создания, дата последнего ответа.
Статусы: новое, в работе, ждёт ответа клиента, решено, закрыто.
Экран агента: список обращений с фильтром по статусу,
категории и назначенному агенту; сортировка по дате.
Карточка обращения: переписка сверху вниз, смена статуса,
назначение агента, внутренняя заметка, видимая только агентам.
Клиенту при смене статуса уходит письмо на почту.
Вход по почте. Тон интерфейса: деловой, плотный, без украшений.

Внутренняя заметка это тот пункт, который забывают чаще всего. Агенты обсуждают обращение между собой, и если такого поля нет, обсуждение уезжает в мессенджер и теряется вместе с контекстом.

Какие статусы и экраны нужны?

Статусов должно быть мало. Каждый лишний это ещё одно состояние, в котором обращение может застрять, и ещё одна причина спора о том, чем «в работе» отличается от «в процессе».

Экран сводки стоит добавлять последним. Пока обращений мало, его роль выполняет фильтр в очереди, и лишний экран только удлиняет сборку.

Форму создания обращения держите короткой. Каждое обязательное поле снижает шанс, что человек вообще напишет, а половину полей агент всё равно уточнит в переписке. Тема, описание и категория это разумный минимум; приоритет лучше ставить самому, потому что заявитель поставит высокий всегда.

Где хранить обращения и как пускать агентов?

Здесь без настоящей базы не обойтись. Коннектор Supabase даёт Postgres и вход по почте под вашим аккаунтом: переписка живёт в ваших таблицах, вы можете смотреть её через дашборд, делать выгрузки и не зависеть от подписки на один инструмент.

Правило видимости надо написать словами: клиент видит только свои обращения, агент видит все. Это не косметика, а разделение прав доступа, и проверить его надо самому в дашборде до того, как в системе появятся настоящие данные людей.

Письма о смене статуса доставляет Resend. Это тот элемент, из-за отсутствия которого клиенты пишут повторно: человек не видит движения и создаёт второе обращение по тому же поводу. Одно автоматическое письмо снимает заметную долю дублей.

Stripe нужен, если поддержка платная: подписка на приоритетный ответ или разовая оплата консультации. Google Analytics в закрытом приложении почти бесполезен, а вот экспорт кода в GitHub полезен сразу: разбор в статье про экспорт приложения в GitHub.

Сколько это стоит в кредитах?

Free даёт 5 кредитов: меньше одной полной сборки, так что это способ осмотреться. Pro стоит $25 в месяц и даёт 200 кредитов, Business стоит $99 в месяц.

Перед выдачей проект запускается в песочнице, и сборка, которая не открылась, отмечается как ошибка вместо белого экрана. Риск это снижает, но не убирает: заведите тестовое обращение и проведите его по всем статусам сами.

Как доводить процесс правками?

Хелпдеск это тот случай, где первая версия почти наверняка не совпадёт с реальностью. Через две недели работы выяснится, что нужен статус «ждёт поставщика», что категорий на две больше и что приоритет надо ставить автоматически по категории.

Каждое такое изменение это одна правка за 3 кредита, сформулированная фразой: «добавь статус „ждёт поставщика" между „в работе" и „решено" и не считай время в этом статусе в срок ответа». Именно так очень специфичная логика и доводится: серией правок, а не одним идеальным промптом.

Полезная привычка: меняйте по одному правилу за раз и проверяйте на тестовом обращении. Пакет из пяти изменений одной фразой обычно даёт результат, в котором непонятно, что именно сработало не так.

Как не превратить очередь в свалку?

Хелпдеск умирает одинаково во всех компаниях: обращения копятся в статусе «в работе», никто за них не отвечает, и через два месяца в системе висит триста тикетов, на которые все перестали смотреть. Лечится это тремя правилами, и все три встраиваются в приложение.

Первое: у обращения всегда есть назначенный агент. Тикет без ответственного это тикет, которым не занимается никто. Сделайте поле обязательным при переводе в работу и покажите в очереди отдельным фильтром всё, что без назначения.

Второе: статус «ждёт ответа клиента» обязан закрываться сам. Обращение, в котором клиент молчит две недели, надо автоматически переводить в закрытое с письмом «мы закрыли, ответьте, и оно откроется снова». Иначе такие тикеты живут вечно и портят любую статистику.

Третье: считайте не количество, а возраст. Сводка «открыто 40 обращений» ни о чём не говорит. Сводка «7 обращений без ответа дольше суток» говорит всё и показывает ровно ту работу, которую надо сделать сегодня.

Каждое из этих правил добавляется одной правкой за 3 кредита, и добавлять их лучше по одному, проверяя на тестовом обращении.

Чего такой хелпдеск не даст?

• Приём писем как обращений. Разбор входящей почты в тикеты требует почтового шлюза и разбора заголовков. Это работа разработчика.
• SLA и эскалации. Таймеры, автоматическое повышение приоритета и отчёты по нарушениям доводятся правками, но полноценную систему замеров они не заменят.
• Телефонию и чат на сайте. Живой чат с операторами и запись разговоров это отдельные сервисы со своими интеграциями.
• Готовую базу знаний с поиском. Статьи собрать можно, а нормальный полнотекстовый поиск по ним это отдельная задача.

Между этими границами остаётся рабочая очередь с ролями, статусами, историей и уведомлениями. Для внутреннего процесса или небольшой команды поддержки этого хватает надолго.

С чего начать?

Соберите версию с тремя статусами и двумя ролями, подключите Supabase и Resend, заведите пять настоящих обращений руками. Через неделю вы увидите, какого статуса не хватает, и добавите его одной фразой.

Если обращения приходят от клиентов, за которыми надо вести историю сделок, а не только тикетов, посмотрите разбор CRM без программиста. Если поддержка платная и нужны счета, соседний сценарий описан в статье про выставление счетов. Свою очередь описывайте на zugo.dev теми словами, которыми объясняете процесс новому сотруднику.