Как собирать баг-репорты от клиентов: схема для веб-агентств

отзывы клиентов

Это письмо знакомо любому агентству. Тема «проблема с сайтом», текст «форма на странице контактов не работает у меня на компьютере», отправитель — клиент, в копии — его ассистент, письмо дважды переслано. Ни браузера, ни URL, кроме «страницы контактов», ни ошибки, зато есть скриншот документа Word, внутри которого скриншот. Через два оплачиваемых часа выясняется, что виновато расширение браузера.

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

Почему почта — худший канал из возможных

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

  • Круги уточнений. «Какой браузер? Можете прислать точную ссылку? Что вы нажали сначала?» Каждый круг занимает день по календарю и часть терпения клиента.

  • Нет общего статуса. Клиент не знает, видели ли вы письмо, работает ли кто-то над проблемой и почему то, о чём он писал месяц назад, до сих пор не исправлено. Поэтому он пишет снова, и на эти письма тоже нужно отвечать.

  • Нет границ между проектами. Десять клиентов на абонентской поддержке — это баг-репорты с десяти сайтов вперемешку в одном ящике, и каждый нужно вручную распределить, перенести в трекер и отслеживать.

Выходит, что от клиента ждут работы QA-инженера — заметить, задокументировать, дать контекст, — а он этого не умеет и не обязан. Решение — перестать просить.

Модель с виджетом

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

В BugDump установка — один тег script на сайт:

HTML
<script src="https://bugdump.com/sdk/latest.js" async data-api-key="site-specific-key"></script>

Что важно для агентства:

  • Один проект на сайт клиента. У каждого проекта свой ключ, своя доска и своя история отчётов. Ничего не смешивается. Тариф Ultra вмещает до 100 проектов — как раз для такой работы.

  • Без брендинга BugDump. На платных тарифах с виджета убирается брендинг BugDump, и виджет выглядит частью сайта, который сделали вы, а не чужой надстройкой.

  • Под стиль сайта. Тема (светлая, тёмная, авто), иконка кнопки, положение и все строки интерфейса настраиваются — вплоть до полного перевода для клиентов, чьи сайты не на английском.

  • На приёмке приглашайте оставлять отчёты. Подсказка рядом с кнопкой («Заметили проблему?») превращает раунды правок из PDF с размеченными скриншотами в структурированные отчёты, которые можно разбирать по одному.

Для клиента всё сводится к простому: увидел проблему, нажал, написал предложение, готово. Ни входа, ни формы, ни «каким браузером вы пользуетесь» — больше никогда.

Что меняется на вашей стороне

Отчёты приходят готовыми к диагностике. Ошибка в консоли и упавший запрос лежат в отчёте. Ложная тревога из-за расширения браузера выясняется за минуты, а не после пересборки сайта. «Не воспроизводится» почти исчезает, потому что вы читаете сбой, а не пытаетесь его повторить.

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

Баги попадают в ваш рабочий процесс. Интеграции пересылают отчёты туда, где команда уже работает: в Slack или Discord, чтобы все были в курсе, в GitHub Issues, Jira или Asana — те, что становятся тикетами. Никакого ручного переноса, и ни один баг не теряется между почтой и бэклогом.

Первичный разбор можно поручить ассистенту. Через MCP-сервер BugDump Claude Code или Cursor читают отчёты проекта вместе с консолью, сетью и воспроизведением сессии. На абонентской поддержке «кратко опиши отчёты за неделю по сайту Meridian и отметь всё, что похоже на регрессию» — обычный запрос в понедельник утром.

Передача проекта

Агентству важно чисто выходить из проектов. Помогут две практики:

Ограничивайте доступ проектом. Ключи привязаны к проекту, поэтому подрядчик, который помогает с сайтом одного клиента, видит только этот проект. Если человек уходит с проекта, MCP-ключи можно сразу сменить в настройках.

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

Что это даёт абонентской поддержке

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

Затраты небольшие и предсказуемые: один тег script на сайт и цена по объёму, а не за места, — поэтому в курсе может быть вся ваша команда и команда клиента, и места считать не нужно.

Письма всё равно иногда будут приходить. Но «просто нажмите на странице кнопку для бага и отправьте» — это ответ в одну строку, а отчёт, который придёт после него, вы действительно сможете исправить.

Читайте также