Quase toda avaliação de plataforma segue o mesmo roteiro. Uma planilha com uma linha por recurso, uma linha por limite, uma linha para o preço e, perto do fim, uma linha chamada “suporte” com valores como “e-mail” ou “24/7” copiados da tabela de planos. Recursos e preço merecem essa atenção, e as perguntas do guia de compra dão conta disso.
O suporte fica com uma linha só porque ninguém sabe avaliá-lo de fora, e durante o trial nada quebrou ainda.
Depois os dispositivos vão para campo. Oito meses depois, uma atualização de firmware no gateway muda o formato do payload e 300 sensores começam a gravar lixo às 2 da manhã de um sábado. Nesse momento a lista de recursos não vale nada. O que você compra ali é quem responde, em quanto tempo, e se essa pessoa entende a camada de dispositivo ou só a plataforma. O suporte que você recebe nessa hora foi definido por coisas que a página de preços nunca mostrou: quem atende a fila, o que “resposta” quer dizer em cada nível de severidade, e se você consegue se resolver sozinho quando ninguém está acordado.
Este post é sobre descobrir essas coisas durante o trial, enquanto você ainda tem tempo e pode escolher.
Quem responde, e o que essa pessoa sabe
“Suporte 24/7” descreve uma escala de horário, não uma capacidade. A pergunta que importa é o que a pessoa que lê o seu ticket sabe. A distância entre um nível de triagem, que classifica tickets e pede screenshots, e um engenheiro que já construiu sobre a plataforma e sabe ler o seu código de Payload Parser é enorme.
O teste: durante o trial, abra um ticket de verdade com um problema técnico de verdade. Uma dúvida de decodificação serve bem. Mande o payload cru, o seu código de parser e a saída errada. Depois observe. Uma primeira resposta que pergunta qual navegador você usa diz uma coisa. Uma primeira resposta que aponta o erro de offset de byte diz outra. Meça os dois tempos, o da primeira resposta e o de uma resposta útil. São números diferentes, e é com o segundo que você vai conviver.
Pergunte direto se o suporte é feito pelos engenheiros do próprio fornecedor ou por um nível terceirizado, e se quem responde tem acesso a quem escreve a plataforma. Você quer um sim na segunda pergunta, mesmo que a primeira venha com ressalvas.
Compromissos de resposta por severidade, por escrito
A maioria das tabelas de planos lista um único tempo de resposta, ou nenhum. Incidentes não têm todos o mesmo tamanho. Um Widget de dashboard que renderiza errado não é a mesma coisa que a ingestão de dados falhando para todos os dispositivos na planta de um cliente, e um modelo de suporte que trata os dois igual está prometendo demais no caso pequeno ou entregando de menos no caso grande.
O que você quer é uma escala de severidade: a definição de cada nível, o compromisso de resposta de cada um, o horário em que ele vale e o canal que você usa. Peça o caminho de escalação por escrito: quem entra quando quem atendeu primeiro empaca, e como você dispara isso. Um fornecedor que não sabe descrever a escalação não tem escalação, tem uma fila.
Não aceite “normalmente respondemos em uma hora”. Normalmente não é compromisso, e o incidente que custa um cliente é, por definição, fora do normal.
Ajuda com a plataforma e ajuda com o dispositivo
É aqui que a maior parte do suporte em IoT decepciona. O fornecedor da plataforma dá suporte à plataforma. O seu problema está no dispositivo: um uplink LoRaWAN em uma porta inesperada, um mapa de registradores Modbus deslocado em uma posição, um decodificador que funcionava no firmware 2.1 e quebra no 2.3. Os fornecedores traçam a linha do suporte na fronteira da API, e tudo abaixo dela vira “problema do fabricante do seu dispositivo”.
Descubra onde essa linha está antes de precisar dela. Na TagoIO, a camada de dispositivo faz parte do produto: Connectors e Networks decodificam payloads de modelos de sensores publicados, e o Payload Parser é o lugar próprio para corrigir a decodificação, então uma dúvida de decodificação está dentro do escopo, e não fora. Qualquer que seja a plataforma que você avalie, faça a pergunta sem rodeios: “Se o meu parser gera valores errados, vocês vão olhar o parser?”
Você consegue se resolver sozinho à meia-noite
Ticket de suporte é o caminho lento. O caminho rápido é a documentação (a TagoIO publica a dela em docs.tago.io), e a qualidade dessa documentação decide quantos tickets você vai precisar abrir. Durante o trial, pule o guia de primeiros passos. Leia a documentação do seu caso de uso exato: o tipo de Action que você pretende usar, o gatilho de Analysis de que você precisa, o formato de política de Access Management para os seus clientes. Se a documentação responde à pergunta que você realmente tem, com um exemplo que funciona, você vai passar a maioria das noites sem abrir ticket.
Mais verificações de autoatendimento:
- Uma página de status pública com histórico. Um ponto verde não basta; você quer o registro dos incidentes passados, como foram comunicados e quanto tempo duraram. A TagoIO mantém a dela em status.tago.io.
- Uma comunidade em que outros integradores respondem. A da TagoIO fica em community.tago.io. Leia as perguntas sem resposta com a mesma atenção que as respondidas; a proporção mostra o quanto ela está viva.
O que acontece quando você revende
Se você é um integrador de sistemas colocando os seus próprios clientes em um portal TagoRUN, a questão do suporte dobra. Os seus clientes ligam para você, não para a plataforma. Você é o primeiro nível de atendimento, tenha planejado isso ou não, e o fornecedor da plataforma é o seu segundo nível. Isso muda o que você precisa dele.
Pergunte: posso abrir um ticket sobre o problema de um cliente e ele é tratado como meu? Os Profiles que eu opero para clientes têm o mesmo peso de suporte que os meus? Quando eu prometo um tempo de resposta ao meu cliente, que tempo de resposta eu recebo de vocês para sustentar essa promessa? A diferença entre esses dois números é o seu risco, e boa vontade não fecha essa conta. O post sobre o que incluir em um SLA ao revender uma plataforma IoT mostra como estruturar a promessa. Aqui o ponto é conseguir o número de cima antes de escrever o de baixo.
Confirme o que o seu plano inclui de fato
Os níveis de suporte costumam seguir os níveis de plano, e o trial roda no nível que o fornecedor escolheu para trials. Antes de assinar, diga qual plano você vai comprar de verdade e pergunte, por escrito, que suporte vem com ele: canais, horários, compromissos por severidade e se existe escalação nesse nível ou só acima dele. No caso da TagoIO, os termos atuais estão na página de preços e na documentação de planos de conta; leia a versão que está no ar quando você assinar, não um resumo de uma ligação de vendas.
O que testar durante o trial
Faça isso durante a avaliação, não depois:
- Abra um ticket de verdade com um problema real de Payload Parser. Registre o tempo até a primeira resposta e o tempo até uma resposta útil.
- Leia a documentação do seu caso de uso exato, não o tutorial. Anote o que falta.
- Leia o histórico da página de status do último ano.
- Busque na comunidade o modelo do seu dispositivo e os recursos dos quais você pretende depender.
- Peça as definições de severidade e o caminho de escalação por escrito.
- Pergunte o que o plano que você vai comprar inclui, e se o nível do trial era o mesmo.
- Se você revende, pergunte como funcionam os tickets sobre problemas dos seus clientes e que tempo de resposta você pode repassar.
Dois dias desse trabalho dizem mais sobre os próximos três anos do que qualquer comparação de recursos. A plataforma que ganha na planilha e perde no ticket das 2 da manhã é a plataforma cara, não importa o que diga a linha do preço.
