14 aspectos que conviene tener en cuenta al preparar una RFP para un servicio IPTV u OTT
Resumen rápido
Ya ha decidido lanzar un servicio de televisión. O quizá ya opera uno y la plataforma que le funcionaba bien hace unos años resulta cada vez más difícil de modificar.
En ambos casos, elegir al próximo socio tecnológico empieza por responder algunas preguntas dentro de su organización. ¿Qué quiere conseguir? ¿Qué necesita cambiar? Y, si ya tiene un servicio, ¿qué interrupciones puede permitirse?
Una solicitud de propuestas, o RFP, le permite resolver esas preguntas y explicar sus requisitos a los posibles proveedores. Si está bien preparada, le ayuda a recibir propuestas que realmente se puedan comparar. También adelanta las decisiones difíciles a un momento en el que todavía hay tiempo para tomarlas.
Para un proyecto previsto en 2026 o 2027, eso implica mirar más allá del lanzamiento. La RFP debe cubrir el servicio que utilizarán los clientes, la transición desde el entorno actual y el trabajo y los costes necesarios para mantenerlo en funcionamiento.
No necesita un documento de cien páginas para empezar. Sí necesita suficiente detalle para asegurarse de que usted y los proveedores hablan del mismo proyecto. Estos catorce aspectos le ayudarán.
1. Defina qué debe conseguir el proyecto
¿Por qué está invirtiendo en el servicio? Parece una pregunta obvia, pero la respuesta determinará casi todo lo que viene después.
Quizá quiera añadir televisión a un paquete de conectividad, llegar a clientes fuera de su red fija, introducir una nueva fuente de ingresos o sustituir una plataforma que encarece cualquier pequeño cambio. Un operador con un servicio consolidado también puede querer conservar los decodificadores y las integraciones que siguen siendo útiles mientras mejora la experiencia del cliente.
Exprese esas prioridades con claridad. «Modernizar nuestro servicio de televisión» deja mucho margen a la interpretación. «Sustituir las capas de gestión del servicio y de aplicaciones, manteniendo los dispositivos instalados compatibles y nuestro sistema de facturación» ofrece al proveedor un punto de partida concreto.
Acuerde también cómo se medirá el éxito. Una fecha de lanzamiento, un objetivo de cobertura de dispositivos o la posibilidad de que su equipo modifique paquetes sin solicitar desarrollo aportan más que una promesa genérica de flexibilidad.
2. Decida cómo generará ingresos el servicio
¿Los clientes pagarán una suscripción mensual? ¿La televisión se incluirá en un paquete de banda ancha o móvil? ¿Necesita publicidad, alquileres, eventos de pago por visión o una combinación?
La respuesta afecta a mucho más que la tarifa. Determina cómo deben funcionar conjuntamente los paquetes, los permisos de acceso, las promociones y la facturación. Una prueba gratuita, por ejemplo, necesita un inicio y un final claros, reglas de conversión a un paquete de pago y una experiencia previsible si falla el cobro.
Describa los modelos que necesita en el lanzamiento y los que podría incorporar más adelante. Explique después las reglas comerciales importantes. ¿Puede el cliente cambiar a un paquete superior de inmediato? ¿Qué sucede con su acceso cuando cancela? ¿Cuántas reproducciones simultáneas permite cada paquete?
Estos detalles ayudan a descubrir si una capacidad propuesta está lista para usarse o necesita integración y desarrollo adicionales.
3. Entienda por qué los clientes elegirán y mantendrán su servicio
¿Qué hará que alguien se suscriba? ¿Y qué le dará motivos para quedarse cuando termine la oferta inicial?
Empiece por el público y el contenido. Un servicio centrado en el deporte en directo tiene requisitos distintos de uno basado en canales locales o un catálogo de películas. Los acuerdos de derechos también pueden determinar dónde se puede ver el contenido, en qué dispositivos y si se permite verlo a la carta, grabarlo o reproducirlo sin conexión.
Convierta esas condiciones en requisitos de protección de contenido y cobertura de dispositivos. En lugar de pedir únicamente «compatibilidad con multi-DRM (gestión de derechos digitales)», identifique los dispositivos objetivo y las obligaciones de protección asociadas al contenido. Pida al proveedor que explique y demuestre cómo funcionará esa combinación.
Piense después en los hábitos cotidianos. ¿Puede el cliente encontrar el programa de esta noche, empezar uno que se perdió y seguir viéndolo en otra pantalla compatible? ¿La experiencia sigue respondiendo bien en los dispositivos más antiguos de su parque instalado? Son preguntas útiles para una RFP y todavía más útiles para una demostración.
4. Defina dónde y cómo distribuirá el servicio
¿Sus espectadores utilizan su propia red gestionada, internet abierto o ambos? ¿Prestará el servicio en un país o en varios mercados?
Estas decisiones afectan a la arquitectura de distribución, los derechos de contenido, las variantes regionales y el modelo de soporte. Un servicio IPTV gestionado, uno OTT y uno híbrido no deben dimensionarse como si distribuyeran todas las reproducciones de la misma manera.
Explique a los proveedores dónde están sus suscriptores y qué conectividad, centros de datos e infraestructura de distribución tiene. Indique si pretende operar una red de distribución de contenido (CDN) privada, contratar servicios externos de CDN o comparar ambas opciones.
Deje claros los límites. Si usted aporta conectividad o una CDN existente, ¿con qué debe integrarse el proveedor? Si el proveedor se encarga de la distribución, ¿qué incluye el precio y quién investiga los problemas de reproducción? Acuerde cómo se medirá el rendimiento en el dispositivo del espectador y dentro de la plataforma.
5. Determine qué cambia y cómo se migrarán los clientes
Una plataforma nueva no exige necesariamente renovar todos los sistemas que la rodean. Dibuje el entorno actual y los requisitos de integración y decida qué espera sustituir, conservar o retirar. La facturación, el CRM, la identidad, los equipos de cabecera, la protección de contenido y los dispositivos deben aparecer en ese mapa.
Reconozca lo que todavía no sabe. Algunos decodificadores antiguos podrán reutilizarse y otros necesitarán sustitución. Permita que los proveedores evalúen los modelos, las versiones de software y las limitaciones reales, en vez de prometer compatibilidad con un «parque heredado» sin definir.
Si ya existe un servicio, la migración debe formar parte de la RFP desde el principio. ¿Cómo se trasladarán las cuentas, las suscripciones y los permisos de acceso? ¿Funcionarán en paralelo la plataforma antigua y la nueva? ¿Puede empezar con un grupo reducido de clientes antes de migrar más hogares?
Defina qué constituye una migración satisfactoria y cuándo debe detenerse. Por ejemplo, un requisito ilustrativo podría establecer que los clientes migrados conservan sus paquetes, pueden activar dispositivos compatibles y superan las comprobaciones de reproducción acordadas antes de pasar al siguiente grupo. Exija un plan de reversión que explique qué se puede deshacer, en cuánto tiempo y cómo se conciliarán los cambios realizados durante la transición.
Incluya la comunicación al cliente y la preparación del soporte. Una puesta en marcha técnicamente correcta puede generar llamadas innecesarias si los clientes no saben qué esperar.
6. Elija el despliegue según la carga de trabajo y su equipo
El despliegue local, en nube privada, en nube pública o híbrido puede tener sentido. La pregunta útil es qué opción se adapta al servicio y a las personas que lo operarán.
Si ya dispone de infraestructura, conectividad y un equipo de operaciones experimentado, puede ser conveniente conservar esas inversiones. Si necesita un servicio gestionado, concrete qué espera que gestione el proveedor.
Compare las opciones con la misma carga de trabajo. Incluya tráfico, almacenamiento, redundancia, copias de seguridad, recuperación, monitorización, actualizaciones y soporte. El alojamiento en la nube sigue necesitando un modelo operativo, y la disponibilidad depende de la arquitectura y los compromisos contractuales, además de la ubicación de los servidores.
Pregunte quién aplica parches a cada componente, quién responde a una incidencia y qué ocurre si falla una ubicación o una dependencia. Los objetivos de recuperación y el comportamiento de la conmutación por error deben contar con un diseño y un plan de pruebas. Si prevé cambiar el alojamiento más adelante, incluya las condiciones prácticas y comerciales para hacerlo.
La seguridad necesita la misma claridad. Especifique controles de acceso administrativo, registros de auditoría, gestión de vulnerabilidades y notificación de incidentes. Explique sus requisitos sobre datos de suscriptores, conservación y ubicaciones de tratamiento, incluidos los servicios de analítica o recomendaciones. Pida a los proveedores que identifiquen sus responsabilidades y aporten pruebas de los controles necesarios.
7. Haga que las responsabilidades sean fáciles de entender
¿Prefiere que un proveedor principal coordine la solución o tiene equipo para gestionar varios proveedores especializados?
Un único responsable puede simplificar la implantación y el soporte si el contrato hace efectiva esa responsabilidad. Un modelo con varios proveedores puede ofrecer más opciones, pero alguien debe seguir siendo responsable de las integraciones y de resolver los problemas que afectan a varias partes.
Piense en un espectador que no puede reproducir un canal. La causa puede estar en la aplicación, el servicio de permisos, el DRM, el flujo de vídeo o la red. ¿Quién recibe la incidencia, coordina la investigación y confirma la solución?
Cada propuesta debe identificar qué entrega el proveedor, qué entregan sus socios y qué queda en manos de su equipo. Incluya pruebas, coordinación de versiones y soporte tras el lanzamiento. Aquí es donde un diagrama de arquitectura bien presentado debe convertirse en un modelo operativo viable.
8. Dé una estructura clara a la RFP
Facilite que los proveedores entiendan el proyecto y que su equipo revise las respuestas. Una estructura práctica incluye:
- Antecedentes del proyecto, objetivos comerciales y alcance
- Entorno actual y servicio objetivo
- Requisitos funcionales, técnicos, de seguridad y de migración
- Supuestos de capacidad y responsabilidades operativas
- Hitos de entrega, pruebas y aceptación
- Propuesta económica, criterios de evaluación e instrucciones de presentación
Incluya diagramas cuando ayuden y asigne una referencia coherente a cada requisito. Establezca un procedimiento para las preguntas de aclaración que permita a todos los licitadores recibir la misma información relevante.
Si quedan dudas importantes de viabilidad, una solicitud de información, o RFI, o un análisis previo específico puede ser útil antes de la licitación formal. Es más fácil mejorar ahora un requisito incierto que negociar un proyecto distinto después de seleccionar al proveedor.
9. Compare el coste de operar y modificar el servicio
El precio inicial de la plataforma no cuenta toda la historia. ¿Qué sucede cuando crece su base de suscriptores, aumenta el consumo o quiere añadir una aplicación para otro dispositivo?
Solicite un desglose de los cargos únicos y recurrentes. Incluya licencias, implantación, integraciones, migración, infraestructura, tráfico de CDN, almacenamiento, soporte, servicios de terceros y actualizaciones. Considere también el esfuerzo interno necesario para operar la solución.
Aclaren las unidades de facturación. ¿«Por suscriptor» significa cuenta registrada, cuenta activa u hogar? ¿Se cobran por separado los dispositivos adicionales o las reproducciones simultáneas? ¿Qué consumo está incluido y qué ocurre al superarlo?
Compare escenarios realistas de lanzamiento y crecimiento durante el mismo periodo y con los mismos supuestos. Incluya el solapamiento de las dos plataformas durante la migración. Revise finalmente el coste del cambio y de la salida: acceso a API, desarrollo a medida, exportación de datos, asistencia para la transición y condiciones para finalizar el contrato.
10. Convierta los requisitos en respuestas verificables
«Compatible» es un punto de partida útil. Rara vez es una respuesta completa.
Para cada requisito, separe dos cuestiones: hasta qué punto lo cumple la propuesta y cómo lo entregará el proveedor. Una función puede cumplirlo por completo y depender de una integración. Otra puede existir en el producto y satisfacer solo parte del requisito.
Utilice un formato de respuesta que registre:
- Cumplimiento total, parcial o inexistente, con las limitaciones explicadas
- Entrega mediante funcionalidad existente, configuración, integración o desarrollo a medida
- Disponibilidad actual o dependencia de una versión futura
- Evidencias, dependencias, responsables y costes incluidos
Para los requisitos críticos, acuerde cómo se demostrará el cumplimiento. La documentación puede resolver una cuestión; otra puede requerir una prueba en el dispositivo objetivo o una demostración de integración.
Trate por separado las capacidades previstas y las disponibles hoy. Si el proyecto depende de una función futura, entienda el compromiso de entrega y sus opciones si llega tarde.
11. Dimensione el servicio con supuestos reales de consumo
¿Cuántos suscriptores espera tener? Ahora la pregunta más difícil: ¿cuántos verán contenido al mismo tiempo y qué estarán viendo?
La planificación de capacidad necesita ambas respuestas. Especifique la concurrencia normal y máxima, incluidos los grandes eventos en directo, y distinga la distribución multicast gestionada del streaming unicast. Describa los canales, la combinación de SD, HD y UHD, los perfiles de codificación y las tasas de bits previstas.
Incluya la retención de catch-up por canal, el tamaño y crecimiento del catálogo de vídeo bajo demanda y los requisitos de grabación. Para el PVR en red, explique cuántos clientes podrán utilizarlo, cuántas horas pueden conservar y qué modelo de grabación y derechos se aplican. Estos supuestos pueden cambiar considerablemente el almacenamiento necesario.
Como ejemplo sencillo, 10.000 reproducciones unicast simultáneas con una media de 6 Mb/s representan 60 Gb/s de carga útil de vídeo. Esa cifra no incluye la sobrecarga de los protocolos ni la capacidad adicional para mantener la resiliencia. Diez mil suscriptores registrados dicen mucho menos sobre el ancho de banda necesario.
Pida a los proveedores que expliquen sus supuestos de dimensionamiento para almacenamiento, distribución desde el origen y los nodos de borde, autenticación y servicios de permisos. Exija pruebas de rendimiento que reflejen la combinación prevista de consumo y actividad de cuentas, en lugar de aceptar una única cifra de capacidad.
12. Pruebe las funciones como las utilizarán los clientes
Su lista puede incluir televisión en directo, guía electrónica de programas, búsqueda, catch-up, reinicio de programas, pausa, grabación y vídeo bajo demanda. Decida cuáles son esenciales y relaciónelas con recorridos completos de uso.
Por ejemplo, un cliente encuentra el programa de ayer en la guía, lo inicia, lo pausa y lo retoma en otro dispositivo compatible. ¿Qué partes del recorrido funcionan, con qué reglas de derechos y de cuenta y en qué versiones de dispositivo?
Incluya activación, cambios de paquete, controles parentales, sustitución de dispositivos y atención a una suscripción caducada. Estos recorridos revelan conexiones entre sistemas que una demostración cuidada de la pantalla de inicio puede ocultar.
Pruebe dispositivos representativos de su propio parque, incluido el hardware antiguo que pretende conservar. Especifique expectativas medibles de arranque, navegación y reproducción con condiciones de prueba acordadas. Si un proveedor propone búsqueda o recomendaciones asistidas por IA, evalúe su utilidad con su catálogo, idiomas y permisos de uso de datos. Inclúyalas porque resuelven una necesidad del servicio y compruebe el resultado.
Mire también más allá de la versión de demostración. ¿Quién mantiene las aplicaciones cuando cambian los sistemas operativos? ¿Qué modelos y versiones seguirán siendo compatibles y cómo se informará a los clientes cuando termine el soporte?
13. Decida cómo puntuará las propuestas
Redactar requisitos y evaluar respuestas son tareas diferentes. Acuerde el método de evaluación antes de recibir las propuestas.
Identifique los requisitos que una oferta debe cumplir para seguir en el proceso. Después, pondere los demás criterios según sus prioridades: experiencia del cliente, viabilidad de la migración, encaje operativo, confianza en la entrega y coste total.
Utilice las respuestas de cumplimiento del punto diez como evidencia para la puntuación. No otorgue el mismo valor a una capacidad disponible y demostrada que a una promesa sin respaldo de desarrollo futuro.
Oriente las demostraciones y las pruebas de concepto hacia las cuestiones que podrían cambiar su decisión. Una prueba específica de un dispositivo instalado o de una integración difícil puede aportar más que otra presentación general del producto.
Mantenga visibles los supuestos y las cuestiones pendientes durante la evaluación. Conviene saber qué está aceptando antes de firmar el contrato.
14. Hable con operadores que tengan proyectos comparables
Los casos de éxito de operadores y las referencias son más útiles cuando se parecen al servicio que necesita construir o sustituir. Busque dispositivos, modelos de distribución, integraciones, dificultades de migración y responsabilidades operativas comparables.
Pregunte qué ocurrió después de la selección. ¿La migración siguió el plan propuesto? ¿Qué exigió más trabajo del previsto? ¿Cómo responde el soporte cuando una incidencia afecta a varios proveedores? ¿Qué dificultad presentan las actualizaciones y los cambios cotidianos?
Un gran despliegue puede demostrar escala, pero un operador más pequeño con un entorno similar puede aportar más información sobre sus riesgos concretos. Cuando sea posible, hable con personas que participaron en la implantación y con quienes se encargan de la operación diaria.
Está eligiendo un socio para los años posteriores al lanzamiento, además del propio lanzamiento. Su capacidad para explicar las limitaciones y asumir responsabilidades importa tanto como el producto.
Antes de enviar la RFP
Léala una vez desde la perspectiva del proveedor. ¿Podría alguien que no conoce su negocio entender qué necesita, qué debe entregar y cómo evaluará usted su respuesta?
Después, léala desde la perspectiva de su equipo de operaciones. ¿Está claro cómo se migrarán los clientes, quién operará el servicio y qué ocurrirá si algo falla?
Si alguna respuesta no está clara, dedique algo más de tiempo a esas secciones. Una RFP clara ofrece a todos un mejor punto de partida y aumenta sus posibilidades de elegir una plataforma con la que pueda trabajar a medida que crece el servicio.
Para conectar la decisión de compra con su estrategia de plataforma, consulte la Guía de TV para telcos, la guía de UniqCast para la modernización de IPTV y OTT.
¿Está preparando un nuevo servicio o la sustitución de una plataforma? Comente sus requisitos de IPTV u OTT con UniqCast.
