Plan de implantación de IA de voz en 90 días para equipos empresariales

Qué debe dejar el plan de 90 días

En una empresa de 50 a 100 personas, la primera versión de IA de voz debe demostrar un resultado operativo, no cubrir todas las colas. Elija un proceso con volumen suficiente para aprender, políticas claras y una alternativa humana razonable: cambios de cita, estado de pedidos, cualificación u otra petición acotada. El día 90 debería haber un proceso en producción, una línea base, un alcance aprobado, integraciones probadas, un traspaso medible y un responsable que rinda cuentas.

Nombre cuatro responsables desde el principio: un patrocinador ejecutivo para prioridades y riesgos, un responsable de operaciones para el proceso, un responsable de sistemas para el acceso a telefonía y CRM, y un revisor de calidad o cumplimiento para la aceptación y la trazabilidad. El responsable de operaciones sigue respondiendo del resultado diario. Un jefe de proyecto puede coordinar el trabajo, pero no debe convertirse en el responsable de repuesto cuando el agente genera una excepción.

Use estos hitos como un contrato de trabajo. Las fechas son ventanas de planificación, no un motivo para dar por superado un punto de control inacabado. Si un sistema de origen, una decisión de política o una ruta humana no están listos, detenga la fase siguiente y deje constancia de la dependencia.

Primero, los límites

Deje por escrito qué puede responder, consultar y modificar el agente, y qué no decide nunca. Incluya horario de atención, idiomas, verificación de identidad, reglas de reintento, consentimiento de grabación, temas sensibles y el momento en que una persona toma el relevo. Un límite solo sirve si el equipo sabe reconocerlo en una llamada real. Añada ejemplos de peticiones permitidas y prohibidas, la fuente de referencia de cada respuesta y el estado exacto que demuestra que una acción se ha completado.

Monte un dossier de evidencias

Mantenga un único dossier versionado para el proceso: declaración de alcance, diagrama del flujo de llamada, fuentes de las políticas, campos de datos, mapa de responsables, diccionario de métricas, casos de prueba, aprobaciones, registro de incidencias e historial de versiones. Vincule cada requisito importante a una prueba o a un registro de revisión. Así el equipo tiene algo más sólido que la grabación de una demo, y la decisión del día 90 se puede explicar a un nuevo operador, revisor o responsable de sistemas.

Días 1 a 15: el mapa de la conversación

Empiece por las grabaciones, las transcripciones, las tipificaciones, los motivos de rellamada, las notas de los supervisores, el conocimiento aprobado y los campos del CRM que usan los agentes. Tome muestras de llamadas rutinarias y de excepciones en la cola elegida, en distintas franjas, idiomas y tipos de interlocutor. Escuche cómo habla quien llama, no solo las etiquetas de los informes: una intención puede llegar como varias peticiones, y una frase puede esconder una petición que corresponde a otro responsable.

Dibuje el recorrido desde el saludo hasta el resultado. Marque la autenticación, las consultas, las acciones que generan compromisos y las transferencias. Para cada rama, anote el resultado esperado, la evidencia que lo respalda y la persona o cola responsable del siguiente paso. Registre la línea base de resolución, tasa de transferencia, tiempo en cola, rellamadas, acciones completadas y la revisión de calidad actual. Sin línea base y sin denominador, una mejora posterior no pasa de ser una buena impresión.

De las observaciones a una muestra útil

Mantenga una pequeña biblioteca de llamadas con ejemplos habituales, difíciles y dudosos. Etiquete la intención real de quien llama, la política aplicable, la tipificación correcta, el estado esperado en el sistema y si debería intervenir una persona. Elimine o proteja los datos sensibles según las normas de tratamiento aprobadas por el equipo. No se trata de crear un conjunto de datos perfecto, sino de hacer visibles, y por tanto comprobables, las decisiones que se repiten en el proceso.

Responsable: operaciones, con un supervisor y un revisor de calidad. Entregables: mapa de intenciones, flujo de llamada, inventario de datos, línea base, biblioteca de llamadas y lista de lo que queda fuera de alcance. Criterio de salida: el equipo puede explicar el proceso en una frase, señalar la fuente de referencia de cada respuesta y nombrar al responsable de cada excepción.

Días 16 a 30: de la política al proceso

Convierta el mapa en un contrato de proceso: apertura, identificación de quien llama, confirmación de la intención, consulta de conocimiento, acción, confirmación, resumen y siguiente paso. Constrúyalo sobre frases e interrupciones reales, no sobre un guion perfecto. Incluya silencios, acentos, correcciones, momentos de «esto ya se lo he explicado», peticiones que cambian, varias peticiones en una misma llamada e interlocutores que piden hablar con una persona desde el primer momento.

