Saltar al contenido principal

Torus Academy

Construcción completa del proyecto final

Datos de esta lección
FaseF6 — Proyecto completo
MóduloM6.1 — Simulación de cliente
Puntos de profesionalidad al superar el test150

Objetivo práctico

Al terminar esta lección tendrás el sistema completo de Fontanería Ejemplo construido de extremo a extremo: un número de teléfono real conectado a un agente de Vapi o de Retell, con el Prompt Maestro adaptado al pliego del cliente, una voz de ElevenLabs configurada, dos herramientas de Tool Calling (reservar_cita y cancelar_cita/modificar_cita) conectadas a un workflow de n8n o a un escenario de Make que gestiona Google Calendar o Cal.com, límites de gasto revisados, y una transferencia de contingencia funcional.

Resultado que obtendrás

Un proyecto real y funcional, probado con al menos una llamada completa de reserva y una de cancelación o modificación, que integra en un único sistema todo lo construido por separado en las Fases 1 a 4 de este curso.

Dónde encaja dentro del sistema final

Esta es la lección de integración final: convierte en un único sistema coherente todas las piezas trabajadas por separado (Teléfono → Agente → Cerebro → Voz → Automatización → Calendario), aplicadas exactamente al pliego analizado en la lección anterior.

Conocimientos previos

Herramientas necesarias

Posible coste

Esta lección no introduce ningún concepto de coste nuevo respecto a lo ya explicado en el módulo 2.1: cada llamada de prueba completa que realices consume minutos de telefonía, tokens de LLM, segundos de transcripción y caracteres de voz, tal y como se desglosó en «Cómo se calcula el coste real de una llamada». Como esta lección implica varias llamadas de prueba de extremo a extremo (reserva, cancelación, urgencia, transferencia), limita el número de llamadas completas mientras depuras cada pieza por separado, y resérvalas para el final de cada bloque del procedimiento.

Advertencia de seguridad

Antes de empezar, revisa la checklist de seguridad económica del módulo 2.1 sobre las cuentas reales que vas a usar en este proyecto (Twilio, ElevenLabs, Vapi o Retell): confirma que tienes aplicada la protección real disponible en cada una (saldo prepago sin recarga automática en Twilio, límite de créditos de tu plan en ElevenLabs) y medidas externas donde no exista un límite vinculante nativo, antes de dejar el número conectado y activo.

Modelo mental

Piensa en esta lección como en el día en que, tras haber construido y probado por separado cada mueble de la oficina (la centralita, el cerebro, la voz, el mensajero, la agenda), los colocas todos juntos en la misma sala y contratas al primer cliente real (aunque ficticio) para comprobar que la oficina completa funciona como un sistema único, no como piezas sueltas.

Explicación

Esta lección no introduce herramientas nuevas: aplica, sobre el pliego de Fontanería Ejemplo, exactamente las piezas ya construidas y probadas en las Fases 2, 3 y 4. La dificultad no está en aprender algo nuevo, sino en integrarlo todo con disciplina, siguiendo el principio de diagnóstico por descarte también durante la construcción, no sólo durante el diagnóstico de fallos: construye y prueba una pieza cada vez, en el orden TELÉFONO → CEREBRO → VOZ → AUTOMATIZACIÓN → CALENDARIO, y no añadas la siguiente pieza hasta haber confirmado que la anterior funciona de forma aislada. Añadir todas las piezas a la vez y probar sólo al final es la forma más lenta de encontrar un fallo, porque no sabrás en cuál de las cinco piezas se originó.

Elección entre Vapi y Retell. Este curso no impone una plataforma: ambas están documentadas con la misma profundidad (módulo 2.3) y ambas admiten el Prompt Maestro completo en un único campo de prompt del sistema (el modo «Single prompt» en Retell). Un criterio razonable para decidir es recordar con cuál de las dos te sentiste más cómodo durante la Fase 3: si prefieres el formato de respuesta más flexible de las Custom Functions de Retell (basta un código 200-299 y un cuerpo con el resultado), elige Retell + Make; si prefieres reutilizar exactamente el flujo de Tools y Server URL ya practicado con Vapi, elige Vapi + n8n. Cualquiera de las dos combinaciones, bien construida, es igual de válida para entregar a un cliente real.

