Один ящик, много брендов: как проектировался Helpdash для мультиарендной поддержки

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

Helpdash начинает с другого конца. Рабочее пространство — это граница арендатора: свой домен, логотип, палитра и адрес отправки. Но агенты работают над этой границей, в едином окне разбора, охватывающем все пространства, к которым у них есть доступ. Переключение бренда — это фильтр, а не отдельный вход.

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

Если граница арендатора держится на том, что разработчик о ней помнит, это не граница.

Второе решение — форма цены, а это на самом деле продуктовое решение в маскировке. Оплата за место заставляет руководителя поддержки экономить на доступах: пятый агент — это разговор о бюджете, поэтому тикеты висят неназначенными всю ночь. Helpdash считает цену за рабочее пространство, поэтому добавить человека, который действительно может ответить, ничего не стоит.

Остаётся скучная половина: почта туда и обратно, веб-виджет, живой чат по WebSocket, многоязычная база знаний, таймеры SLA и CSAT. Ничего из этого не ново. Всё это должно выдержать утро понедельника.