Cómo elegir un proveedor white-label de SIM y eSIM

Un proveedor white-label de SIM y eSIM puede acortar el camino entre una idea y una marca de conectividad operativa. También puede convertirse en una de las dependencias más importantes del negocio.

El proveedor puede influir en los países y redes que podrá vender, la rapidez con la que los clientes reciben sus perfiles, lo que puede consultar su equipo de soporte, la precisión con la que se tarifica el consumo, el margen que conserva y la posibilidad de trasladar el servicio a otro proveedor en el futuro.

Por tanto, elegir bien exige más que comparar el número de países y los precios mayoristas. Una evaluación rigurosa debe comprobar todo el modelo operativo: alcance del producto, conectividad, aprovisionamiento, software, datos, seguridad, soporte, condiciones comerciales y derechos de salida.

La pregunta más útil no es:

¿Qué proveedor tiene la lista de funciones más larga?

Sino:

¿Qué proveedor puede respaldar nuestra propuesta concreta de forma fiable, transparente y económicamente viable, preservando el control que necesitamos?

Puntos clave

• Defina el producto, el recorrido del cliente, los países objetivo y las responsabilidades operativas antes de solicitar propuestas.
• No compare proveedores solo por el número de países anunciado. Verifique las redes reales, las tecnologías de acceso, las restricciones, el enrutamiento y el rendimiento esperado en los mercados prioritarios.
• Confirme qué arquitectura GSMA, componentes de aprovisionamiento, dispositivos y tipos de eUICC admite el servicio propuesto. «Preparado para eSIM» no es una respuesta técnica completa.
• Trate la demostración de la plataforma como una prueba operativa. Pida al proveedor que complete pedidos, cancelaciones, sustituciones, exportaciones e investigaciones de soporte reales.
• Separe los cargos únicos, las cuotas recurrentes, los cargos por consumo, los compromisos mínimos, la exposición al tipo de cambio y los cargos excepcionales.
• Defina quién es titular de la marca, el contrato con el cliente final, los datos de los clientes, los dominios, las aplicaciones, las cuentas de pago y la analítica.
• Los certificados de seguridad aportan pruebas útiles, pero su alcance importa. Verifique qué entidad jurídica, sistema y subcontratista cubre cada garantía.
• Un acuerdo de nivel de servicio debe definir eventos medibles, exclusiones, tiempos de respuesta, escalado y medidas compensatorias. Un porcentaje sin método de medición ofrece poca protección.
• Pruebe al proveedor mediante un piloto con dispositivos, países, redes y condiciones de fallo representativos antes del lanzamiento completo.
• Negocie la exportación de datos, la asistencia para la transición y los procedimientos posteriores a la terminación antes de empezar la integración.

Empiece por sus requisitos, no por la demostración del proveedor

Una demostración cuidada puede hacer que cualquier plataforma parezca adecuada. Normalmente sigue un recorrido exitoso con un dispositivo compatible, un perfil disponible y un destino elegido cuidadosamente.

Los requisitos reales son menos ordenados.

Un negocio de viajes puede necesitar entrega inmediata, paquetes por destino, códigos de descuento, varias monedas y soporte para clientes que instalan el perfil antes de salir. Una empresa de IoT puede dar más importancia a las operaciones masivas del ciclo de vida, las redes privadas, la larga vida útil de los dispositivos, las alertas de consumo y la recuperación cuando no es posible acceder físicamente a los equipos. Un banco o un minorista puede necesitar integrar la conectividad en una aplicación existente y no querer una tienda white-label independiente.

Antes de contactar con los proveedores, defina al menos:

• los segmentos de clientes objetivo;
• los países prioritarios y la distribución prevista del tráfico;
• los casos de uso de consumo, empresa, viajes, SIM física o IoT;
• los requisitos de solo datos, voz, SMS y numeración;
• el volumen previsto de pedidos y el perfil de consumo;
• los canales web, de aplicaciones, API y revendedores necesarios;
• el control deseado sobre los pagos y la relación con el cliente;
• los requisitos de marca y localización;
• los horarios de soporte, idiomas y modelo de escalado;
• los mercados regulatorios y las obligaciones de protección de datos;
• la fecha de lanzamiento y los recursos para la implementación;
• las funciones que deben seguir siendo portables si cambia de proveedor.

Este conjunto de requisitos crea una base común. Sin él, un proveedor puede presupuestar una tienda compartida básica mientras otro incluye una integración API personalizada, aplicaciones nativas y soporte dedicado. Los importes no serán comparables porque los servicios propuestos no son equivalentes.

Comprenda qué ofrece realmente el proveedor

«Proveedor white-label de eSIM» no es un modelo operativo estandarizado. La empresa que vende la plataforma puede realizar algunas funciones por sí misma y obtener otras de proveedores de su cadena de suministro.

Un servicio completo puede incluir:

• un sitio web o una aplicación para el cliente;
• un catálogo de productos y herramientas de precios;
• procesamiento de pagos;
• gestión de pedidos y derechos de servicio;
• inventario de perfiles eSIM y acceso al aprovisionamiento remoto;
• fabricación y distribución de SIM físicas;
• relaciones con redes móviles y socios de roaming;
• sistemas de abonados, tarificación y control del consumo;
• administración de clientes y socios;
• API y webhooks;
• controles antifraude;
• soporte de primer y segundo nivel;
• alojamiento, monitorización y respuesta a incidentes;
• procesos regulatorios y fiscales.

