O termo não tem especificação por trás dele. As definições em circulação vêm de empresas de análise de mercado e de fornecedores, como parte de categorias de mercado que eles mantêm. Vários desses glossários não são publicamente acessíveis.
O que o rótulo realmente nomeia?
Um trabalho específico que você teria que fazer por conta própria.
Sem um provedor, enviar SMS em escala são quatro trabalhos:
- Contratos e conexões com operadoras em cada mercado.
- Fornecimento de números e a burocracia de registro.
- Regras por país sobre o que pode ser enviado e por quem.
- As operações que mantêm a entrega funcionando.
Com um provedor, é uma solicitação HTTP.
O mesmo formato se repete por canal. WhatsApp e RCS têm donos de plataforma em vez de operadoras, então o trabalho passa a ser aprovações, revisão de templates e verificação de empresa. A posição é idêntica: alguém mantém o relacionamento e o expõe como API.
Como avaliar um?
Pelo que ele absorve, já que API é a parte fácil.
Cinco perguntas, cada uma com uma resposta verificável:
- De onde vem o número e quem o registra? Comprar um número é fácil. Conseguir aprovação para enviar em um determinado país é o trabalho. Um provedor que devolve isso a você deixa a parte difícil com você.
- O que acontece quando um canal muda suas regras? Políticas de canal mudam. Ou o provedor absorve a mudança, ou ela chega como um incidente seu.
- O detalhe da falha é útil? Uma falha de entrega reportada apenas como falhou não permite ação. Uma que identifica a causa permite. A página de filtragem de SMS de Bird descreve o que as operadoras reportam e o que não reportam.
- A interface é documentada como um contrato? Uma especificação OpenAPI publicada é um compromisso diferente de um site de documentação.
- Os preços por país são visíveis antes de você se comprometer? O preço das mensagens varia por destino. Tarifas que você não consegue ver até ser cliente não podem ser comparadas com as de ninguém.
CPaaS é o mesmo que omnichannel?
Não. Eles respondem a perguntas diferentes. Um produto pode atender a um sem atender ao outro.
CPaaS é sobre quem opera a telecomunicação. Omnichannel é sobre se seus canais compartilham estado. Um provedor pode expor seis canais por meio de API enquanto cada um mantém sua própria lista de contatos e seu próprio registro de consentimento. Isso atende ao primeiro e não ao segundo. Omnichannel vs multicanal aborda como testar a segunda afirmação.
As siglas vizinhas, CCaaS e UCaaS, nomeiam produtos de contact center e de comunicações internas, não APIs para desenvolvedores. Elas compartilham o sufixo como serviço e pouco mais.
Qual é a posição de Bird sobre isso?
Contra o modelo de preços, não contra a capacidade.
Bird publica essa posição com o título "The end of CPaaS". A afirmação por trás é mais restrita que o título. O argumento de Bird é que as mensagens se comoditizaram e suas margens estão caminhando para zero. O que acaba, segundo esse argumento, é a prática de preços que depende de os compradores não conseguirem comparar tarifas entre países e operadoras. O argumento não diz que a capacidade vai desaparecer.
Esse argumento tem uma forma verificável: se as tarifas por país de um provedor são visíveis antes de você assinar. As tarifas de Bird são publicadas por país nas páginas de preços, não cotadas sob consulta.
Em resumo
É um rótulo de mercado, não uma especificação.
Nenhum órgão de padronização o define, então o limite da categoria é traçado por quem a descreve.
O que o termo nomeia é real o suficiente.
Alcançar redes de operadoras e plataformas por meio de HTTP API, sem contratos, conexões ou estrutura de conformidade próprios.
O que importa é o que o provedor absorve.
Rotas, fornecimento de números, registro de remetente e regras de canal são o trabalho. API que deixa isso com você não removeu muita coisa.
Bird argumenta que o modelo de preços por trás da categoria está acabando.
Não a capacidade. A afirmação é sobre margens em mensagens comoditizadas. É uma posição, não uma definição.