Para cada acción de herramienta, especifique la entrada, el permiso, la respuesta de éxito, el tiempo máximo de espera y la ruta de fallo. Indique si la acción es de solo lectura, reversible o un compromiso que requiere confirmación. Mantenga reducido el primer conjunto de integraciones: una ruta de telefonía, un registro de CRM o helpdesk y el mínimo de conocimiento aprobado. DRING admite procesos de voz integrados que convierten una conversación en un resultado estructurado, pero es el negocio quien decide qué resultado es el de referencia.

Un control de preparación para cada integración

Antes de poner una herramienta a disposición del agente, compruebe cuatro cosas: la fuente de verdad tiene nombre, el permiso es el mínimo necesario para el proceso, la respuesta se puede validar y el fallo es visible para una persona. Confirme el mapeo de campos, los identificadores obligatorios, el comportamiento ante duplicados, los tiempos máximos de espera, los eventos de auditoría y quién se encarga de conciliar. Empiece con acceso de lectura siempre que pueda. Añada la escritura solo cuando una prueba demuestre que un reintento no puede crear una segunda reserva, una segunda incidencia o un segundo compromiso.

El traspaso, una ruta de primera categoría

Defina qué provoca el traspaso en directo: duda persistente tras pedir aclaración, una petición sensible, una acción de sistema fallida, un interlocutor que pide una persona o una decisión fuera de política. El agente debe explicar el siguiente paso, pasar a la persona un resumen breve con los identificadores y conservar el caso si la cola no está disponible. Acuerden la alternativa: tarea de llamada de vuelta, incidencia, confirmación por SMS o cierre documentado.

Redacte el contenido del traspaso como un contrato operativo. Debe distinguir lo que dice quien llama de lo que devuelve el sistema, e incluir el estado de la verificación de identidad, la intención, las acciones intentadas, los identificadores de registro pertinentes, la urgencia, el idioma, el estado del consentimiento o de la baja, el motivo del traspaso y el siguiente responsable. Defina qué cuenta como transferencia correcta, cuánto puede esperar quien llama y qué ocurre cuando nadie acepta el traspaso. Una transferencia que pierde el contexto o deja una tarea sin dueño no es un proceso terminado.

Días 31 a 45: conectar la ruta real

Configure el número, la ruta SIP o de centralita virtual, el identificador de llamada, el horario de atención, el buzón de voz, las reglas de cola y la alternativa de continuidad del servicio. Pruebe la ruta telefónica completa, desde la entrada hasta la transferencia, incluidos enrutamientos erróneos, colas saturadas, llamadas cortadas, identificadores que no coinciden, el comportamiento fuera de horario y la falta de una persona disponible. Una conversación impecable sigue fallando si el enrutamiento está mal o si la transferencia pierde el contexto.

Conecte el CRM o el helpdesk. Empiece con acceso de lectura y añada escrituras solo cuando estén claros el campo, el permiso, la validación y el registro de auditoría. Decida cómo se identifica a quien llama, cómo se tratan los duplicados y cómo se evita que un reintento cree dos incidencias o dos reservas. Registre el resultado, la siguiente acción, el motivo del fallo, el estado de origen y el responsable allí donde ya trabaja el equipo de operaciones. Pruebe tanto una escritura correcta como un fallo parcial, por ejemplo una acción completada a la que le falta el resumen.

Preparar a las personas que rodean la línea

La gestión del cambio empieza antes de la primera llamada del piloto. Explique a agentes y supervisores qué trabajo se traslada, qué decisiones siguen en manos de personas, cómo se corrige un registro erróneo y dónde se comunica un fallo sin buscar culpables. Entregue al equipo receptor ejemplos de resúmenes de traspaso y una breve cola de práctica. Pida a los agentes con experiencia frases y casos límite, y muestre después cómo sus comentarios se convierten en una prueba o en una decisión de política documentada. Así la adopción forma parte de la preparación y no es un anuncio posterior al lanzamiento.

Responsable: sistemas, con validación de operaciones, supervisión y calidad. Entregables: ruta conectada, permisos, mapeo de eventos, ensayo del traspaso, información al personal y procedimiento de recuperación. Criterio de salida: una llamada de prueba genera el evento de telefonía, el estado del CRM, el resumen y el registro de traspaso esperados sin reparaciones manuales, y una persona con nombre puede pausar la ruta.

Días 46 a 60: probar comportamiento y resultados

Cree una batería de pruebas con conversaciones habituales, difíciles y hostiles. Separe los bloques de llamadas rutinarias, casos límite, fallos de herramientas, traspasos y peticiones sensibles desde el punto de vista de las políticas. Cubra números equivocados, registros inexistentes, audio con ruido, silencios, interrupciones, conocimiento contradictorio, interlocutores enfadados, texto no fiable en los datos recuperados, APIs que no responden a tiempo, peticiones duplicadas, variaciones de idioma o acento, cambios de intención y cada uno de los desencadenantes de traspaso. Pruebe lo que dice el agente y también el estado en que queda el sistema.

