Para reservar sin errores, un asistente de IA necesita seis datos: el servicio, quién lo hace o con qué recurso, la sede, la fecha y la hora completas, la persona que va a la cita con un contacto, y un «sí» del cliente al resumen. Si falta uno, la cita sale mal aunque la conversación haya sido amable. Es lo primero que se define al montar un asistente de IA a medida que da citas.
Esta pieza trata de qué datos son y cómo se comprueba cada uno antes de escribir en la agenda. Qué datos no conviene pedir por chat, como un diagnóstico, está en cómo automatizar reservas por WhatsApp; dónde vive la cita una vez creada, en cómo conectar conversaciones, clientes y agenda. No se repite aquí.
Por qué un asistente reserva mal
Un asistente de IA no falla al reservar porque escriba mal, sino porque convierte una frase ambigua en un dato que parece exacto. «El jueves por la tarde con Laura» acaba siendo una cita a una hora concreta, con una profesional concreta, en una sede concreta. Si alguno de esos valores lo ha supuesto el modelo, nadie lo ve hasta que el cliente se presenta.
La documentación de Anthropic sobre el uso estricto de herramientas lo explica con un ejemplo de reservas: sin el modo estricto, el modelo podría devolver tipos incompatibles u omitir campos obligatorios, y donde un sistema de reservas espera el número 2 en el campo de pasajeros podría recibir «two» o «2». Con strict: true, Anthropic garantiza que la entrada de la herramienta sigue el esquema definido.
Lo que esa garantía no cubre es que el dato sea verdad. Un esquema estricto asegura que llega una fecha con formato de fecha; no asegura que sea el jueves que el cliente quería. Por eso los seis datos se tratan de dos formas: lo que tiene una lista cerrada se elige de la lista, y lo que no la tiene se repite al cliente antes de reservar.
Los seis datos, uno por uno
1. El servicio, de una lista cerrada
El servicio decide la duración, el precio y quién puede hacerlo, así que no puede ser texto libre. El asistente tiene que traducir lo que escribe el cliente («algo para las manchas», «repasar el tinte») a uno de los servicios del negocio, con su duración ya fijada.
En la guía para definir herramientas, Anthropic dice que dar descripciones extremadamente detalladas es, con diferencia, el factor más importante en el rendimiento de una herramienta: qué hace, cuándo debe usarse y cuándo no, y qué significa cada parámetro. Traducido a una agenda: cada servicio con su nombre, su duración y una línea sobre cuándo es ese y no otro. Si el cliente pide algo que no encaja con ninguno, la respuesta correcta es preguntar o pasar a una persona, no elegir el más parecido.
2. Quién lo hace o con qué recurso
Si el negocio tiene más de un profesional, una cabina, un sillón o una sala, la cita necesita saber cuál, aunque el valor sea «me da igual». «Me da igual» es un dato válido: permite buscar el primer hueco de cualquiera. Lo que no vale es que el asistente lo decida en silencio cuando el cliente ha nombrado a alguien.
El caso que más falla es el de la clienta que dice «con la de siempre». El asistente solo puede resolverlo si la ficha del cliente guarda con quién fue la última vez; si no lo sabe, pregunta.
3. La sede, si hay más de una
Con dos locales, la sede forma parte de la cita igual que la hora. Un hueco libre en un local no sirve en el otro, y el cliente que escribe al número general no siempre dice a cuál va.
En España la sede también puede cambiar la hora. El Real Decreto 236/2002, que regula la hora de verano, fija el cambio de marzo «a las dos horas de la madrugada (la una hora de la madrugada en Canarias)»: Canarias va una hora por detrás de la península todo el año. Un negocio con un centro en Madrid y otro en Las Palmas no puede guardar «las 10:00» sin decir de qué reloj.
4. La fecha y la hora, completas y sin pronombres
«Mañana», «el jueves» o «a primera hora» no son datos de agenda: el asistente tiene que convertirlos en día, mes, año y hora antes de reservar. Para hacerlo bien necesita saber qué día y qué hora es en el negocio en ese momento; un «mañana» escrito a las 00:30 ya no significa lo mismo que a las 23:50.
Google Calendar lo pide así. En la referencia del recurso de eventos de su API (actualizada el 7 de julio de 2026), la hora de inicio es un valor combinado de fecha y hora en formato RFC 3339, y la documentación dice que es obligatorio un desfase horario salvo que se indique la zona en el campo timeZone, con un nombre de la base de datos de zonas horarias de la IANA, como «Europe/Zurich». Para un negocio en la península, eso es «Europe/Madrid»; en Canarias, «Atlantic/Canary».
El cambio de hora es la otra trampa. El mismo Real Decreto 236/2002 fija el inicio del horario de verano el último domingo de marzo y el final el último domingo de octubre, y precisa que ese día de octubre dura veinticinco horas. Las próximas fechas, por cálculo propio a partir de esa regla, son el 28 de marzo y el 31 de octubre de 2027. Si el sistema guarda la cita con su zona horaria, el cambio no la mueve; si guarda una hora suelta copiada a mano, puede quedar desplazada una hora en el calendario de alguien.
5. Quién va a la cita, y cómo avisarle
La persona que escribe no siempre es la que va a la cita: una madre que pide hora para su hijo, alguien que reserva para su pareja. La cita necesita el nombre de quien será atendido y un contacto para avisarle o confirmarle, que puede ser el mismo número de la conversación o no.
Aquí sobra casi todo lo demás. El artículo 5.1.c del Reglamento General de Protección de Datos exige que los datos personales sean «adecuados, pertinentes y limitados a lo necesario en relación con los fines para los que son tratados», lo que el propio reglamento llama minimización de datos. Para dar una cita basta con nombre y contacto; la fecha de nacimiento, el DNI o el motivo detallado se piden solo si el servicio de verdad los exige, y no por chat cuando son datos de salud.
6. Un «sí» al resumen
Antes de escribir en la agenda, el asistente repite la cita con todos sus datos y espera una confirmación expresa del cliente. Ese mensaje es la única forma de comprobar los datos que no tienen lista cerrada.
El resumen se escribe con fecha absoluta, no con la palabra que usó el cliente: «Te reservo manicura semipermanente, 45 minutos, con Laura, en el centro de la calle Mayor, el jueves 19 de noviembre a las 17:00. ¿Lo confirmo?». Si el cliente quería el jueves de la semana siguiente, lo dice aquí y no en la puerta. Un «vale» a una pregunta anterior no cuenta como confirmación de la cita.
Lo que pone el sistema, no el cliente
Hay datos de la cita que el asistente no debe pedir ni inventar, porque los decide la agenda. Son la duración (sale del servicio), si el hueco está libre (sale de la disponibilidad real), el estado de la cita y el identificador que la une a la ficha del cliente y a la conversación.
Google Calendar, por ejemplo, distingue tres estados de un evento en la misma referencia: confirmado, provisional y cancelado. Que la cita nazca confirmada o como solicitud que revisa el negocio es una decisión de configuración, no algo que el modelo resuelva en cada conversación. Qué pasa cuando dos citas chocan, o cuando el cliente quiere moverla o anularla, son preguntas aparte que tratamos en otras piezas del calendario.
Cómo se comprueba antes de salir
La prueba no mira la frase del asistente, sino la agenda: después de cada reserva, alguien abre la cita y compara los seis datos con lo que pidió el cliente. Es la familia de la agenda de la batería que contamos en qué preguntas debería poder responder un asistente de IA antes de salir en producción.
Para estos datos, los casos que no pueden faltar son:
- Un servicio pedido con otras palabras y uno que el negocio no ofrece.
- «Con la de siempre», con y sin historial del cliente.
- Una petición sin sede en un negocio con dos.
- «Mañana» escrito pasada la medianoche y «el jueves» escrito un jueves.
- Una reserva para otra persona.
- Un cliente que cambia la hora después del resumen.
Ejemplo: el centro de estética con dos locales
El ejemplo es ilustrativo, no un cliente real. Un centro de estética tiene un local en el centro y otro en un barrio, cuatro profesionales y veinte servicios con duraciones de 15 a 90 minutos. Una clienta escribe un miércoles por la noche: «Hola, ¿me cogéis mañana por la tarde con Laura para lo de las uñas?».
El asistente tiene la mitad de los datos y una suposición en cada uno. «Lo de las uñas» pueden ser tres servicios distintos; Laura trabaja los jueves en el local del barrio y no en el del centro; «mañana» es jueves 19 si son las 22:00 y viernes 20 si ya han pasado las doce. Bien resuelto, el asistente pregunta solo lo que no puede deducir con seguridad (qué servicio de uñas), propone dos huecos reales de Laura en el local del barrio y cierra con el resumen completo. Mal resuelto, reserva una manicura de 30 minutos en el centro, y la clienta llega a un local donde Laura no está.
Cómo lo planteamos en PotencIA
Separado de lo anterior, porque aquí somos parte interesada: PotencIA diseña y pone en marcha asistentes de IA para la atención y las reservas de negocios.
Los servicios, sus duraciones y quién hace cada uno se cargan en la puesta en marcha, y antes de proponer un hueco la disponibilidad cruza el horario del negocio con las citas ya dadas y, si está conectado, con el calendario de Google. La cita queda unida a la ficha del cliente y a la conversación de la que nace. En el agente de voz para reservas aplicamos la regla del resumen: registra la petición cuando el cliente confirma el resumen, y en el modo con el que arrancamos el restaurante la confirma, la rechaza u ofrece otra hora. No prometemos que el asistente no se equivoque nunca; los seis datos sirven para que, cuando se equivoque, se vea antes de que llegue el cliente.
Si tu negocio vive de la agenda, lo vemos aplicado a tu caso en nuestras soluciones de IA a medida, y para centros con muchos servicios y profesionales, en el asistente de IA para centros de estética.
Cómo se ha verificado esto
Fuentes consultadas el 11 de noviembre de 2026:
- Anthropic, documentación en español sobre el uso estricto de herramientas y sobre cómo definir herramientas.
- Google for Developers, referencia del recurso de eventos de la API de Google Calendar, actualizada el 7 de julio de 2026.
- Real Decreto 236/2002, de 1 de marzo, por el que se establece la hora de verano, artículos 2 y 3, en el BOE.
- Reglamento (UE) 2016/679, General de Protección de Datos, artículo 5.1.c, en la copia del Diario Oficial de la Unión Europea publicada en el BOE.
Las fechas del cambio de hora de 2027 son un cálculo propio a partir de la regla del Real Decreto. La lista de seis datos, los casos de prueba y el ejemplo del centro de estética son criterio propio de PotencIA, no requisitos de ninguna de esas fuentes. Este artículo es información general, no asesoramiento jurídico.