El término no tiene ninguna especificación detrás. Las definiciones en circulación provienen de firmas de analistas y de proveedores, como parte de categorías de mercado que ellos mantienen. Varios de esos glosarios no son de acceso público.
¿Qué nombra realmente la etiqueta?
Un trabajo concreto que de otro modo harías tú mismo.
Sin un proveedor, enviar SMS a escala implica cuatro tareas:
- Contratos y conexiones con operadores en cada mercado.
- Suministro de números y su papeleo de registro.
- Reglas por país sobre qué se puede enviar y quién puede hacerlo.
- Las operaciones que mantienen la entrega funcionando.
Con un proveedor, es una solicitud HTTP.
La misma estructura se repite por canal. WhatsApp y RCS tienen dueños de plataforma en lugar de operadores, así que el trabajo se convierte en aprobaciones, revisión de plantillas y verificación de negocio. La situación es idéntica: alguien mantiene la relación y la expone como API.
¿Cómo evalúo uno?
Por lo que absorbe, ya que API es la parte fácil.
Cinco preguntas, cada una con una respuesta verificable:
- ¿De dónde viene el número y quién lo registra? Comprar un número es fácil. Conseguir que esté aprobado para enviar en un país determinado es el trabajo real. Un proveedor que te devuelve eso te deja la parte difícil.
- ¿Qué pasa cuando un canal cambia sus reglas? Las políticas de canal cambian. O el proveedor absorbe el cambio, o te llega como incidente.
- ¿Es útil el detalle del fallo? Un fallo de entrega reportado solo como fallido no permite actuar. Uno que indica la causa sí. La página de filtrado de SMS de Bird describe qué reportan y qué no reportan los operadores.
- ¿La interfaz está documentada como contrato? Una especificación OpenAPI publicada es un compromiso diferente al de un sitio de documentación.
- ¿Los precios por país son visibles antes de comprometerte? El precio de los mensajes varía según el destino. Tarifas que no puedes ver hasta ser cliente no se pueden comparar con las de nadie más.
¿CPaaS es lo mismo que omnicanal?
No. Responden preguntas diferentes. Un producto puede cumplir una sin cumplir la otra.
CPaaS trata de quién gestiona las telecomunicaciones. Omnicanal trata de si tus canales comparten estado. Un proveedor puede exponer seis canales a través de API mientras cada uno mantiene su propia lista de contactos y su propio registro de consentimiento. Eso cumple lo primero pero no lo segundo. Omnicanal vs multicanal explica cómo verificar la segunda afirmación.
Los acrónimos vecinos, CCaaS y UCaaS, nombran productos de centro de contacto y de comunicaciones internas, no APIs para desarrolladores. Comparten el sufijo como servicio y poco más.
¿Cuál es la postura de Bird?
En contra del modelo de precios, no de la capacidad.
Bird publica esa postura bajo el título "The end of CPaaS". La afirmación en el contenido es más acotada que el título. El argumento de Bird es que la mensajería se ha convertido en commodity y sus márgenes tienden a cero. Lo que termina, según ese argumento, es la práctica de precios que depende de que los compradores no puedan comparar tarifas entre países y operadores. El argumento no dice que la capacidad vaya a desaparecer.
Ese argumento tiene una forma verificable: si las tarifas por país de un proveedor son visibles antes de firmar. Las tarifas de Bird se publican por país en las páginas de precios, no se cotizan bajo solicitud.
En resumen
Es una etiqueta de mercado, no una especificación.
Ningún organismo de estándares lo define, así que los límites de la categoría los traza quien la describe.
Lo que nombra es bastante real.
Llegar a redes de operadores y plataformas a través de HTTP API, sin contratos, conexiones ni infraestructura de cumplimiento propios.
Lo que importa es lo que el proveedor absorbe.
Rutas, suministro de números, registro de remitentes y reglas de canal son el trabajo real. API que te deja todo eso no elimina gran cosa.
Bird sostiene que el modelo de precios detrás de la categoría está llegando a su fin.
No la capacidad. La afirmación se refiere a los márgenes de la mensajería convertida en commodity. Es una postura, no una definición.