Pocos proveedores poseen todas las capas. Eso no supone automáticamente una debilidad. Los servicios de telecomunicaciones funcionan mediante cadenas de suministro por diseño. Lo importante es que esa cadena sea visible, esté controlada y tenga respaldo contractual.

Pida al ofertante una matriz de responsabilidades que identifique:

La tabla debe reflejar el servicio propuesto, no una presentación comercial genérica. Si antes de firmar no se puede identificar quién responde por una descarga de perfil fallida, un registro de consumo disputado o una caída de roaming, será aún más difícil resolverlo durante una incidencia real.

Criterio 1: Encaje con el modelo de negocio

El primer filtro consiste en determinar si el proveedor admite el modelo comercial que pretende operar.

Preguntas que debe plantear

• ¿La oferta es un programa de afiliados, un modelo de reventa, un servicio white-label, una plataforma API, un servicio MVNE o una combinación?
• ¿Quién contrata con el cliente final?
• ¿Puede fijar los precios minoristas y las promociones?
• ¿Puede elegir qué productos y mercados se muestran?
• ¿Puede crear subrevendedores, cuentas corporativas o socios de distribución?
• ¿Se le permite combinar el servicio con otros proveedores de conectividad?
• ¿Puede utilizar su propio proveedor de pagos, CRM, analítica y sistema de atención al cliente?
• ¿Permite el contrato los países de venta y las categorías de clientes previstos?

Un proveedor puede ser técnicamente capaz y, al mismo tiempo, comercialmente inadecuado. Por ejemplo, una tienda pensada para vender eSIM de viaje a particulares puede no admitir cuentas empresariales con facturación, mientras que una plataforma de conectividad IoT puede no ofrecer el proceso de compra y entrega al consumidor que necesita una marca de viajes.

Pruebas que debe solicitar

• una matriz de responsabilidades propuesta;
• ejemplos de recorridos de clientes y revendedores;
• una lista de módulos estándar y opcionales;
• una descripción escrita de los canales y territorios permitidos;
• ejemplos de informes y estados de liquidación;
• un borrador de contrato con el mismo modelo comercial descrito en la propuesta.

Criterio 2: Capacidades del producto y del recorrido del cliente

La plataforma debe admitir el servicio que realmente comprará el cliente, no limitarse a crear una página de catálogo.

Para productos de consumo y viajes, examine si puede gestionar:

• planes locales, regionales y globales;
• paquetes de datos fijos y productos recurrentes;
• ofertas de solo datos o con voz y SMS;
• recargas y ampliaciones;
• reglas de activación diferida o con el primer uso;
• comunicación del vencimiento y la validez del plan;
• orientación sobre dispositivos compatibles;
• códigos QR, datos de activación manual y recorridos de instalación directa compatibles;
• visualización en varias monedas, impuestos y facturas;
• lógica de cupones, afiliados y promociones;
• cuentas de clientes e historial de pedidos;
• reglas de cancelación, reembolso y sustitución.

Para SIM físicas, añada:

• formatos de tarjeta y proceso de diseño gráfico;
• embalaje e inserción;
• control de números de serie y existencias;
• personalización y estados de activación;
• destinos de envío y seguimiento de entregas;
• logística de devoluciones y sustituciones;
• previsiones, pedidos mínimos y plazos de suministro.

Para IoT, añada:

• inventario de dispositivos y SIM;
• activación, suspensión y cambios de políticas masivos;
• alertas por umbrales;
• opciones de APN privado o red privada;
• VPN o interconexión segura;
• requisitos de IP fija o privada;
• control del ciclo de vida mediante API;
• correspondencia entre dispositivos y perfiles;
• continuidad del producto a largo plazo;
• arquitectura eSIM adecuada y capacidad de gestión remota.

No dé por hecho que una función existe porque sea habitual en el mercado. Pida al proveedor que demuestre cada recorrido obligatorio utilizando exactamente el nivel de servicio incluido en la propuesta.

Criterio 3: Cobertura, redes y diseño de conectividad

«Cobertura en 190 países» es un resumen comercial, no un diseño de red.

Las preguntas útiles son:

• ¿Qué redes móviles están permitidas en cada país prioritario?
• ¿Hay más de una red disponible y la SIM puede realmente seleccionar entre ellas?
• ¿Las redes están disponibles mediante un único perfil o mediante varios productos independientes?
• ¿Qué tecnologías de radio se admiten, como LTE o 5G?
• ¿Hay servicios restringidos, incluidos compartir internet, voz, SMS, uso de VPN o determinadas categorías de aplicaciones?
• ¿Dónde sale el tráfico de internet de la red móvil?
• ¿Se admiten casos de uso sensibles a la latencia o regulados?
• ¿Qué política de uso razonable se aplica a los productos «ilimitados»?
• ¿Puede cambiar la lista de redes o el acceso comercial durante el contrato?
• ¿Cómo notificará el proveedor los cambios importantes de cobertura?

El número de nombres de redes en una hoja de cálculo no debe considerarse una garantía de rendimiento. La disponibilidad depende de la suscripción, la configuración de roaming, las bandas del dispositivo, las condiciones de radio locales, la congestión, las políticas y el enrutamiento.

Solicite pruebas en tres niveles

1. Derecho comercial de acceso: la lista contratada de países, redes, tecnologías y restricciones.
2. Configuración técnica: los perfiles, el comportamiento de selección de redes preferidas, el APN, el enrutamiento y las reglas de producto que hacen posible el acceso.
3. Rendimiento observado: resultados de pruebas en dispositivos y ubicaciones representativos, incluidos registro, caudal de datos, latencia y estabilidad cuando estas medidas sean relevantes.

