Un widget de soporte que ya sabe con quién habla

Una tienda con su propio help desk sigue teniendo un hueco: la tienda y el desk no saben el uno del otro. Un cliente con una duda sale del sitio, encuentra el desk por separado y abre un ticket como un desconocido, volviendo a teclear el nombre, el correo y el teléfono que la tienda ya tiene. El agente gasta después dos respuestas en averiguar con quién habla y de qué pedido se trata.

La respuesta del proveedor es un snippet que pegas en la plantilla. Eso cierra la mitad del hueco y abre tres problemas nuevos.

Problema uno: el snippet está en el sitio equivocado

El código dentro de una plantilla muere con el tema. Una actualización, un cambio a tema hijo, un traspaso a otro desarrollador, y el soporte desaparece en silencio. Nadie se entera, porque nada falla: sencillamente el widget ya no está.

Peor aún, cada ajuste pasa a ser una edición de código. Color, esquina, idioma, qué campos exige el formulario: todo vive en el marcado, así que cambiar uno implica un despliegue y un desarrollador.

Muévelo a un plugin con pantalla de ajustes. Es poco vistoso y es el arreglo completo de este problema.

Problema dos: la identidad hay que entregarla

Un widget que no sabe nada produce un ticket que empieza de cero. Pasar los datos del cliente identificado cuesta casi nada:

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

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

Fíjate en el array vacío. Sin sesión el widget se sigue renderizando, solo que sin datos de visitante. Esto importa más de lo que parece: la visita anónima es justo la que con más probabilidad tiene una pregunta previa a la compra, y un widget que falla o se esconde para quien no ha iniciado sesión retira el soporte precisamente donde más vale.

Problema tres: un widget global cuesta una consulta por página

Resolver el usuario y sus metadatos en cada renderizado añade una ida a la base de datos en todas las páginas del sitio, por un widget que la mayoría de visitantes nunca abre.

Cachéalo por usuario:

$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;

La clave tiene que incluir el identificador del usuario. Una clave compartida es la forma en que el nombre de un cliente acaba en el widget de chat de otro, y eso es una fuga de datos, no un problema de rendimiento. Siempre que caches algo derivado de quién pregunta, la identidad pertenece a la clave. Es la manera más fácil de convertir un cambio de caché en un incidente.

La colocación se elige, no se hereda

La inyección en el pie pone el widget en todas las páginas; un shortcode lo pone en una. Ambas son legítimas: una tienda lo quiere en todas partes, un sitio de documentación quizá solo en la página de contacto.

Soporta las dos y haz que compartan el mismo código de identidad. La tentación es construir primero la versión global y añadir después el shortcode copiando la función de renderizado, momento en el cual tienes dos widgets que empiezan a separarse.

Qué comprobar antes de darlo por hecho

Abre la tienda con sesión iniciada y confirma que el formulario arranca relleno. Después entra en una ventana privada y mira si el widget aparece igualmente, vacío y funcional. La segunda comprobación es la que más se salta la gente, y es la que caza el fallo con usuario nulo.

Luego revisa qué está enviando el widget en realidad. Manda a un servicio de terceros todo lo que le hayas dado, y «todo lo que le hayas dado» tiende a crecer. Un teléfono es razonable para una mesa de soporte. Un historial de pedidos, un identificador interno de cliente o un nivel de fidelidad seguramente entraron porque estaban a mano, no porque soporte los necesitara.