A maioria das RFPs de plataformas de IoT fracassa antes mesmo de o fornecedor lê-las. Não porque o comprador não sabe o que quer, mas porque o documento faz as perguntas erradas. RFPs genéricas recebem respostas genéricas. Você acaba comparando material de marketing dos fornecedores em vez das capacidades reais.
Veja o que perguntar no lugar.
Por que a maioria das RFPs de IoT erra o alvo
A RFP de IoT típica foca em funcionalidades. A plataforma suporta MQTT? Tem dashboards? Consegue enviar alertas? Toda plataforma vai responder sim a todas essas perguntas.
As perguntas que realmente importam são mais difíceis de responder: o que acontece com os meus dados quando eu precisar sair? Como fica o preço com 5.000 dispositivos? Meu cliente consegue acessar um portal com a minha marca sem ver o nome da sua empresa?
Três padrões de falha aparecem em RFPs de IoT fracas:
- Genéricas demais. Perguntas que qualquer fornecedor responde de forma afirmativa sem revelar nada de útil.
- Sem uma visão de custo total de propriedade. Avaliar as mensalidades da plataforma sem considerar o tempo de onboarding de dispositivos, os custos de suporte e a carga de engenharia.
- Falta de perguntas operacionais. O que funciona em uma demo pode não funcionar em condições reais de produção. A maioria das RFPs não testa isso.
As cinco categorias abaixo resolvem os três problemas.
Categoria 1: Conectividade
É aqui que a maioria das plataformas se diferencia rápido. Pergunte:
- Quais protocolos são suportados nativamente? LoRaWAN, MQTT, HTTP, NB-IoT, satélite?
- Vocês suportam os principais network servers LoRaWAN (TTN, ChirpStack, Actility)?
- Quantos parsers de dispositivo prontos vocês oferecem? Posso criar o meu próprio?
- O que acontece se o meu dispositivo usa um formato de payload customizado?
- Existe uma lista de integrações de hardware oficialmente suportadas?
Uma plataforma que afirma ter “amplo suporte a conectividade” não significa nada. Peça a lista específica. Se um fornecedor suporta mais de 500 tipos de dispositivo já de cara, essa é uma resposta concreta e verificável.
Categoria 2: Dados
A portabilidade dos dados costuma ser ignorada até que alguém precise trocar de plataforma ou fazer uma auditoria. Pergunte:
- Onde os dados ficam armazenados? Em quais regiões geográficas?
- Qual é o período padrão de retenção de dados? Posso estendê-lo?
- Como eu exporto os meus dados? Existe uma API de exportação em massa?
- O payload bruto é armazenado ou apenas os valores já interpretados?
- O que acontece com os meus dados se eu cancelar a assinatura?
Essas perguntas revelam se um fornecedor trata os seus dados como seus ou como dele. Se as respostas forem vagas, isso é um sinal.
Categoria 3: Escalabilidade
A pergunta certa não é “vocês escalam?”. É “o que escalar custa e exige na prática?”.
- Qual é o modelo de preço com 100 dispositivos, 1.000 dispositivos e 10.000 dispositivos?
- Existem limites de pontos de dados por mês ou de chamadas de API por segundo?
- Como a plataforma lida com um pico de mensagens de dispositivos?
- Existe um ambiente dedicado para cada cliente ou é compartilhado?
- Onde encontro a documentação de preços?
Procure plataformas que publicam o preço de forma aberta. Preços transparentes em https://tago.io/pricing são uma boa referência de como isso funciona na prática.
Categoria 4: White-label
Se você é um integrador de sistemas ou está construindo um produto para clientes, o white-label não é opcional. Pergunte:
- Posso colocar no ar um portal voltado ao cliente sob o meu próprio domínio?
- O aplicativo móvel de vocês suporta marca customizada? Está disponível para iOS e Android?
- Meus clientes vão chegar a ver o nome ou o logo da sua empresa em algum momento?
- O white-label está incluído no plano base ou é um adicional pago?
- Posso controlar o que cada usuário final consegue ver e fazer?
Uma plataforma que não consegue entregar aos clientes uma experiência com a sua marca significa que você está construindo o seu produto em cima da marca de outra empresa. Esse é um risco que vale quantificar antes de assinar.
Categoria 5: Suporte
A qualidade do suporte é impossível de avaliar a partir de páginas de marketing. Peça detalhes concretos:
- Qual é o SLA para incidentes críticos?
- Qual é o tempo médio de resposta para chamados de suporte?
- Existe um site de documentação público e uma comunidade de desenvolvedores?
- Vocês oferecem assistência de onboarding para novas contas?
- Há recursos de treinamento disponíveis (academy, tutoriais em vídeo)?
Verifique se o fornecedor tem uma base de conhecimento pública e um fórum de comunidade. Recursos como https://docs.tago.io e https://tago.io/academy dão uma ideia de quão a sério um fornecedor investe em suporte self-service.
Transformando isso em um documento de trabalho
Essas cinco categorias dão a você a estrutura. O próximo passo é transformá-las em uma matriz de avaliação com pontuação: atribua pesos a cada categoria conforme as prioridades do seu projeto e depois pontue as respostas de cada fornecedor de 1 a 5. Isso tira o achismo da decisão.
Uma versão completa para download deste modelo de RFP está disponível sob solicitação. Entre em contato em https://tago.io/contact-us e inclua “RFP template” na sua mensagem.
Próximos passos
- Conheça as capacidades da plataforma: https://docs.tago.io
- Explore casos de uso reais: https://tago.io/use-cases
- Fale com a equipe: https://tago.io/contact-us