El Prompt Maestro adaptado. El recurso «Prompt Maestro adaptado — Fontanería Ejemplo» (descargable desde Recursos) sustituye cada corchete del Prompt Maestro genérico del módulo 1.3 por los datos reales del pliego: horarios, servicios y precios ficticios, zonas de cobertura, criterios de urgencia, preguntas frecuentes, restricciones explícitas, reglas de transferencia, política de cancelación y confirmaciones de cita. Pégalo completo en el campo de prompt del sistema de tu asistente, exactamente como practicaste en el módulo 2.3, sin reescribirlo desde cero.

Por qué hacen falta dos herramientas de Tool Calling. El módulo 3.4 construyó una única herramienta, reservar_cita, que crea un evento nuevo en el calendario. El apartado 10 del pliego de Fontanería Ejemplo exige algo que reservar_cita no puede hacer: permitir que un cliente cancele o modifique una cita ya existente hasta 2 horas antes, previa confirmación de su nombre y la fecha exacta de la cita. Crear un evento nuevo y localizar/cambiar un evento ya existente son dos operaciones distintas sobre el calendario (creación frente a búsqueda y edición), así que este proyecto necesita una segunda herramienta, cancelar_cita (que también puede gestionar modificaciones si se le añade un parámetro accion), con su propio esquema de parámetros: nombre, telefono, fecha_hora_cita (la cita que se busca) y, si es una modificación, nueva_fecha_hora. El workflow asociado a esta segunda herramienta debe, primero, localizar el evento real en el calendario que coincida con esos datos —usando el nodo de búsqueda de eventos de Google Calendar o Cal.com, localizado por nombre en el buscador de aplicaciones exactamente como en el módulo 3.3— y sólo entonces eliminarlo o actualizarlo, devolviendo una confirmación (o un mensaje de «no encontrado» si los datos no coinciden con ninguna cita real, para que el agente no confirme nunca una cancelación que no se ha producido realmente).

Urgencias frente a citas normales. El apartado 9 del pliego distingue explícitamente entre una cita no urgente (que respeta un buffer de 30 minutos entre citas, ya configurable en Google Calendar y en Cal.com según lo visto en el módulo 3.2) y una urgencia (que se registra como un evento inmediato, con la etiqueta «URGENCIA» en el título del evento, sin ocupar un hueco de agenda futura). La herramienta reservar_cita debe aceptar un parámetro adicional, por ejemplo es_urgencia, que el workflow de n8n o de Make use para decidir si crea el evento con el buffer estándar o como evento inmediato etiquetado.

Límites de gasto y logs. Antes de dejar el número de teléfono conectado de forma continuada, repite la checklist del módulo 2.1 sobre las cuentas reales de este proyecto. Si algo falla durante las pruebas, aplica el mismo método TELEFONÍA → CEREBRO → VOZ → AUTOMATIZACIÓN → CALENDARIO del módulo 4.1: revisa primero el log de Twilio, después el de tu asistente de Vapi o tu agente de Retell, después (si procede) la ejecución de tu workflow de n8n o tu escenario de Make, y por último el calendario, en ese orden, sin abrir las cinco a la vez.

Plan de contingencia. Toda la lógica de transferencia del módulo 4.2 se aplica aquí con las condiciones concretas del pliego: transferir de inmediato ante una petición explícita de hablar con una persona, ante un olor a gas o una inundación activa, o si la conversación se repite dos veces sin avance. Configura también el fallback: qué debe decir el agente si la transferencia misma falla técnicamente (número ocupado o sin respuesta), en lugar de dejar la llamada sin ninguna salida.

Vocabulario nuevo

Herramienta de búsqueda y edición de cita

Piénsalo así: La diferencia entre abrir un expediente nuevo y localizar uno ya existente en el archivador para modificarlo.

Herramienta de Tool Calling (cancelar_cita/modificar_cita) que, a diferencia de reservar_cita, primero localiza un evento ya existente en el calendario según los datos proporcionados, y sólo entonces lo elimina o lo actualiza.

Ejemplo: La herramienta cancelar_cita de Fontanería Ejemplo busca, en Google Calendar, un evento que coincida con el nombre y la fecha indicados por quien llama, antes de eliminarlo.

Evento inmediato etiquetado

Piénsalo así: Una nota urgente que se coloca directamente sobre la mesa del técnico, en lugar de archivarse en la agenda semanal.

Evento de calendario creado para una urgencia, sin respetar el buffer de citas normales, identificado con una etiqueta clara (por ejemplo, «URGENCIA») en el título.