Un proveedor que no puede distinguir entre disponibilidad contratada y rendimiento probado le ofrece un catálogo, no garantías operativas.

Criterio 4: Arquitectura de SIM, eSIM y aprovisionamiento

La capacidad eSIM debe examinarse como una arquitectura, no como una función de código QR.

Para eSIM de consumo, confirme la relación entre:

• la eUICC del dispositivo;
• el perfil del operador;
• el SM-DP+ responsable de preparar y entregar el perfil;
• el Local Profile Assistant del dispositivo;
• cualquier mecanismo de descubrimiento o activación;
• la suscripción de conectividad y los acuerdos de red.

La especificación técnica de aprovisionamiento remoto de SIM de consumo de GSMA es SGP.22. La arquitectura IoT más reciente se especifica mediante SGP.31 y SGP.32. Un producto de consumo SGP.22 no es automáticamente una solución SGP.32 de gestión de flotas.

Pregunte:

• ¿Qué arquitectura GSMA y versiones de las especificaciones se admiten?
• ¿Qué parte opera el SM-DP+, el eIM u otro componente de gestión de suscripciones?
• ¿Qué pruebas de conformidad y garantías de seguridad de GSMA se aplican a esos entornos?
• ¿Qué dispositivos, sistemas operativos, eUICC y módulos se han probado?
• ¿Qué estados de perfil expone la plataforma?
• ¿Cuándo empieza la validez del plan?
• ¿Se puede volver a descargar, transferir o sustituir un perfil?
• ¿Qué sucede después de una descarga parcial o interrumpida?
• ¿Qué tratamiento comercial reciben los perfiles no utilizados, descargados, habilitados, eliminados y caducados?
• ¿Qué identificadores están disponibles para los equipos de soporte y operaciones?

GSMA mantiene especificaciones eSIM y un ecosistema de conformidad para un aprovisionamiento remoto interoperable y seguro. El comprador debe verificar el alcance pertinente en lugar de aceptar un logotipo o una frase «conforme con GSMA» sin explicación.

Criterio 5: Usabilidad de la plataforma y visibilidad operativa

La plataforma de administración es donde su equipo investigará problemas, controlará el inventario y conciliará el servicio. Una tienda atractiva para consumidores no compensa una consola operativa deficiente.

La plataforma debe permitir observar los estados importantes. Según el servicio, pueden incluir:

• pedido creado y estado del pago;
• perfil reservado o asignado;
• información de activación emitida;
• perfil descargado, instalado, habilitado, deshabilitado o eliminado;
• primer registro en la red;
• inicio y vencimiento del paquete;
• registros de consumo y saldo disponible;
• estado de la recarga;
• suspensión y reactivación;
• acciones de soporte e historial de auditoría.

Evalúe si el portal admite:

• búsqueda por pedido, cliente, EID, ICCID u otro identificador relevante;
• acceso basado en roles para distintos equipos y revendedores;
• operaciones masivas con salvaguardas;
• exportaciones e informes programados;
• categorías de error claras;
• marcas de tiempo y zonas horarias visibles;
• registros de auditoría para acciones sensibles;
• alertas configurables;
• localización;
• documentación accesible y ayuda dentro del producto.

Utilice una demostración con un guion definido

No pida al equipo comercial que «muestre la plataforma». Dé a todos los proveedores preseleccionados el mismo guion:

1. Crear un nuevo cliente y realizar un pedido.
2. Emitir una eSIM e identificar su estado de aprovisionamiento.
3. Simular o localizar una instalación fallida.
4. Determinar si se descargó el perfil.
5. Sustituir o reembolsar el pedido conforme a la política propuesta.
6. Aplicar una recarga o un cambio de ciclo de vida.
7. Exportar los datos del cliente, pedido, perfil y consumo.
8. Mostrar qué administrador realizó cada acción.
9. Crear un rol restringido de agente de soporte.
10. Seguir una incidencia desde el soporte de primer nivel hasta el escalado al proveedor de la cadena de suministro.

Este ejercicio revela más que una lista de funciones. Muestra si el sistema refleja el trabajo real de soporte.

Criterio 6: Calidad de las API, los webhooks y la integración

Un logotipo de API no demuestra que una plataforma esté preparada para integrarse.

Evalúe:

• el modelo de autenticación y autorización;
• la separación de los entornos de desarrollo y producción;
• la calidad de la documentación y los ejemplos de solicitudes;
• la idempotencia de las operaciones que crean pedidos;
• las respuestas de error previsibles;
• los límites de solicitudes y el comportamiento de concurrencia;
• la paginación y los filtros;
• la firma de webhooks y la protección contra ataques de repetición;
• el comportamiento de reintentos y el orden de eventos;
• el versionado de la API y la política de retirada de versiones;
• los datos de prueba y el realismo del entorno de pruebas;
• la posibilidad de auditar las acciones de la API;
• la disponibilidad de información de estado e incidentes.

OWASP API Security Top 10 destaca riesgos como fallos de autorización a nivel de objeto, fallos de autenticación, consumo de recursos sin restricciones, gestión inadecuada del inventario y consumo inseguro de API de terceros. El proveedor debe poder explicar cómo su diseño y controles operativos abordan los riesgos pertinentes.

Pruebe el comportamiento, no solo la documentación

