Un chatbot para explicar las entregas, sin inventar dónde está un pedido

«Si compro el jueves por la tarde, ¿cuándo llega?» y «¿dónde está mi pedido?» pueden entrar seguidas en la misma conversación. Yo no encargaría las dos respuestas a un chatbot que solo consulta documentos. La primera puede resolverse con una política de entregas; la segunda necesita saber qué ha pasado con ese pedido concreto.

Empezaría por una tarea pequeña: explicar los plazos habituales, las zonas de reparto y cómo contactar si hay una incidencia. Sin autorizar devoluciones, cambiar direcciones ni prometer fechas que el negocio no haya confirmado.

Buscar una condición no es comprobar un envío

Para esa tarea prepararía una ficha con las condiciones vigentes: hora límite de preparación, días de reparto, zonas, excepciones y fecha de revisión. Si el texto no aclara qué ocurre los festivos, primero falta una decisión del negocio. El chatbot no debe rellenarla.

RAG es el nombre técnico de un mecanismo que busca fragmentos de información y se los da al modelo para redactar la respuesta. No hace falta aprender la sigla para entender la dependencia: si recupera una condición antigua o no encuentra la excepción, puede contestar mal. Microsoft describe el mecanismo y sus dificultades de recuperación.

En un ejemplo hipotético, la ficha dice que los pedidos recibidos después de las 14:00 se preparan el siguiente día laborable. Ante la pregunta del jueves, el sistema tendría que aclarar la hora y explicar esa regla. No debería convertirla en «te llegará el viernes» si no hay información suficiente para sostenerlo.

Para saber dónde está un pedido, hace falta una consulta autorizada al sistema que registra su estado, con identificación adecuada del cliente. Una política de entregas no contiene ese dato. Yo dejaría esa función fuera del primer piloto.

La prueba que haría antes de abrirlo

Tomaría mensajes anteriores, retirando los datos personales que no hagan falta, y prepararía una respuesta esperada para cada consulta. Añadiría preguntas que el sistema debe rechazar o derivar: una excepción no documentada, dos condiciones contradictorias, un pedido concreto y una petición de cambiar la dirección.

Revisaría cada resultado en tres pasos:

  1. ¿Encontró el documento y el apartado correctos?
  2. ¿La respuesta conserva la condición completa, sin inventar ni omitir una excepción?
  3. ¿Pide la aclaración necesaria o pasa a una persona cuando no puede resolverlo?

La separación entre buscar bien y responder bien coincide con la documentación de evaluación de Microsoft. Un enlace a la fuente ayuda a revisar; no convierte la respuesta en cierta.

No sé cuántas consultas resolvería en tu negocio. En una prueba limitada, mediría las respuestas correctas y completas, las derivaciones útiles, los fallos y los minutos de revisión. Contar mensajes contestados, sin mirar el resultado, puede ocultar trabajo que vuelve después en forma de reclamación.

Cuando toca pasar a una persona

Definiría la derivación antes de activar el chat: si falta una fuente, hay contradicción, aparece una reclamación o el usuario pide atención humana, el sistema debe ofrecer el canal previsto. El traspaso incluiría la pregunta y el contexto necesario para no obligar al cliente a empezar de cero.

Fuera del horario de atención, puede recoger la consulta y explicar cuándo se revisará, según el horario real. Tener el chat abierto de noche no significa que haya alguien resolviendo incidencias de noche.

Para explicar una política general, normalmente bastan la pregunta y, si afecta al plazo, la zona de entrega. No pediría un DNI ni acceso al historial de pedidos para eso. Antes de guardar conversaciones, definiría quién puede verlas, durante cuánto tiempo y qué servicio las procesa. Tener una base documental propia no resuelve por sí solo la privacidad.

Si todas las preguntas llevan a la misma ficha, probaría primero una página clara con ese enlace. Solo añadiría conversación si ayuda a encontrar la condición aplicable.

Escribe una respuesta correcta y una razón para derivar cada consulta antes de encargarle la tarea al chatbot.

Fuentes

  • Microsoft: RAG en Azure AI Search — Consultado el 10-10-2026. Recuperación de contenido, preparación de fuentes y control de acceso.
  • Microsoft: evaluación de recuperación y respuesta en RAG — Consultado el 10-10-2026. Relevancia de lo recuperado, fidelidad al contexto y completitud.
  • El escenario de entrega es hipotético. Las pruebas, derivaciones y selección de datos son criterios propuestos para el piloto; no resultados medidos ni una validación jurídica.

Puedes enviarme tres consultas frecuentes, sin datos personales, a hola@hebra.studio para plantearme una tarea concreta de atención.

Escríbeme