Ejemplo: Una fuga activa con riesgo de inundación genera un evento titulado «URGENCIA — Fuga activa, C/ Ejemplo 12» creado de inmediato en el calendario.

Preparación

Ten descargados y a mano: el pliego del cliente (módulo 6.1) y el Prompt Maestro adaptado a Fontanería Ejemplo (Recursos). Ten abiertas las cuentas de Vapi o Retell, ElevenLabs, Twilio, n8n o Make, y Google Calendar o Cal.com, todas ya creadas en fases anteriores del curso.

Procedimiento paso a paso

  1. Contexto: Vas a decidir la combinación de plataformas para este proyecto antes de tocar ninguna configuración.

    Acción de teclado: Abre el documento de notas comparativas que fuiste anotando durante los módulos 2.3 y 3.4 (o, si no lo tienes, recupera con NVDA tus quiz superados de esas lecciones para recordar tu impresión de cada plataforma).

    Respuesta esperada de NVDA: NVDA leerá tus propias notas conforme las recorras con las flechas.

    Qué significa: No existe una combinación obligatoria: Vapi + n8n y Retell + Make están documentadas con la misma profundidad en este curso.

    Acción siguiente: Anota tu decisión (por ejemplo «Vapi + n8n») al principio de tu documento de proyecto, porque el resto del procedimiento depende de esta elección.

  2. Contexto: Vas a crear el asistente o agente base con el Prompt Maestro adaptado, repitiendo el ensamblaje ya practicado.

    Acción de teclado: Repite el procedimiento completo de la lección Ensamblaje del agente en Vapi o de Ensamblaje del agente en Retell AI, según tu elección, pero pegando en el campo de prompt del sistema el contenido íntegro del recurso «Prompt Maestro adaptado — Fontanería Ejemplo» en lugar del Prompt Maestro genérico.

    Respuesta esperada de NVDA: NVDA anunciará los mismos campos y selectores ya descritos en esas lecciones.

    Qué significa: Esto es exactamente el mismo procedimiento técnico que ya dominas, con datos de negocio reales en lugar de corchetes genéricos.

    Acción siguiente: Realiza una llamada de prueba por voz desde el navegador y comprueba que el asistente se presenta como el recepcionista de Fontanería Ejemplo, sin avanzar todavía a la siguiente pieza.

  3. Contexto: Vas a conectar el número de Twilio antes de añadir Tool Calling, siguiendo el orden TELÉFONO → CEREBRO → VOZ del diagnóstico por descarte.

    Acción de teclado: Repite el procedimiento de Configuración de un número con Twilio y de Conexión de Twilio con Vapi y con Retell, asociando tu número de pruebas al asistente que acabas de configurar.

    Respuesta esperada de NVDA: NVDA anunciará los mismos formularios ya descritos en esas lecciones.

    Qué significa: Con este paso completo, ya tienes la primera pieza de la cadena TELÉFONO → CEREBRO → VOZ funcionando de extremo a extremo, sin Tool Calling todavía.

    Acción siguiente: Llama de verdad a tu número de pruebas y confirma que la conversación funciona con normalidad antes de continuar; si algo falla aquí, no avances hasta resolverlo.

  4. Contexto: Vas a crear la primera herramienta, reservar_cita, adaptada a las citas normales y a las urgencias del pliego.

    Acción de teclado: Repite el procedimiento de Caso completo: Vapi + n8n reservando una cita o de Caso completo: Retell + Make reservando una cita, según tu elección, añadiendo al esquema de parámetros un campo adicional es_urgencia (verdadero/falso).

    Respuesta esperada de NVDA: NVDA anunciará el mismo formulario de creación de herramienta ya practicado, con el campo nuevo al final del esquema de parámetros.

    Qué significa: El agente ahora puede distinguir, en los datos que envía a la automatización, si la cita es una urgencia o no.

    Acción siguiente: En tu workflow de n8n o escenario de Make, añade una condición (nodo IF o Router) que, según es_urgencia, cree el evento con el buffer de 30 minutos habitual o como evento inmediato con «URGENCIA» en el título.

  5. Contexto: Vas a crear la segunda herramienta, cancelar_cita, que el pliego exige para su política de cancelación.

    Acción de teclado: En la sección de herramientas de tu plataforma (Tools en Vapi, Functions en Retell), crea una nueva herramienta llamada cancelar_cita, con una descripción clara («Cancela o modifica una cita ya existente cuando el cliente confirme su nombre y la fecha exacta de la cita») y un esquema de parámetros con nombre, telefono, fecha_hora_cita, accion (cancelar o modificar) y nueva_fecha_hora (opcional, sólo si accion es modificar).

    Respuesta esperada de NVDA: NVDA anunciará el mismo tipo de formulario ya usado para reservar_cita.

    Qué significa: Esta herramienta apunta a un Webhook distinto (una nueva rama de tu workflow de n8n, o un nuevo escenario de Make) que primero busca el evento y sólo después lo modifica.

    Acción siguiente: Construye esa rama: un nodo de búsqueda de eventos de Google Calendar o Cal.com (localízalo por nombre en el buscador de aplicaciones, como en el módulo 3.3), seguido de un nodo de eliminación o de actualización según el valor de accion, y un nodo final que devuelva una confirmación o un mensaje de «no encontrado».

  6. Contexto: Vas a asociar ambas herramientas al agente y a reforzar en el prompt cuándo debe usar cada una.

    Acción de teclado: Añade ambas herramientas (reservar_cita y cancelar_cita) a tu asistente o agente, y revisa que tu Prompt Maestro adaptado ya incluya, en el bloque «Cancelación y modificación de citas», la instrucción explícita de confirmar nombre y fecha antes de invocar cancelar_cita.

    Respuesta esperada de NVDA: NVDA leerá la lista de herramientas asociadas al confirmar la asociación.

    Qué significa: Sin esta instrucción explícita en el prompt, el LLM podría no activar la herramienta correcta, exactamente como se explicó en el módulo 3.4.

    Acción siguiente: Realiza una llamada de prueba pidiendo una cita nueva, y después otra llamada pidiendo cancelar esa misma cita, confirmando en ambos casos que el evento aparece y desaparece realmente en tu calendario.

  7. Contexto: Vas a revisar los límites de gasto de las cuentas reales de este proyecto antes de dejarlo conectado de forma continuada.

    Acción de teclado: Repite la checklist de la lección Límites de gasto: qué existe realmente en cada plataforma sobre tus cuentas de Twilio, ElevenLabs, Vapi o Retell de este proyecto concreto.

    Respuesta esperada de NVDA: NVDA anunciará las opciones de facturación de cada plataforma conforme las revises.

    Qué significa: Confirmas que el proyecto tiene, para cada plataforma, o bien un límite vinculante nativo, o bien una medida externa aplicada.

    Acción siguiente: Documenta, en tu carpeta de proyecto (módulo 1.1), qué medida de seguridad económica tiene activa cada cuenta de este proyecto concreto.

  8. Contexto: Vas a configurar la transferencia de contingencia con las condiciones exactas del pliego.

    Acción de teclado: Repite el procedimiento de Transferencias de llamada y contingencias, introduciendo como destino el número de guardia del pliego (o tu propio teléfono de pruebas) y confirmando que el prompt adaptado ya incluye las tres condiciones de activación: petición explícita, riesgo de seguridad (gas o inundación activa), y conversación repetida sin avance.

    Respuesta esperada de NVDA: NVDA anunciará el mismo formulario de transferencia ya practicado en el módulo 4.2.

    Qué significa: Esta es la última pieza de seguridad del sistema: qué ocurre cuando el agente decide, correctamente, que no debe seguir gestionando la llamada él solo.

    Acción siguiente: Prueba la transferencia con una llamada real pidiendo hablar con una persona, y comprueba también qué dice el agente si no respondes esa llamada de prueba (tu fallback).

  9. Contexto: Vas a hacer la prueba final de extremo a extremo con el sistema completo ya integrado.

    Acción de teclado: Realiza al menos tres llamadas de prueba distintas al número real: una reservando una cita no urgente, otra simulando una urgencia (fuga activa con riesgo de inundación) y otra cancelando la cita reservada en la primera llamada.

    Respuesta esperada de NVDA: No aplica una única respuesta; escucha con atención cada respuesta del agente y confirma los resultados en tu calendario real.

    Qué significa: Si las tres llamadas se comportan según las reglas del pliego, tienes el proyecto completo funcionando de extremo a extremo.

    Acción siguiente: Si detectas cualquier fallo, aplica el método TELEFONÍA → CEREBRO → VOZ → AUTOMATIZACIÓN → CALENDARIO del módulo 4.1 antes de repetir la llamada.