Construya una pequeña prueba de concepto que compruebe:

• solicitudes de pedido duplicadas;
• webhooks retrasados y duplicados;
• tiempos de espera agotados cuando el proveedor podría haber completado ya una operación;
• estados de producto o perfil no válidos;
• reintentos y limitación de solicitudes;
• credenciales revocadas;
• rotación de claves;
• exportación de datos operativos;
• conciliación entre eventos de la API y facturas.

El objetivo no es hacer que falle el proveedor. Es averiguar si los fallos son seguros, observables y recuperables.

Criterio 7: Control de la marca, los clientes y los datos

White-label no debería significar que el proveedor se apropia silenciosamente de la relación que su empresa pagó por adquirir.

Aclare la titularidad y el control de:

• los nombres de marca y los recursos visuales;
• los dominios y las cuentas de las tiendas de aplicaciones;
• las condiciones para el cliente final;
• los registros de clientes y los consentimientos de marketing;
• las cuentas de pago y los datos de transacciones;
• las cuentas de analítica y publicidad;
• el historial de soporte;
• la configuración del producto;
• los identificadores de SIM, perfiles y pedidos;
• los contenidos y las traducciones;
• el software personalizado y los trabajos de integración.

El contrato debe indicar si el proveedor puede contactar con sus clientes, dirigirles acciones de marketing o realizar ventas cruzadas. También debe describir qué ocurre con los datos de los clientes después de la terminación.

Los roles del RGPD requieren análisis, no etiquetas

Para servicios que impliquen datos personales en el Espacio Económico Europeo, identifique si cada parte actúa como responsable, encargado, corresponsable o responsable independiente para cada actividad de tratamiento.

El artículo 28 del RGPD establece requisitos para el tratamiento por un encargado, incluidos un contrato vinculante y condiciones relativas a los subencargados. El Comité Europeo de Protección de Datos destaca que los roles de responsable y encargado derivan de las actividades reales de las partes, no solo de las palabras utilizadas en un contrato.

Solicite:

• un acuerdo de tratamiento de datos;
• una lista y la ubicación de los subencargados;
• las finalidades y categorías del tratamiento;
• las reglas de conservación y eliminación;
• los mecanismos de transferencia internacional cuando sean necesarios;
• las medidas de seguridad;
• los compromisos de notificación de incidentes;
• asistencia con las solicitudes de los interesados;
• derechos de auditoría o de obtención de garantías.

Esta sección es una lista de comprobación para compras, no asesoramiento jurídico. El acuerdo final debe revisarse teniendo en cuenta los mercados y servicios implicados.

Criterio 8: Seguridad y garantías de la cadena de suministro

El proveedor puede tratar información de clientes, emitir inventario digital valioso y controlar operaciones del ciclo de vida de las suscripciones. Por tanto, la diligencia debida en seguridad debe cubrir tanto el software como la infraestructura de telecomunicaciones.

Solicite pruebas relativas a:

• la gobernanza de seguridad de la información;
• el control de acceso y los accesos privilegiados;
• la autenticación multifactor;
• el cifrado en tránsito y en reposo cuando corresponda;
• el desarrollo seguro de software;
• la gestión de vulnerabilidades y las pruebas de penetración;
• la gestión de secretos y certificados;
• los registros y la monitorización de seguridad;
• la respuesta a incidentes;
• las copias de seguridad, la recuperación y la continuidad del negocio;
• los accesos de empleados y contratistas;
• la gestión del riesgo de proveedores y subencargados;
• la separación de datos entre socios white-label;
• la eliminación y la gestión de soportes;
• los informes de aseguramiento o certificaciones recientes y su alcance.

Para la infraestructura de gestión de suscripciones, confirme la acreditación de seguridad y las pruebas de conformidad pertinentes de GSMA con la parte que opera el componente. Para el procesamiento de pagos, determine qué sistemas entran en el alcance de PCI DSS y cómo el uso de un proveedor de pagos alojado modifica, pero no elimina automáticamente, sus propias responsabilidades.

NIST SP 800-161 Rev. 1 describe la gestión del riesgo de ciberseguridad en la cadena de suministro como un proceso continuo de identificación, evaluación y mitigación del riesgo en los productos y servicios adquiridos. Es un principio útil para las compras: evalúe toda la cadena de dependencias y revísela cuando cambien los sistemas o proveedores.

Compruebe el alcance de cada certificado

Un certificado puede aplicarse a:

• una entidad jurídica diferente;
• un centro de datos, pero no a la aplicación;
• un proveedor de la cadena de suministro, pero no a la plataforma white-label;
• un proceso limitado en lugar de a todo el servicio;
• un periodo que ya ha vencido.

Registre el titular del certificado, su alcance, norma, auditor y vigencia. No transforme «un proveedor de la cadena tiene un certificado» en «todo el servicio está certificado».

Criterio 9: Precios y rentabilidad unitaria

La tarifa mayorista más baja no implica necesariamente el menor coste total.

Construya un modelo de precios completo que incluya:

• cargos de implementación y adaptación de marca;
• suscripción a la plataforma;
• compromiso mensual mínimo;
• cargos por perfil, SIM o pedido;
• tarifas de datos, voz y SMS;
• cargos por descarga, sustitución o ciclo de vida del perfil;
• cargos por API, cuenta o revendedor;
• producción y personalización de SIM físicas;
• embalaje, preparación de pedidos y devoluciones;
• paquetes de soporte;
• costes de procesamiento de pagos;
• exposición a la conversión de divisas;
• tratamiento fiscal;
• reglas para inventario no utilizado o caducado;
• cargos por excesos, situaciones excepcionales y terminación.