Para cada caso, registre la intención esperada, la respuesta permitida, el aviso o la confirmación obligatorios, la llamada a herramienta esperada, el estado esperado del registro, la decisión de traspaso y la gravedad si falla. Use una batería de regresión pequeña en cada versión y un conjunto de evaluación más amplio para las decisiones de cada hito. Una llamada que suena natural puede escribir el estado equivocado o retrasar el traspaso. El proceso de calidad y evaluación de DRING combina conversaciones simuladas, pruebas de regresión, revisión humana y despliegue por fases. Fije primero los criterios de aprobación y conserve los escenarios fallidos en la batería de regresión.

Puntuar la conversación y el resultado

Puntúe la comprensión de la intención, el cumplimiento de políticas, la tarea completada, la exactitud de los datos, la conservación del contexto, la latencia y la precisión del traspaso. Los revisores deben poder marcar cada caso como aprobado, suspendido o pendiente de revisión, con un motivo. Separe los fallos críticos de los detalles de acabado: una revelación no autorizada, una actualización en el registro equivocado, una confirmación falsa o un traspaso de seguridad que no se produce no deben quedar diluidos en la media de muchas llamadas rutinarias fluidas. Guarde la versión y el resultado de la prueba con cada evaluación.

Acordar cómo se comporta ante los fallos

Para cada tipo de fallo, elija una respuesta: aclarar, reintentar una acción acotada, negarse de forma segura, crear un seguimiento o transferir. El agente no debe adivinar la política, inventarse un registro ni afirmar que una acción ha salido bien cuando no es así. El revisor de calidad aprueba estos límites; el responsable de sistemas confirma que los registros hacen visibles los fallos. Vuelva a ejecutar toda la batería de regresión tras cualquier cambio en prompts, conocimiento, permisos, enrutamiento, telefonía o mapeo de datos, porque corregir una frase puede alterar una decisión de herramienta o de traspaso.

Responsable: calidad. Entregables: batería de pruebas versionada, cuadro de puntuación, clasificación de fallos, resultados de regresión y decisión de preparación firmada. Punto de control del día 60: ningún fallo crítico sin resolver en la ruta dentro de alcance, cada acción de herramienta tiene un resultado de éxito y otro de fallo observados, y el equipo receptor ha ensayado el traspaso y la vuelta atrás.

Días 61 a 75: un piloto acotado

Ponga el proceso en una pequeña porción del tráfico: una cola, una región o una franja horaria. Mantenga disponible la ruta actual y haga que la opción de hablar con una persona sea fácil de encontrar. Explique al equipo receptor el formato del resumen, cómo se toma el relevo, las etiquetas de fallo y quién puede pausar el tráfico. Pida a los supervisores que revisen llamadas a diario y agrupen los problemas por causa raíz, en lugar de reescribir el agente por una frase torpe. Dé al equipo una única cola de excepciones, para que una escritura fallida, una llamada de vuelta olvidada y una duda de política no se pierdan en bandejas distintas.

Siga la resolución, las transferencias adecuadas, las rellamadas, el tiempo en cola, las llamadas abandonadas, el éxito de las acciones de sistema, las excepciones de política, la latencia y la opinión del cliente. Separe los resultados operativos de las preferencias sobre la voz. Revise una muestra de llamadas contenidas, no solo de transferencias: la contención puede ocultar a alguien que se quedó sin solución. Cruce las conversaciones de la muestra con el estado del CRM y pregunte al equipo receptor si el traspaso le permitía actuar. Pause el piloto cuando se incumpla una condición crítica de política, privacidad, enrutamiento o integridad de datos.

Criterios para parar, ampliar y dar marcha atrás

Parar: pause la ruta afectada ante una revelación no autorizada, una actualización en el registro equivocado, un cierre falso, un traspaso crítico que no se produce, la pérdida de un consentimiento obligatorio, escrituras duplicadas repetidas o una excepción de alta prioridad sin responsable. Conserve la ruta anterior y documente la incidencia, las llamadas afectadas, la versión, el responsable y la contención inmediata.

Ampliar: aumente el tráfico solo después de que el responsable de operaciones haya revisado la comparación con la línea base, la muestra de calidad, los resultados en los sistemas, la cola de traspasos y las incidencias abiertas. Las pruebas deben mostrar que el proceso dentro de alcance se comporta dentro de los límites acordados de antemano y que el equipo tiene capacidad para absorber las excepciones. No decida una ampliación mirando solo una media: examine los segmentos donde cambian el trabajo o el riesgo.