Posibles diferencias de interfaz

Todos los nombres exactos de botones y campos ya se explicaron con su margen de variación en las lecciones originales de cada pieza (módulos 2.3, 2.4, 3.2, 3.3, 3.4 y 4.2). Esta lección no introduce interfaces nuevas: aplica las mismas de siempre sobre datos de negocio reales.

Errores frecuentes y diagnóstico

El agente conversa con normalidad y confirma verbalmente una cita, pero el evento nunca aparece en el calendario.

Cómo localizarlo: Aplicando el diagnóstico por descarte del módulo 3.4: si la conversación (TELÉFONO → CEREBRO → VOZ) ya funciona, el problema está en la automatización o en el calendario, no en el agente.

Solución: Revisa la ejecución de tu workflow de n8n o escenario de Make, confirmando que la herramienta reservar_cita se activó y que el formato de respuesta es el que exige tu plataforma (results/toolCallId en Vapi, código 200-299 en Retell).

La herramienta cancelar_cita responde siempre «no encontrado», aunque la cita exista realmente.

Cómo localizarlo: El nodo de búsqueda de eventos puede estar comparando el nombre o la fecha con un formato distinto al que envía el agente (por ejemplo, mayúsculas frente a minúsculas, o un formato de fecha distinto).

Solución: Inspecciona los datos reales de entrada de una ejecución de prueba, igual que en el módulo 3.4, y ajusta el criterio de búsqueda del nodo hasta que coincida exactamente con el formato real recibido.