Después modele varios grupos realistas, no un único cliente medio.

Por ejemplo:

• un viajero de bajo importe que visita un solo país;
• un usuario regional de alto consumo de datos;
• un cliente que necesita soporte y sustitución;
• una cuenta empresarial con numerosos dispositivos de bajo consumo;
• una SIM inactiva mantenida por resiliencia;
• un revendedor con reparto de ingresos.

Compare la misma unidad

Una propuesta puede indicar el coste de un paquete de datos. Otra puede incluir inventario de perfiles, acceso a la plataforma y soporte en la tarifa. Una tercera puede exigir un compromiso mínimo.

Convierta todas las propuestas a las mismas medidas, como:

• margen de contribución por pedido completado;
• coste por cliente o dispositivo activo;
• coste por gigabyte en cada mercado prioritario;
• coste de soporte por pedido;
• capital de trabajo necesario;
• volumen de equilibrio;
• exposición a pérdidas si las ventas quedan por debajo del plan.

Cualquier previsión sigue siendo un modelo. Exponga los supuestos y pruebe cómo cambia el resultado cuando varían el consumo, los reembolsos, el fraude, los tipos de cambio o la demanda de soporte.

Criterio 10: Facturación, informes y conciliación

Los negocios de conectividad pueden perder margen por pequeñas diferencias que se repiten en numerosas transacciones.

Pregunte cómo concilia el proveedor:

• los pedidos y la asignación de perfiles;
• la activación y el vencimiento de paquetes;
• los registros de consumo y los saldos de paquetes;
• los reembolsos y las sustituciones;
• los registros de pagos e impuestos;
• las facturas mayoristas;
• la conversión de divisas;
• las comisiones de revendedores;
• los ajustes manuales;
• el consumo de red disputado.

Solicite una factura de ejemplo, una exportación de consumo y un informe de liquidación. Compruebe que su equipo financiero puede rastrear un importe desde el resumen de factura hasta el cliente, producto, SIM o perfil y periodo de tarificación.

Pregunte también cómo se trata el consumo recibido con retraso. Los registros de consumo de telecomunicaciones no siempre aparecen de inmediato. Las reglas comerciales deben explicar si los saldos, alertas y facturas pueden ajustarse cuando lleguen registros retrasados.

Criterio 11: Soporte, incidentes y niveles de servicio

Su marca recibirá la queja aunque el fallo subyacente corresponda a una red de la cadena de suministro.

El modelo de soporte debe definir:

• qué parte presta el soporte de primer nivel;
• horarios de atención e idiomas;
• definiciones de gravedad;
• tiempos de respuesta y de actualización;
• canales de escalado;
• información necesaria en un ticket;
• acceso a especialistas técnicos;
• escalado al operador de la cadena de suministro;
• avisos de mantenimiento programado;
• comunicaciones de incidentes;
• informes de causa raíz;
• créditos de servicio u otras medidas compensatorias;
• soporte durante el lanzamiento y las grandes campañas.

Haga que el SLA sea medible

Un compromiso de disponibilidad solo tiene sentido cuando el contrato define:

• el servicio o endpoint que se mide;
• el punto de observación;
• el intervalo de medición;
• el mantenimiento excluido;
• los fallos de terceros excluidos;
• el método para notificar una interrupción;
• la compensación y el proceso de reclamación.

La disponibilidad de la plataforma, el éxito del aprovisionamiento, la capacidad de respuesta de la API y la cobertura de la red móvil son medidas diferentes. Agruparlas en una declaración vaga de «servicio del 99,9 %» oculta el riesgo en lugar de gestionarlo.

Pruebe el escalado durante el piloto

Presente casos técnicos reales y observe:

• el tiempo hasta el acuse de recibo;
• la calidad de las preguntas de diagnóstico;
• el acceso al estado del perfil y de la red;
• la claridad sobre quién asume la responsabilidad;
• la frecuencia de las actualizaciones;
• las pruebas aportadas al resolver el caso.

El comportamiento de un proveedor ante incidentes forma parte del producto.

Criterio 12: Escalabilidad y hoja de ruta

La escalabilidad no es solo el número de pedidos que puede almacenar una base de datos.

Incluye:

• capacidad de inventario de perfiles y SIM físicas;
• picos de tráfico de compra y API;
• límites de solicitudes;
• operaciones masivas;
• generación de informes;
• procesamiento de eventos de consumo;
• dotación de personal de soporte;
• capacidad de redes y proveedores;
• operaciones de liquidación y finanzas;
• jerarquía de socios y revendedores;
• expansión a otros países, monedas e idiomas.

Pida límites probados, no adjetivos como «de nivel empresarial». Describa los volúmenes normales y máximos previstos y solicite confirmación del diseño admitido.

La hoja de ruta también importa. Determine:

• qué funciones solicitadas ya existen;
• cuáles requieren configuración;
• cuáles requieren desarrollo de pago;
• cuáles solo están previstas;
• quién es titular del trabajo personalizado;
• cómo se comunican y prueban las versiones;
• cómo se gestiona la compatibilidad con versiones anteriores.

Una hoja de ruta no es un compromiso contractual salvo que se formalice como tal.

Criterio 13: Flexibilidad contractual y preparación para la salida

