Post actualizado el día octubre 31, 2026 by DeiviSanzPlay
La semana pasada recibí un mensaje de Lucía, responsable de operaciones de un call center de 40 agentes en Valencia. Habían migrado su VoIP para call centers en un fin de semana, convencidos por el precio. El lunes, entre las 9:00 y las 11:00, perdieron cientos de llamadas sin saber por qué. No fue el proveedor: fue el diseño.
El problema no era la tecnología, era el dimensionamiento
Su centralita virtual contratada incluía 40 canales simultáneos, justo los agentes que tenían. En teoría, perfecto. En la práctica, cada llamada entrante consume un canal y cada llamada saliente otro. Cuando un agente hacía una transferencia consultiva, se abrían dos canales para una sola conversación. En hora punta, con 32 agentes en línea y varias transferencias activas, el sistema se quedó sin circuitos y empezó a rechazar llamadas con un tono de ocupado que el cliente interpretó como cierre.
Ese detalle —la transferencia consultiva duplica canales— aparece en la mayoría de manuales de VoIP para call centers, pero casi nunca se explica con un ejemplo numérico. Lucía lo aprendió a base de reclamaciones.
Qué salió mal, paso a paso
El primer error fue asumir que el ancho de banda de fibra sobraba. Tenían 600 Mbps simétricos, sí, pero el router del proveedor aplicaba QoS de forma agresiva al tráfico SIP cuando detectaba streaming de vídeo en la sala de descanso. Las llamadas se entrecortaban de forma intermitente, no constante, lo que hacía casi imposible diagnosticarlo. Tuvieron que priorizar el tráfico RTP en el router y separar la red de voz de la de invitados.
El segundo error fue el código de país de los números. Compraron numeraciones locales de varias provincias sin comprobar la cobertura de emergencias. En España, un número VoIP que atiende llamadas al 112 necesita estar correctamente geolocalizado; si no, el operador de emergencias no recibe la dirección del centro. No es un fallo que aparezca en las pruebas de calidad, pero sí en una auditoría real.
El tercer error, el más caro: no probaron la conmutación por fallo. El proveedor prometía redundancia en dos centros de datos, pero la configuración de la cuenta solo apuntaba a una IP. Cuando el nodo principal tuvo un mantenimiento no anunciado, el sistema no conmutó solo. Estuvieron 47 minutos sin servicio en plena campaña.
Lo que sí funcionó y lo que no
La calidad de voz del códec G.722 mejoró notablemente la percepción de los clientes frente al G.729 que usaban antes, a costa de más ancho de banda por llamada. En su caso, con fibra simétrica, valía la pena. En cambio, el softphone que eligieron inicialmente consumía demasiada CPU en los equipos antiguos del turno de tarde y provocaba microcortes. Cambiaron a un cliente ligero basado en web y se resolvió.
También descubrieron que la integración con su CRM solo funcionaba en horario de oficina del proveedor del CRM, porque dependía de una API con límite de peticiones. En picos de campaña, las pantallas emergentes dejaban de abrirse y los agentes volvían al papel. Esa limitación no aparece en las comparativas de VoIP para call centers porque depende de terceros.
Esto no funciona para todos los call centers
Si tu operación depende de fax o de líneas analógicas para datáfonos antiguos, la migración completa a VoIP te va a obligar a mantener un gateway ATA o a cambiar los terminales de pago. Si tu plantilla está repartida en países con regulaciones distintas sobre grabación de llamadas, necesitas revisar el consentimiento por país antes de activar la grabación centralizada.
Tampoco recomiendo VoIP para call centers con menos de cinco agentes que solo hacen llamadas salientes locales: una centralita en la nube con tarifa plana puede salir más cara que una línea tradicional con desvío. He visto pymes pagar por funciones de cola que nunca usan.
Qué haría distinto la próxima vez
Lucía ahora exige tres cosas antes de firmar: una prueba de carga con el doble de canales contratados, un documento escrito con el plan de conmutación por fallo y una cláusula de compensación por caídas superiores a quince minutos. También pide el registro de llamadas perdidas de la primera semana en formato CSV, no en un panel web que se borra a los siete días.
La lección no es que la VoIP para call centers sea mala. Es que la mayoría de los incidentes que veo no vienen del protocolo SIP ni del códec, sino de decisiones de dimensionamiento y de contratos que nadie leyó. La próxima vez que alguien te prometa «calidad de voz garantizada», pídele la latencia máxima comprometida por escrito y el jitter aceptado. Si no lo tienen, ya sabes dónde va a fallar.
Perfiles verificables: Sitio web
Publicado el 31 de October de 2026. Última revisión: 31 de October de 2026.
