Una respuesta segura no significa que la reserva se haya hecho
Un bot puede decir «reservado, le esperamos el jueves a las 3 de la tarde» con total seguridad mientras la cita no llega a ninguna parte: la estilista nunca recibió el aviso, el hueco no se bloqueó en el calendario o el mensaje fue a un chat de pruebas en lugar del real. El texto de la respuesta solo demuestra que el bot sabe encadenar palabras, no que haya pasado algo de verdad al otro lado. Lo que hay que comprobar es el resultado, no la conversación: si la reserva aparece donde la estilista la va a ver.
Cinco escenarios que conviene recorrer usted mismo
Probar solo el camino perfecto, elegir una hora, confirmar, recibir respuesta, no basta. Como mínimo, recorra cinco escenarios como lo harían distintos clientes reales:
- Camino ideal: hay un hueco libre, el cliente lo elige y confirma.
- Hueco ocupado: el cliente intenta elegir una hora ya reservada; el bot debe ofrecer una alternativa, no quedarse bloqueado.
- Cancelar y cambiar: el cliente cancela o mueve una reserva existente; el hueco debe liberarse o cambiar en el calendario, no quedar duplicado.
- Datos incompletos: el cliente escribe un nombre sin teléfono o abandona la conversación a medias; el bot no debe crear una reserva con un hueco.
- Pantalla de móvil: la misma conversación en una pantalla pequeña; los botones y el texto no deben cortarse ni solaparse.
Compruebe el destino, no la conversación
Tras cada prueba, mire dónde debía acabar realmente la reserva: el calendario de la estilista, una hoja de cálculo o el chat donde se avisa al personal. ¿Coinciden la hora, el nombre y el teléfono de ese registro con lo que escribió el cliente de prueba? Si el bot avisa a la estilista, confirme que el aviso llegó de verdad, no solo que el flujo debía enviarlo.
Lleve una lista de discrepancias en lugar de parchear sobre la marcha
Cada discrepancia encontrada merece anotarse: qué se esperaba, qué ocurrió realmente y, tras corregirla, ese mismo escenario se vuelve a probar. Arreglar las cosas sobre la marcha sin lista casi siempre significa que el mismo fallo reaparece un mes después, porque se arregló algo correctamente, pero no el caso que realmente fallaba.
Pruebe donde estará el cliente, no solo en el panel de desarrollo
Una conversación que se ve bien en el panel de pruebas del bot puede comportarse de otra forma en el canal real: Telegram, WhatsApp o un widget de la web donde está integrado el bot. La comprobación final debe hacerse en el canal y el dispositivo reales que usaría un cliente, no solo en un entorno de desarrollo.
Errores comunes, en breve
- Solo se prueba el camino perfecto, sin hueco ocupado ni cancelación.
- El aviso a la estilista se comprueba contra la lógica del flujo, no contra la entrega real.
- Se prueba en el panel de desarrollo en lugar de en un chat real en un móvil.
- Se corrige un fallo pero nunca se vuelve a probar el mismo escenario para confirmarlo.
Lista previa al lanzamiento
- [ ] Se han probado el camino ideal, el hueco ocupado, cancelar o cambiar, los datos incompletos y la pantalla de móvil
- [ ] Cada reserva de prueba aparece en el calendario real o en la hoja de cálculo del personal
- [ ] Los avisos a la estilista están confirmados por entrega real, no solo por la lógica del flujo
- [ ] Se llevó una lista de discrepancias y se cerró con una nueva prueba, no solo con una corrección
- [ ] La prueba final se hizo en el canal y el dispositivo reales del cliente
Qué puede encargarnos
Comprobar y corregir el bot forma parte del plan de soporte del estudio, desde $150 al mes. También puede consultarnos cómo probar su propio bot de reservas.