El mejor momento para planificar una transición de proveedor es antes de conectar al primer cliente.

Las cláusulas de salida deben abordar:

• la exportación de datos de clientes, pedidos, consumo y configuración;
• el formato, la frecuencia y el coste de las exportaciones;
• la continuidad del acceso durante un periodo de transición;
• el tratamiento de las SIM físicas y perfiles eSIM activos;
• la titularidad o portabilidad de identificadores cuando sea técnica y jurídicamente posible;
• el tratamiento del inventario no utilizado y los saldos prepagados;
• la transferencia de dominios, aplicaciones y cuentas de pago;
• la eliminación y devolución de datos;
• la asistencia para la transición;
• los plazos de preaviso y cargos por terminación;
• la vigencia posterior de las obligaciones de confidencialidad y soporte;
• la continuidad si cambia un proveedor de la cadena de suministro.

No todos los perfiles o suscripciones pueden transferirse sin más a otro proveedor. Deben comprenderse las limitaciones técnicas y contractuales antes de prometer portabilidad a los clientes.

Solicite una demostración de salida

Pida una exportación de:

• todos los clientes de ejemplo;
• productos y precios;
• pedidos y pagos;
• SIM y perfiles asignados;
• estado del ciclo de vida;
• historial de consumo y saldos;
• referencias de soporte;
• relaciones con revendedores;
• registros de administradores y auditoría.

Una exportación que genere unos pocos archivos CSV incompletos puede no permitir una migración viable.

Un proceso de selección de proveedor paso a paso

Paso 1: Defina los requisitos no negociables

Divida los requisitos en:

• obligatorios para el lanzamiento;
• necesarios dentro de un plazo definido;
• comercialmente deseables;
• innecesarios para el modelo actual.

Esto evita que una larga lista de funciones opcionales pese más que la ausencia de una capacidad fundamental.

Paso 2: Envíe la misma solicitud de información a cada proveedor

Utilice un cuestionario estructurado y exija que los ofertantes clasifiquen cada respuesta como:

• disponible actualmente en el servicio propuesto;
• disponible mediante configuración;
• disponible mediante desarrollo personalizado;
• prestado por un tercero identificado;
• previsto con una fecha comprometida;
• no disponible.

Pida que adjunten pruebas e identifiquen cualquier supuesto.

Paso 3: Cree un modelo comparable de coste total

Utilice los mismos supuestos de ventas, consumo, soporte y crecimiento para todas las propuestas. Incluya escenarios de volumen bajo y alto.

Paso 4: Realice demostraciones con un guion definido

Pruebe los recorridos del cliente, soporte, finanzas y administración. Registre las carencias pendientes y las soluciones alternativas propuestas.

Paso 5: Complete la diligencia debida técnica y de seguridad

Revise la arquitectura, el comportamiento de la API, los roles de aprovisionamiento, las pruebas de seguridad, las condiciones de privacidad, los subencargados, la continuidad y los procesos de incidentes.

Paso 6: Construya una prueba de concepto

Integre el recorrido crítico de API o white-label. No espere al proyecto de producción para descubrir cómo funcionan la gestión de errores, los webhooks o las exportaciones.

Paso 7: Realice un piloto representativo

Utilice dispositivos reales y destinos representativos. Incluya recorridos exitosos y fallos controlados.

Paso 8: Compruebe referencias

Hable con socios con un modelo de negocio, escala y geografía similares. Un proveedor que funciona bien para afiliados de viajes de poco volumen puede no estar probado para IoT empresarial, y a la inversa.

Paso 9: Alinee el contrato con el servicio probado

Asegúrese de que el contrato, el formulario de pedido, el anexo técnico, las condiciones de tratamiento de datos y el SLA reflejan lo demostrado y prometido.

Paso 10: Defina los criterios de autorización del lanzamiento

Lance solo cuando los responsables de producto, integración, soporte, finanzas, asuntos jurídicos y operaciones hayan aceptado sus respectivos criterios de preparación.

¿Qué debe probar el piloto?

Un piloto debe cubrir más que la instalación en un único teléfono de gama alta.

Registre el resultado conforme a criterios de aceptación acordados de antemano. «Funcionó la mayor parte del tiempo» no es una decisión de lanzamiento.

Una matriz ilustrativa de evaluación de 100 puntos

Las ponderaciones deben reflejar su negocio. El siguiente ejemplo es un punto de partida, no una fórmula universal.

Puntúe cada respuesta con pruebas:

• 0: no disponible o sin respuesta;
• 1: afirmado, sin pruebas prácticas;
• 2: parcialmente disponible o dependiente de trabajo manual;
• 3: disponible y demostrado;
• 4: probado en el piloto con respaldo contractual adecuado;
• 5: probado, respaldado contractualmente y superior al requisito.

Un requisito mínimo obligatorio es más importante que la puntuación total. Un proveedor no debería ganar porque los precios bajos y una marca atractiva compensen una carencia de seguridad, cobertura esencial o derechos sobre los datos de clientes.

Señales de alerta habituales

La cobertura se describe solo como un número de países

El proveedor no revela las redes permitidas, tecnologías, restricciones o controles de cambios.

Todas las capacidades están «en la hoja de ruta»

La propuesta no distingue entre funciones operativas y desarrollo previsto.

La demostración evita los estados operativos

El proveedor muestra la compra y la marca, pero no puede investigar una descarga fallida, un registro de consumo retrasado o un cargo disputado.

La API no tiene un entorno de pruebas realista

