Para migrar a CCaaS sin perder llamadas, primero desvía tus números antiguos a números nuevos en la plataforma en la nube y deja la portabilidad para lo último. Todo lo que hagas antes de la portabilidad se puede deshacer con un cambio de configuración. Una portabilidad completada no, y en EE. UU. tarda 2 to 4 weeks una vez que la documentación es correcta. Así que haz un inventario, reconstruye, prueba con números de reserva y realiza una prueba piloto con una cola mientras el sistema antiguo sigue gestionando la mayoría de las llamadas.
La mayoría de los planes pasan por alto la parte de soporte: el helpdesk no se mueve, pero sus conexiones con los teléfonos sí. El compañero de helpdesk con IA de eesel trabaja dentro del helpdesk, así que sigue respondiendo tickets durante la transición.
Para quién es esta guía (y qué necesitas primero)
Esta guía es para responsables de soporte u operaciones que van a trasladar una línea telefónica de atención al cliente de una centralita PBX local o un conjunto de tecnologías de centro de llamadas antiguo a uno en la nube (CCaaS, centro de contacto como servicio): Amazon Connect, Genesys Cloud, Talkdesk, Five9, Zendesk Talk, Aircall, Twilio Flex y otras opciones. Si todavía estás eligiendo una plataforma, mi recopilación de software para centros de llamadas cubre las principales candidatas. Si usas Freshdesk, el Freshdesk Contact Center integrado es otra opción, y Dialpad y las alternativas a Aircall cubren las opciones más ligeras. Este artículo trata sobre el traslado en sí.
Soy ingeniero en eesel y dedico la mayor parte de la semana a las integraciones, lo que significa pasar mucho tiempo trabajando con las API de helpdesk y telefonía de otras empresas. El patrón que veo es constante: la telefonía recibe un plan de proyecto, y las conexiones del sistema telefónico con el helpdesk reciben una línea que dice "integraciones". En esas conexiones es donde una transición falla sin que nadie se dé cuenta.
Si también utilizas un agente de IA, la CLI de eesel ofrece a tus ingenieros una vía de acceso alternativa mediante scripts durante el traslado: un agente de programación con IA como Claude Code puede subir conocimientos aprobados (artículos de ayuda exportados, macros, los nuevos guiones del IVR) y luego hacer preguntas de prueba al agente para comprobar sus respuestas antes de poner nada en producción. Para conectar el propio helpdesk sigue haciendo falta que una persona con acceso de administrador lo apruebe.
Ten esto preparado antes del paso 1:
- Una copia de la factura telefónica o del registro de servicio al cliente (CSR) de cada operador. La documentación de portabilidad tiene que coincidir exactamente con ella.
- Un titular de la cuenta del operador que pueda firmar. AWS pide una firma manuscrita en la LOA (carta de autorización) e indica que la mayoría de los operadores rechazan las firmas electrónicas.
- Acceso de administrador a tu helpdesk y CRM, porque vas a volver a conectarlos.
- Tus informes de llamadas de los últimos 90 días (volumen por hora, tasa de abandono, tiempo de gestión) como referencia con la que compararás la nueva plataforma.
¿Por qué están migrando tantos centros de contacto ahora?
Para muchos equipos, la migración no es opcional. Los grandes productos de centro de contacto locales están llegando al término del soporte de sus proveedores, y la red telefónica de cobre del Reino Unido se está desactivando. Estas son las fechas que aparecen en las páginas de los propios proveedores y reguladores:
| Producto | Hito | Fecha |
|---|---|---|
| Genesys PureConnect | Cese del mantenimiento y soporte | 31 de julio de 2025 |
| Microsoft Skype for Business Server 2015 y 2019 | Cese del soporte | 14 de octubre de 2025 |
| Avaya Aura Call Center Elite 10.1.x | Cese del soporte del fabricante | 1 de enero de 2026 |
| Cisco UCCE, PCCE, UCCX, CVP 12.5 y 12.6 | Cese de las versiones de mantenimiento del software | 31 de diciembre de 2026 |
| PSTN de BT en el Reino Unido (red telefónica de cobre), según Ofcom | Retirada prevista | 31 de enero de 2027 |
| Cisco UCCE, PCCE, UCCX, CVP 12.5 y 12.6 | Última fecha de soporte | 31 de diciembre de 2027 |
| Mitel MiContact Center Business | Cese de las ventas de complementos | 31 de diciembre de 2027 |
| Genesys Engage local | Retirada de la solución local | 31 de diciembre de 2028 |
Si lo que te impulsa es una fecha límite como estas, planifica hacia atrás desde esa fecha y empieza pronto con los trámites del operador. AWS indica que exige que las solicitudes de portabilidad estén abiertas "several months before pending go-live dates" porque los operadores bloquean las portabilidades en días festivos y durante las tareas de mantenimiento.
¿Cuál es el único paso que no puedes deshacer?
La portabilidad del número. Todos los demás pasos de una migración a CCaaS son configuraciones que puedes revertir. La portabilidad traslada el número a un nuevo operador, y AWS deja claro que, una vez completada, "the gaining carrier has sole control of the phone number." Devolverlo al operador anterior implica una nueva LOA, nuevos documentos y una nueva portabilidad.
Eso cambia el orden en el que deberías hacer el trabajo. La pregunta no es "¿en qué fecha hacemos la transición?". Es "¿cuánto tiempo podemos mantener los dos sistemas funcionando antes de dar el paso irreversible?". Tanto AWS como Salesforce dan la misma respuesta sobre cómo ganar ese tiempo: primero, desvía las llamadas.
La lista de comprobación de Voice de Salesforce advierte que la portabilidad "is highly regulated, can't be rushed," y recomienda tres acciones: obtener un número nuevo para pruebas y producción, desviar hacia él el tráfico del número original hasta terminar las pruebas y, después, portar el original. La guía de migración de AWS describe esa misma fase de desvío como una forma de ofrecer "rapid rollback (which depends on a relatively simple change to call forwarding rules) without any dependencies on a carrier."
El desvío no es gratis, así que no lo dejes activado durante meses. AWS señala que, mientras está activo, pagas por la llamada entrante al número antiguo, el desvío saliente y la llamada entrante al número nuevo, y cada llamada ocupa un circuito de salida. Yo trato el desvío como un seguro de unas pocas semanas, no como una configuración permanente.
Paso 1: Haz un inventario de lo que hace el sistema antiguo
La mayoría de las sorpresas en una migración vienen de algo que hacía el sistema antiguo y que nadie documentó. Es la misma lección que aprenden los equipos cuando cambian de helpdesk. Antes de diseñar nada, anótalo todo:
| Área | Qué debes documentar |
|---|---|
| Números | Cada número DID, gratuito y compatible con SMS, a qué operador pertenece cada uno y en qué cola suena |
| Flujos de llamadas | Menús del IVR, horarios laborales y de festivos, reglas de desbordamiento, buzones de voz |
| Enrutamiento | Colas, habilidades, prioridades, quién puede recibir transferencias de quién |
| Integraciones | Registro de llamadas en el helpdesk, ventanas emergentes del CRM, líneas de pago, cualquier paso del IVR que consulte una cuenta |
| Grabaciones | Dónde se almacenan, reglas de conservación, quién puede recuperarlas para el control de calidad |
| Informes | Qué informes lee la dirección cada semana y cómo se calcula cada métrica |
| Dispositivos y red | Teléfonos de escritorio, auriculares, agentes que trabajan desde casa, configuración de la VPN |
Hay dos elementos que merecen especial atención. El primero son los SMS. Genesys advierte que los SMS de un número portado "will not be automatically transferred along with voice service. In fact, the SMS services will likely be disrupted." Si envías mensajes de pedidos o recordatorios de citas desde un número de soporte, señálalo ahora. El segundo es cualquier paso del IVR que llame a un sistema interno, como "introduce tu número de cuenta" para consultar una base de datos. Esa lógica hay que reconstruirla en la nueva plataforma, y es fácil pasarla por alto porque está dentro de un flujo que nadie ha abierto en años.
Paso 2: Diseña la nueva configuración (reconstrúyela, no la copies)
Los flujos de llamadas no se trasladan de una plataforma a otra. Un consultor de Amazon Connect lo explicó con claridad en Hacker News:
"when someone designs a call center with Amazon Connect, they use a GUI flowchart tool and create "contact flows". You can export the flow to JSON. But it isn't portable to other environments without some remapping."
Como de todos modos vas a reconstruirlos, simplifica. Las propias recomendaciones de AWS dicen "don't limit yourself" a trasladar sin cambios el antiguo centro de llamadas, y Salesforce recomienda empezar por sus flujos de contacto predeterminados y construir a partir de ellos. Un IVR de siete niveles que tenía sentido en 2014 suele reducirse a tres opciones y una devolución de llamada. Si usas Zendesk, mi guía del IVR de Zendesk Talk muestra un árbol telefónico sencillo.
Parte de lo que hacía el antiguo IVR ahora es tarea de un recepcionista telefónico con IA, que puede responder preguntas sencillas antes incluso de que la persona que llama llegue a una cola.
Dos decisiones de diseño que debes tomar en este paso:
- Cómo convivirán el sistema antiguo y el nuevo. Los agentes suelen trasladarse por grupos, y AWS señala que la fase de migración "might take several months," con equipos en distintas plataformas transfiriéndose llamadas entre sí. AWS sugiere usar números de transferencia dedicados entre las plataformas para que puedas medir las transferencias entre plataformas por separado.
- Qué pasará con las grabaciones antiguas. AWS ofrece dos opciones: migrar las grabaciones y los informes (comprueba primero el formato de audio) o archivarlos donde están hasta que termine su periodo mínimo de conservación. Archivarlos suele ser más barato, pero alguien tiene que responsabilizarse del acceso al archivo antiguo.
Ten en cuenta que la nueva plataforma requerirá conocimientos reales de administración. Si también vas a dejar Zendesk, mi guía de migración de Zendesk cubre la parte de los tickets. Un ingeniero sénior de telefonía que reseñó Genesys Cloud CX en G2 escribió:
"Genesys Cloud CX is extremely capable, but that capability comes with complexity. There are many situations where something that appears relatively straightforward ends up requiring Architect customization, Data Actions, APIs, or external automation."
Justin H., ingeniero sénior de telefonía, reseña en G2
Es una valoración acertada de la mayoría de las plataformas CCaaS empresariales, incluida Genesys. Reserva tiempo de ingeniería para la reconstrucción y evita quedarte sin margen de maniobra: las trampas de la dependencia de un proveedor que afectan a las herramientas de IA también se aplican a las plataformas telefónicas.
Paso 3: Reconecta la parte del helpdesk
Este es el paso que la mayoría de los planes comprimen en una sola línea, y es donde yo dedicaría más tiempo del que crees. El sistema telefónico se mueve. Tu helpdesk, centro de ayuda, macros, CRM y agente de IA se quedan donde están. Los teléfonos se trasladan; las conexiones entre los teléfonos y el helpdesk tienen que reconstruirse. Hay que volver a probar cada una de ellas.
Comprueba tres conexiones en particular:
- Registro de llamadas en tickets. ¿Cada llamada crea o actualiza un ticket en el helpdesk, con la grabación y la persona que llama vinculadas? Si vas a cambiar a una herramienta telefónica que se conecta a tu helpdesk, como CloudTalk y Zendesk, comprueba cómo queda el ticket con una llamada real.
- Ventana emergente del cliente que llama. Cuando suena el teléfono, ¿el agente ve la ficha del cliente? Esto suele depender de que el formato del identificador de llamadas coincida con el del CRM, algo que cambia entre operadores.
- Informes. El tiempo de gestión y la tasa de abandono se calculan de forma distinta en cada plataforma. Una persona que reseñó Genesys Cloud en G2 consideró los informes personalizados "difficult to navigate." Acuerda las nuevas definiciones con la dirección antes de la puesta en producción, o tu primer informe mensual parecerá un desastre que en realidad no lo es.
Después, comprueba qué hace la automatización de tu helpdesk con los tickets de llamadas. Es un detalle que se pasa por alto: las configuraciones de IA bien gestionadas suelen omitir deliberadamente los tickets telefónicos. Lesson Pro, un grupo de marcas de clases que gestiona dos cuentas de Zendesk, usa eesel para dejar notas y borradores en 1,900 tickets al mes, pero no toca los mensajes de voz. Luxedo, que usa Gorgias, hace que su agente omita los tickets de llamadas telefónicas, el spam y las encuestas para no gastar nada en ellos. Si tu nueva plataforma telefónica nombra o etiqueta los tickets de llamadas de forma distinta a la antigua, esas reglas dejan de funcionar sin avisar y, de repente, la IA está redactando respuestas a transcripciones de mensajes de voz. Revisa los disparadores, las vistas y las automatizaciones que filtran por tickets de llamadas.
La ventaja es que la parte del soporte por correo electrónico y chat no depende en absoluto de la plataforma telefónica. Un agente de IA que trabaja dentro del helpdesk sigue funcionando durante toda la migración. smava, una empresa alemana de comparación de préstamos, utiliza eesel en un único Zendesk para dos marcas: 27,000 tickets gestionados en un mes, 14,600 categorizados y 15,300 borradores de respuesta preparados. A una cola así le da igual con qué operador estén los teléfonos.
SamCart es un caso parecido en Freshdesk: un agente gestiona los tickets de Freshdesk y otro se encarga del chat de su sitio web, así que el soporte escrito tiene sus propios canales.
Paso 4: Prueba con números de reserva
Construye la nueva configuración con números temporales y pruébala antes de que reciba ninguna llamada de un cliente. La lista de comprobación para la puesta en producción de AWS pide que todas las líneas de servicio incluidas en el alcance hayan "successfully run UAT scripts" utilizando un número de teléfono temporal.
Escribe tu guion de pruebas empezando por los fallos y después por los casos sin problemas:
| Prueba | Qué debería ocurrir |
|---|---|
| Llamada normal, en horario laboral | IVR correcto, cola correcta, ticket creado en el helpdesk |
| Llamada fuera de horario o en un festivo | Mensaje de cierre correcto, buzón de voz o devolución de llamada |
| Todos los agentes ocupados | Mensaje de espera y después desbordamiento o devolución de llamada |
| Transferencia a un equipo que sigue en el sistema antiguo | La llamada se conecta y no se pide a la persona que llama que repita lo que ha dicho |
| La persona que llama pulsa teclas en el IVR | La entrada del teclado (DTMF) se reconoce en todos los menús |
| El helpdesk o el CRM no están disponibles | El agente puede seguir atendiendo la llamada |
| Un agente marca 911 desde un softphone | Se conecta sin prefijo y se activa la notificación (consulta más abajo) |
Comprueba también tus límites de capacidad antes de hacer pruebas a gran escala. AWS indica que las instancias nuevas pueden empezar con cuotas de apenas "10 concurrent calls or 5 phone numbers", así que solicita los aumentos con antelación. Y haz pruebas con las configuraciones reales de los agentes: AWS recomienda auriculares USB con cable en lugar de Bluetooth y una conexión Ethernet por cable, y sugiere presupuestar adaptadores antes de que empiece la migración.
Paso 5: Haz una prueba piloto con una cola mediante desvío
Elige una cola de bajo riesgo (consultas generales, una línea interna de TI, una región pequeña; mi artículo sobre centro de llamadas frente a mesa de servicio explica por qué las líneas de TI se comportan de forma distinta) y desvía su número a la nueva plataforma. Mantén en el sistema antiguo las líneas de gran volumen y las más críticas, como facturación, hasta que la prueba piloto funcione sin problemas.
Decide antes de empezar, con cifras, qué condiciones harán que reviertas el cambio. La lista de comprobación para la puesta en producción de AWS indica que debes vigilar en tiempo real las llamadas atendidas, la tasa de abandono, el tiempo medio de gestión y la cantidad de llamadas en cola, y mantener abierta una línea de conferencia "until go-live (or rollback) activities have been completed." Yo escribiría algo como "si la tasa de abandono supera el doble de la referencia de los últimos 90 días durante una hora, devolvemos el desvío a su estado anterior" y acordaría quién tiene la autoridad para tomar esa decisión.
Después, traslada el resto de las colas por grupos. AWS dice que el periodo con dos plataformas es costoso y que, cuanto más se alarga, mayor es "the risk of human errors such as making changes on the wrong platform." Avanza de forma constante, no lenta.
Paso 6: Porta los números
Una vez que todas las colas hayan funcionado sin problemas con números desviados, porta los originales. Esto es lo que dicen las principales plataformas sobre los plazos:
| Plataforma | Plazo de portabilidad (según su propia documentación) | Ten cuidado con |
|---|---|---|
| Amazon Connect | De 2 a 4 semanas en EE. UU. y Canadá, de 2 a 6 meses en otros lugares | Las solicitudes de EE. UU. no pueden enviarse con más de 30 días de antelación a la fecha de portabilidad |
| Genesys Cloud | Envía la solicitud con 2 a 3 semanas de antelación; la fecha puede tardar hasta 10 días en confirmarse | Los SMS no se trasladan con la voz |
| Talkdesk | De 2 a 4 semanas después de la aprobación de los documentos | No puedes elegir la fecha de portabilidad |
| Zendesk Talk | De 1 a 4 semanas en EE. UU. y Canadá, 6+ semanas en otros lugares | Las cuentas de prueba no pueden realizar portabilidades |
| Aircall | Varía según el país, por ejemplo, 7 días hábiles en Francia, hasta 45 días en Alemania | Los rangos deben portarse juntos |
El plazo que exige la ley es más corto que cualquiera de esos. En EE. UU., la FCC exige que una portabilidad simple se complete en un día hábil y una no simple en cuatro días hábiles. Pero un bloque de números de un centro de contacto en una troncal rara vez es "simple", y las semanas de la tabla corresponden a la documentación, la validación y la programación que rodean al cambio real.
La documentación es donde fallan las portabilidades. AWS enumera los cuatro motivos habituales de rechazo: un saldo pendiente o un cargo por portar el número a otro operador, un nombre o una dirección que no coincide con el CSR, un número que no se puede portar e información que falta, como una firma. Una LOA rechazada "resets the porting timelines." AWS también exige que la LOA esté fechada dentro de los últimos 15 días, así que no la firmes con un mes de antelación.
Dos reglas más que suelen tomar a la gente por sorpresa:
- No canceles el operador antiguo antes de tiempo. La FCC aconseja iniciar la portabilidad con el nuevo proveedor antes de cancelar el servicio antiguo, y Aircall advierte que los números de una cuenta cancelada pueden perderse permanentemente.
- Conoce tu plazo de cancelación. AWS necesita 5 días hábiles de preaviso para cancelar o reprogramar, y una vez que el número llega a la nueva RespOrg "the port is complete."
El propio día de la portabilidad, AWS advierte que esta "can be disruptive" porque las rutas se actualizan entre operadores, incluidos los que no participan en ella, y que "in rare cases it can take several hours" hasta que todo se estabilice. Haz la portabilidad una mañana tranquila de un día laborable, mantén a los agentes conectados a ambos sistemas, vigila cómo disminuye el tráfico en la plataforma antigua y realiza llamadas de prueba a cada flujo.
Paso 7: Estabiliza y después apaga el sistema antiguo
No retires la antigua PBX al día siguiente de la portabilidad. Mantenla funcionando durante un ciclo completo de facturación y al menos un periodo de mucha actividad, para poder comparar los informes (y tus cifras de ROI del centro de llamadas) y recuperar grabaciones antiguas si surge una disputa. Avisa a finanzas de que los costes se solapan: AWS señala que su propia facturación aumenta y los costes del sistema antiguo bajan solo después de que el nuevo centro de contacto entre en producción.
AWS también señala una carencia no técnica: "user training, process changes, and service desk changes are often overlooked until the project is close to completion." Antes de apagar el sistema antiguo, asegúrate de que tu equipo interno de TI o mesa de servicio sepa quién es responsable de la nueva plataforma y cómo abrir una incidencia relacionada con ella. AWS sugiere abrir una incidencia de prueba y seguirla durante todo el proceso.
¿Qué pasa con el 911 y los agentes remotos?
Esto es un requisito legal en EE. UU., no algo opcional. Según la ley Kari, cualquier sistema telefónico multilínea instalado después del 16 de febrero de 2020, lo que incluye tu nueva configuración en la nube, debe permitir que los usuarios marquen 911 directamente sin un prefijo como "9" y debe enviar una notificación (con un número para devolver la llamada y la ubicación) a alguien que probablemente vaya a verla.
Las normas de ubicación son más estrictas para los agentes que trabajan desde casa. Según 47 CFR 9.16, los dispositivos utilizados fuera de las instalaciones deben proporcionar automáticamente una ubicación a la que puedan acudir los servicios de emergencia (una dirección postal validada) cuando sea técnicamente viable o, en caso contrario, una ubicación que el usuario actualice manualmente. En la práctica, mi interpretación es esta: recopila la dirección de cada agente que trabaja desde casa, dale una forma sencilla de actualizarla cuando se mude y prueba la ruta de una llamada al 911 utilizando el procedimiento de pruebas de tu servicio local de emergencias. Pregunta a tu proveedor de CCaaS cómo gestiona esto su softphone antes de la puesta en producción, no después.
Lista de comprobación para preparar la transición
Marca cada elemento cuando esté listo. Si no puedes marcarlos todos, todavía no es el día de la portabilidad.
Antes de enviar la solicitud de portabilidad
¿Cuánto tarda una migración a CCaaS?
Para un equipo de un solo país con un único operador, de dos a tres meses es un plan realista: unas semanas de inventario y diseño, unas semanas de reconstrucción y pruebas, una prueba piloto y, después, las 2 to 4 weeks de documentación de la portabilidad en paralelo. Si hay varios países, el plazo se alarga, ya que AWS indica de dos a seis meses para portabilidades fuera de EE. UU. y Canadá, y trata más de 10 rangos de números o 10 ubicaciones como "a project" que requiere la participación de su equipo de cuentas.
La parte del helpdesk puede avanzar mucho más rápido, que es precisamente la razón para mantenerla separada. Un agente de IA que trabaja dentro del helpdesk no espera a los teléfonos. Luxedo conectó eesel a Gorgias en julio, creó sus conocimientos e instrucciones en agosto y activó el disparador en la última semana de agosto, todo en Gorgias. Mi cronograma de implementación de soporte con IA explica por qué la mayoría de los equipos tardan entre dos y ocho semanas.
Prueba eesel mientras trasladas tus teléfonos
Una migración a CCaaS supone unos meses estresantes para un equipo de soporte: los agentes están aprendiendo a usar un nuevo softphone, la cola piloto es inestable y la dirección quiere saber por qué han cambiado los informes. Es un mal momento para que también se acumule la cola de correo electrónico y chat. El compañero de helpdesk con IA de eesel se incorpora a tu helpdesk actual (Zendesk, Freshdesk, Gorgias y otros), aprende de tu centro de ayuda, tus macros y tus tickets anteriores (la misma base de conocimientos que usan tus agentes telefónicos), y redacta o envía respuestas, para que la cola de soporte escrito se mantenga bajo control mientras trasladas los teléfonos. Puedes simular su funcionamiento con tickets anteriores antes de que responda a nadie, y los planes empiezan en $299 al mes por 500 tickets en la página de precios.
Prueba eesel gratis con 100 créditos, o reserva una demo si quieres ayuda para planificarlo en torno a tu transición.