Виджет поддержки, который уже знает, с кем разговаривает

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

Ответ вендора выглядит как сниппет, который вы вставляете в тему. Он закрывает половину разрыва и открывает три новые проблемы.

Проблема первая: сниппет лежит не там

Код в шаблоне темы умирает вместе с темой. Обновление, переход на дочернюю тему, передача проекта новому разработчику, и поддержка молча исчезает. Никто не замечает, потому что ошибок нет. Виджета просто больше нет.

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

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

Проблема вторая: личность надо передать

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

$visitor = $user
    ? ['visitor_name' => $user->getName(),
       'visitor_email' => $user->getEmail(),
       'visitor_phone' => $user->getPhone()]
    : [];

return [...$settings, ...$visitor];

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

Проблема третья: виджет на всём сайте стоит запроса на страницу

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

Кэшируйте по пользователю:

$cached = wp_cache_get('freescout_user_' . $user_id);
if ($cached) return unserialize($cached);

$dto = $this->loadFromDb($user_id);
if ($dto) wp_cache_set('freescout_user_' . $user_id, serialize($dto));
return $dto;

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

Размещение выбирают, а не наследуют

Вставка в футер даёт виджет на каждой странице, шорткод - на одной. Оба варианта законны: магазину он нужен везде, а сайту документации может хватить страницы контактов.

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

Что проверить перед тем, как считать сделанным

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

Дальше посмотрите, что виджет реально отправляет. Он передаёт стороннему сервису всё, что вы ему дали, а объём «всего, что дали» имеет свойство расти. Телефон для поддержки разумен. История заказов, внутренний идентификатор клиента или уровень лояльности попали туда, скорее всего, потому что были под рукой, а не потому что поддержке они нужны.