Existe documentación, pero los errores, webhooks y operaciones del ciclo de vida no pueden probarse con seguridad.

Las respuestas de seguridad se apoyan en un único certificado sin explicar

No están claros su alcance, entidad jurídica, sistemas y periodo de vigencia.

La titularidad de los clientes se describe verbalmente

El contrato permite marketing directo, limita la exportación de datos o mantiene cuentas críticas bajo control del proveedor.

Los precios no se pueden conciliar

El proveedor no puede facilitar registros de consumo de ejemplo, facturas o reglas claras para datos retrasados y ajustes.

La responsabilidad del soporte pasa de una parte a otra

El proveedor culpa a la red, pero usted no tiene acceso a ella y no se ha designado un responsable del escalado.

Faltan condiciones de terminación

No hay un plan práctico para suscripciones activas, saldos, datos, dominios o aplicaciones después de la terminación.

La presión sustituye a la diligencia debida

El proveedor se resiste a un piloto, una llamada de referencias, una revisión de seguridad o una confirmación escrita de afirmaciones importantes.

Preguntas para incluir en la solicitud final de propuesta

Empresa y cadena de suministro

1. ¿Qué entidad jurídica contratará con nosotros?
2. ¿Qué funciones críticas presta su organización y cuáles prestan terceros?
3. ¿Cómo se nos notificarán los cambios importantes de proveedores de su cadena de suministro?
4. ¿Qué medidas de continuidad del negocio existen para las dependencias críticas?

Conectividad y aprovisionamiento

5. ¿Qué redes, tecnologías y restricciones se aplican en nuestros mercados prioritarios?
6. ¿Qué arquitecturas y versiones de eSIM de GSMA se admiten?
7. ¿Quién opera los componentes pertinentes de gestión de suscripciones?
8. ¿Qué dispositivos y eUICC se han probado?
9. ¿Cómo se exponen los estados de aprovisionamiento, red y paquete?

Plataforma e integración

10. ¿Qué capacidades solicitadas existen hoy en el servicio presupuestado?
11. ¿Qué funciones de API, webhooks, exportación y entorno de pruebas se incluyen?
12. ¿Qué límites, ventanas de mantenimiento y políticas de versionado se aplican?
13. ¿Podemos conservar nuestros propios dominios, cuentas de aplicaciones, pagos y analítica?

Operaciones

14. ¿Qué cobertura de soporte y vía de escalado se aplicarán?
15. ¿Cómo se comunican los incidentes y se informa de sus causas raíz?
16. ¿Cómo se concilian los pedidos, consumos, reembolsos y facturas?
17. ¿Qué pruebas hay de los niveles de servicio y del rendimiento reciente?

Seguridad y privacidad

18. ¿Qué certificaciones o informes de aseguramiento se aplican exactamente al servicio?
19. ¿Qué subencargados y ubicaciones de datos intervienen?
20. ¿Qué acuerdos existen sobre notificación de brechas, eliminación y auditoría?
21. ¿Cómo se controlan el acceso privilegiado, la separación entre clientes de la plataforma y las credenciales API?

Condiciones comerciales y salida

22. ¿Cuáles son todos los cargos únicos, recurrentes, por consumo y excepcionales?
23. ¿Qué compromisos mínimos y reglas de indexación se aplican?
24. ¿Qué datos y configuración podemos exportar durante y después del contrato?
25. ¿Qué ocurre con las SIM, perfiles, saldos y clientes activos al finalizar el contrato?

Cómo aborda SIM24.biz la evaluación de proveedores

SIM24.biz apoya a empresas que desarrollan propuestas de conectividad SIM, eSIM e IoT con marca propia. La solución adecuada depende del cliente objetivo, los dispositivos, países, diseño del producto, profundidad de integración y responsabilidades operativas.

Por tanto, una conversación útil debe comenzar con requisitos, no con un paquete genérico. El objetivo es definir:

• la experiencia que el socio quiere controlar;
• las funciones de conectividad y aprovisionamiento necesarias;
• los sistemas que deben integrarse;
• los datos y la visibilidad operativa necesarios;
• los supuestos comerciales que deben probarse;
• el camino del piloto al lanzamiento a mayor escala.

Las redes, módulos de plataforma, API, niveles de servicio y compatibilidad con arquitecturas GSMA disponibles a través de SIM24.biz deben confirmarse para el proyecto y la combinación de proveedores seleccionados. Este artículo no afirma que todas las capacidades de la lista de evaluación estén incluidas en todos los servicios de SIM24.biz.

Esa transparencia forma parte de una selección rigurosa. Un buen proveedor debe estar dispuesto a indicar qué requisitos están disponibles, son configurables, requieren personalización, los presta un proveedor de su cadena o no se admiten actualmente.

Conclusión

Elegir un proveedor white-label de SIM y eSIM es una decisión de arquitectura empresarial, no una compra de catálogo.

El proveedor seleccionado puede respaldar durante años el recorrido del cliente, el aprovisionamiento, la conectividad, la facturación, los datos y la experiencia de soporte. Por tanto, la evaluación debe ir más allá del precio, la marca y una cifra de cobertura anunciada.

Empiece por un modelo operativo preciso. Compare propuestas equivalentes. Pida pruebas. Compruebe recorridos normales y fallidos. Realice un piloto representativo. Alinee el contrato con el servicio realmente demostrado. Defina una salida antes del lanzamiento.