Dar marcha atrás: vuelva a la ruta o la versión anterior cuando la causa no se pueda aislar rápido, se rebase un límite de seguridad o el equipo receptor no dé abasto con la cola de excepciones. Compruebe que la ruta antigua sigue funcionando antes de empezar el piloto. La vuelta atrás solo está completa cuando las llamadas nuevas siguen la ruta anterior, las tareas abiertas tienen responsable y el registro de la incidencia recoge la comprobación de recuperación y la decisión de seguimiento.

Días 76 a 90: ampliar con pruebas

Compare los resultados del piloto con la línea base y examine las llamadas que hay detrás de las medias. Busque desviaciones por intención, franja horaria, idioma, tipo de interlocutor y ruta de integración. Su analítica de llamadas debe relacionar transcripción, puntuación, resultado estructurado y estado del CRM, para que el equipo pueda seguir un problema hasta la conversación o el proceso que lo originó. Lleve un registro de decisiones que diga qué cambió, por qué, qué evidencia lo respaldó y qué sigue sin saberse.

Amplíe por fases, por ejemplo al 10 %, al 50 % y al 100 %, con una pausa de revisión tras cada paso. Use el mismo cuadro de puntuación en cada fase para que el denominador no cambie sin que nadie lo note. Defina quién puede ordenar la vuelta atrás y qué la desencadena antes de subir el tráfico. Cada corrección relevante debe producir un caso de prueba, un cambio documentado y un resultado de regresión. Si la siguiente cola necesita otros permisos, políticas, idiomas u horarios de traspaso, trátela como una nueva decisión de alcance en vez de copiar a ciegas el primer proceso.

El día 90, fije un ritmo operativo realista: durante un piloto activo, los supervisores revisan a diario una muestra de llamadas y las excepciones; los responsables de operaciones, calidad y sistemas analizan las tendencias cada semana; el equipo prepara una versión candidata de Agent Factory cada dos semanas cuando hay un cambio validado; y los responsables de políticas, accesos, conservación y alcance revisan el servicio cada mes. Las correcciones urgentes de seguridad o integridad de datos pueden seguir una vía de aprobación rápida, pero siguen necesitando una prueba, un aprobador con nombre, una versión, una ventana de seguimiento y una revisión posterior. El ciclo de mejora continua de Agent Factory convierte la evidencia real en trabajo priorizado y en una versión controlada, no en un cambio de prompt sin explicación.

Aplique esta disciplina al segundo proceso solo cuando el primero tenga un responsable estable, una batería de regresión mantenida, una vuelta atrás conocida y capacidad de revisión suficiente. El objetivo no es que un agente sea permanente, sino que el método del equipo para lanzar y mejorar agentes se pueda repetir.

El cuadro de puntuación, antes del despliegue

Use un diccionario de métricas que indique numerador, denominador, periodo, sistema de origen, exclusiones y responsable. Mantenga separadas las medidas de resultado, servicio, calidad y límites de seguridad. Una única «tasa de automatización» puede ocultar una escritura errónea o a alguien que colgó harto de esperar, mientras que una transferencia puede ser el resultado correcto para una petición fuera de política.

Añada latencia, llamadas cortadas, tasa de respuestas desactualizadas, tasa de tareas duplicadas, acuse de los traspasos y opinión del cliente cuando ayuden a decidir. Desglose los resultados por intención, franja, idioma, tipo de interlocutor, ruta y resultado de la integración. Revise tanto el recuento como el porcentaje cuando cambie el volumen. Un porcentaje estable con una cola de excepciones que no para de crecer puede exigir igualmente una decisión de capacidad o de enrutamiento.

Preguntas que responder antes del despliegue

Antes de aprobar el paso a producción, pregunte: ¿qué resultado medimos y qué fuente lo demuestra? ¿Qué llamadas quedan fuera de alcance? ¿Qué campos del CRM se pueden leer o escribir, y quién responde de la calidad de los datos? ¿Qué exige verificar la identidad o la intervención de una persona? ¿Qué pasa cuando fallan la API, la ruta telefónica, la fuente de conocimiento o la transferencia? ¿Dónde se conservan grabaciones, transcripciones y resúmenes, y quién puede acceder a ellos? ¿Quién puede pausar la automatización, aprobar una versión y comunicar una incidencia? ¿Qué evidencia hace falta antes de añadir tráfico o una acción nueva? ¿Qué rutina del equipo revisará las excepciones, y qué trabajo se le quita o se le añade?

El objetivo es una forma repetible de poner en producción un proceso acotado, aprender de los resultados, proteger la ruta humana y gobernar la siguiente versión. El día 90, el equipo debería saber no solo si el agente es capaz de completar una conversación, sino también quién responde de las excepciones, qué evidencia justifica ampliar y cómo parar o revertir el cambio cuando cambian las condiciones de operación.