Una urgencia se agenda como una cita normal, ocupando un hueco de la agenda y esperando al buffer de 30 minutos.

Cómo localizarlo: El parámetro es_urgencia no se está enviando, o la condición del workflow que distingue ambos casos no está bien configurada.

Solución: Revisa el esquema de parámetros de reservar_cita y la condición (nodo IF o Router) del workflow, confirmando que ambos caminos crean eventos con la configuración correcta según el pliego.

Tras varias horas de pruebas, el gasto acumulado en alguna de las cuentas es mayor de lo esperado.

Cómo localizarlo: Puede que no se haya aplicado ninguna medida de seguridad económica externa en una plataforma sin límite vinculante nativo, tal y como se advirtió en el módulo 2.1.

Solución: Revisa de nuevo la checklist de seguridad económica y aplica saldo mínimo, tarjeta virtual o alertas bancarias en las cuentas donde todavía no lo hayas hecho.

Comprobación final

Realiza, en una sola sesión, las tres llamadas de prueba del último paso del procedimiento (reserva no urgente, urgencia real y cancelación), y confirma que cada una produce el resultado correcto: la cita no urgente aparece en el calendario con el buffer adecuado, la urgencia genera un evento inmediato etiquetado «URGENCIA», y la cancelación elimina realmente el evento correspondiente tras confirmar nombre y fecha. Si las tres comprobaciones son positivas, el proyecto está completo.

Qué acabas de conseguir

Tienes un sistema de agente telefónico de IA completo, funcional y probado de extremo a extremo, construido exactamente sobre los requisitos reales de un pliego de cliente: la culminación técnica de todo el curso, lista para pasar por el protocolo final de pruebas de estrés de la siguiente lección.

Ejercicio práctico

Documenta, en tu carpeta de proyecto, un diagrama textual simple (una lista ordenada) de las seis piezas de tu sistema completo (Teléfono, Agente, Cerebro, Voz, Automatización, Calendario) indicando, para cada una, la plataforma concreta elegida y el nombre exacto del recurso (número de Twilio, nombre del asistente, nombre de la voz, nombre del workflow o escenario, nombre del calendario). Este documento es la base de la documentación de entrega a un cliente real.

Resumen de lo imprescindible

No necesitas aprender todavía

Todavía no necesitas ejecutar la batería completa de pruebas de estrés ni diseñar tu plan comercial de 30 días: son el contenido de las dos lecciones siguientes.

Estoy preparado para continuar si puedo…

Fuentes

Última actualización de esta lección: 2026-08-30.

Test de la lección

Para realizar el test y obtener Puntos de profesionalidad necesitas iniciar sesión o crear una cuenta.

Navegación

Lección anterior: El pliego del cliente: fontanería con urgencias 24 horas

Continuar con la siguiente lección: Protocolo final de pruebas de estrés

Descargar esta lección en PDF accesible