El proveedor más sólido no es necesariamente el que promete todas las funciones. Es aquel cuyas capacidades, límites y responsabilidades son lo bastante claros para que su empresa opere con confianza.

Preguntas frecuentes

¿Cuál es el factor más importante al elegir un proveedor white-label de eSIM?

El encaje con el modelo operativo previsto es el factor más importante. La cobertura, la plataforma, los precios y el soporte deben evaluarse en función de sus clientes, dispositivos, países, canales y responsabilidades concretos.

¿Cómo puedo comparar la cobertura de proveedores eSIM?

Solicite las redes permitidas, las tecnologías de acceso, las restricciones y la información de enrutamiento de los países prioritarios. Después pruebe dispositivos y ubicaciones representativos. El número de países, por sí solo, no basta.

¿Necesita un proveedor white-label de eSIM su propio SM-DP+?

No necesariamente. Puede integrar de forma segura un SM-DP+ de su cadena de suministro operado por otra parte cualificada. Debe comprender quién lo opera y qué acuerdos de conformidad, soporte y contrato se aplican.

¿Qué debe ofrecer una API eSIM?

El alcance necesario depende del producto, pero suele incluir acceso al catálogo, pedidos, entrega de perfiles, estado del ciclo de vida, datos de consumo o saldo, recargas, webhooks, gestión de errores e informes. La seguridad, idempotencia, versionado y calidad del entorno de pruebas importan tanto como el número de endpoints.

¿Debo elegir al proveedor con el precio de datos más bajo?

No sin modelar el coste total. Las cuotas de plataforma, compromisos, cargos por perfiles, soporte, costes de pago, reembolsos, divisas y esfuerzo operativo pueden cambiar el resultado.

¿Cómo sé si un proveedor es seguro?

Revise la gobernanza, los controles técnicos, los procesos de incidentes, la gestión de proveedores y las garantías independientes. Verifique el alcance y la vigencia exactos de las certificaciones. Para los componentes de gestión de suscripciones eSIM, confirme las pruebas pertinentes de conformidad y seguridad de GSMA con el operador de cada componente.

¿Quién debe ser titular de la relación con el cliente final?

Es una decisión comercial, pero en un verdadero modelo white-label suele esperarse que la marca conserve la relación con el cliente. El contrato debe definir expresamente las condiciones para el cliente final, el uso de datos, el marketing directo, las cuentas de pago y el tratamiento posterior a la terminación.

¿Cuánto debe durar un piloto de proveedor eSIM?

No hay una duración universal. Debe continuar hasta probar dispositivos, mercados, volúmenes, recorridos de clientes y fallos representativos frente a los criterios de aceptación. El tiempo transcurrido por sí solo no demuestra preparación.

¿Puedo cambiar de proveedor white-label más adelante?

Sí, pero la dificultad depende de la portabilidad de datos, la titularidad de aplicaciones y dominios, las integraciones, la asistencia contractual y el tratamiento técnico de las suscripciones activas. Algunos perfiles o relaciones SIM pueden requerir sustitución en lugar de una simple transferencia.

¿Debo utilizar más de un proveedor de conectividad?

Varios proveedores pueden reducir el riesgo de concentración y ampliar la elección de productos, pero añaden trabajo de integración, monitorización, soporte y conciliación. La diversificación debe responder a un riesgo o una necesidad comercial definidos.

¿Qué debe acordarse antes de firmar?

Como mínimo, acuerde el alcance del servicio, responsabilidades, redes y productos, implementación, precios, compromisos mínimos, roles de datos, expectativas de seguridad, soporte, niveles de servicio medibles, control de cambios, portabilidad y procedimientos de terminación.

Evalúe el modelo white-label adecuado para su marca

SIM24.biz ayuda a las empresas a definir propuestas de conectividad SIM, eSIM e IoT con marca propia en torno a sus clientes, sistemas y mercados objetivo.

Hable con SIM24.biz sobre sus requisitos, el alcance del piloto y los criterios de evaluación de proveedores.

Fuentes

1. GSMA, «eSIM Compliance»: https://www.gsma.com/solutions-and-impact/technologies/esim/compliance/
2. GSMA, «SGP.22 v2.7, eSIM Consumer Technical Specification»: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-22-v2-7/
3. GSMA, «SGP.31 v1.3, eSIM IoT Architecture and Requirements»: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-31-v1-3/
4. GSMA, «SGP.32 v1.3, eSIM IoT Technical Specification»: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-32-v1-3/
5. GSMA, «SAS for Subscription Management Scope Definitions»: https://www.gsma.com/solutions-and-impact/technologies/security/wp-content/uploads/2024/02/GSMA-SAS_SM-Scope-Definitions-v2.pdf
6. GSMA, «SGP.24, RSP Compliance Process»: https://www.gsma.com/solutions-and-impact/technologies/esim/wp-content/uploads/2023/04/SGP.24-v2.5.pdf
7. Unión Europea, «Reglamento (UE) 2016/679, Reglamento General de Protección de Datos»: https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
8. Comité Europeo de Protección de Datos, «Directrices 07/2020 sobre los conceptos de responsable y encargado del tratamiento en el RGPD»: https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en
9. PCI Security Standards Council, «Document Library, incluido PCI DSS v4.0.1»: https://www.pcisecuritystandards.org/document_library/
10. NIST, «SP 800-161 Rev. 1 Update 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations»: https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final
11. OWASP Foundation, «OWASP API Security Top 10, 2023»: https://owasp.org/API-Security/editions/2023/en/0x11-t10/