La respuesta que lee tu web y la que contestará un mensaje son la misma fila

Lo que un cliente pregunta antes de comprar se contesta hoy en tres sitios distintos: la web, el mensaje directo y el teléfono. Y cada sitio tiene su versión. La de la web está desactualizada, la del mensaje depende de quién esté de turno, y nadie sabe cuál es la buena.

La base de conocimiento entra en el sistema y sale por la API. La respuesta que se publica en la web y la que contestará un mensaje son la misma fila. Se corrige una vez y cambia en los dos sitios — que es el argumento entero de tener una sola capa, aplicado a la cosa más pequeña.

Los artículos se destilan de conversaciones de soporte reales, no de lo que uno cree que preguntan. La diferencia se nota en las formulaciones: la gente no escribe «¿cómo reservo una mesa?», escribe «cuánto hay que gastar para coger una mesa». Esas frases literales alimentan la búsqueda interna y no se publican nunca: traen contexto personal de quien las escribió, y el tipo de dato público no tiene ni un campo donde ponerlas.

Dos reglas más, que son de diseño y no de buena intención:

• Un artículo con una variable sin resolver no se publica. Una página que muestra {{telefono}} es peor que una pregunta que falta.
• Lo que escala a una persona no es contenido. Devoluciones, quejas y cobros son conversación: publicarlas como respuesta automática invita a que nadie escriba, que es justo lo contrario de lo que quieres.

Y una variable puede quedar deliberadamente sin valor, con el motivo escrito en el propio dato. Sin ese estado, el siguiente que mire la tabla ve un hueco, lo rellena creyendo que arregla un olvido y deshace una decisión de negocio.

Es la primera pieza del Inbox, no el Inbox. Falta el resto: los canales, la bandeja y la autonomía del agente.