Business

O que incluir em um SLA ao revender uma plataforma IoT

O que um SLA de revenda realmente precisa: a regra do repasse, uma definição de disponibilidade que se sustenta, durabilidade separada de disponibilidade, níveis de suporte que você consegue cumprir, condições de saída e modelos de cláusula para levar ao seu jurídico.

David Hall ·
O que incluir em um SLA ao revender uma plataforma IoT

Quando você revende uma plataforma IoT com a sua marca, o cliente assina o acordo de nível de serviço com você e com mais ninguém. Sua logo está nos dashboards, seu nome está na nota fiscal e o seu telefone toca quando os dados param de chegar às 2 da manhã. Mas quem opera a infraestrutura não é você, e esse único fato cria a regra que toda cláusula do seu SLA precisa respeitar: você não pode prometer ao cliente mais do que a plataforma promete a você.

Todo compromisso que você coloca no papel está ou coberto por um compromisso do fornecedor ou absorvido por você como risco não precificado. A maioria dos SLAs de revenda falha porque foi copiada de modelos escritos para empresas que são donas dos próprios servidores. O seu tem de ser construído no sentido contrário, partindo do documento que o seu fornecedor entrega.

SLAs espelhados: o SLA da plataforma acima, a lacuna de risco que é sua e precisa ser precificada, e o seu SLA com o cliente abaixo

O problema do repasse

Coloque o SLA do fornecedor na mesa antes de escrever uma linha do seu. Se a plataforma se compromete com 99,9 por cento de disponibilidade e você promete 99,95 ao cliente, você assumiu pessoalmente a diferença: cerca de 21 minutos de exposição por mês, sem infraestrutura para consertar e sem nenhum crédito do fornecedor chegando quando falha.

Assumir essa lacuna de propósito, com ela precificada na sua mensalidade, pode ser uma decisão comercial legítima, e como você precifica o serviço gerenciado é onde essa decisão se resolve. Assumir porque ninguém fez a subtração é como revendedores acabam pagando créditos de serviço com a própria margem.

É também por isso que o SLA do próprio fornecedor entra na sua lista de critérios de escolha de plataforma. A TagoIO publica seu SLA em tago.io/sla e tem certificação ISO 27001, o que dá ao revendedor uma base auditada para construir em cima, em vez de uma garantia verbal. Se você ainda está escolhendo em que construir, as plataformas que integradores de fato revendem são as que publicam seus números.

Defina disponibilidade antes de prometê-la

Um percentual de disponibilidade sem definição é enfeite. Três parâmetros dão sentido a ele.

A janela de medição vem primeiro. 99,9 por cento medido por mês permite cerca de 43 minutos de indisponibilidade mensal, enquanto o mesmo número medido por ano deixa uma única queda brutal de oito horas desaparecer em onze meses tranquilos. A janela honesta é a mensal.

Segundo, o que conta como fora do ar: só a queda total, ou também o serviço degradado? Se a API responde em 30 segundos em vez de 300 milissegundos, o seu cliente vive uma indisponibilidade, admita sua definição ou não.

Terceiro, quem mede e como isso é comunicado. Um compromisso que o cliente não consegue verificar gera disputa, então nomeie a fonte de monitoramento e comprometa-se a comunicar incidentes em vez de esperar ser perguntado. Detecção independente é também o que permite lidar com a indisponibilidade da plataforma como provedor de serviço gerenciado em vez de descobrir pelo próprio cliente.

Durabilidade de dados não é disponibilidade

Esses dois vivem sendo confundidos e são promessas diferentes, com riscos diferentes. Disponibilidade é se o serviço responde agora. Durabilidade é se os dados sobrevivem.

Uma plataforma pode ficar uma hora fora do ar e não perder nada, e o seu cliente recebe um pedido de desculpas e um crédito. Dado perdido é outra categoria de falha, muitas vezes irrecuperável e às vezes uma violação de compliance.

Seu SLA precisa ter texto separado para cada um: um percentual de disponibilidade com as definições acima e uma cláusula de durabilidade cobrindo prazo de retenção, frequência de backup e o que acontece com os dados que ficam em buffer durante uma queda. Faça a pergunta do buffer diretamente ao fornecedor, porque o comportamento da ingestão durante a indisponibilidade é onde a durabilidade silenciosamente vira um problema de disponibilidade.

Níveis de suporte: comprometa-se com resposta, mire a resolução

Tempo de resposta é a rapidez com que alguém qualificado entra no caso. Isso você controla com dimensionamento de equipe, então assuma o compromisso com firmeza. Tempo de resolução depende de onde está a falha, e quando ela está na plataforma, o conserto acontece em uma infraestrutura que você não opera. Mantenha a resolução como meta declarada.

Amarre os dois à severidade. Um incidente de Severidade 1, serviço fora do ar para todos os usuários, pode ter resposta em uma hora, a qualquer hora do dia, e meta de restabelecimento em quatro horas. Severidade 2, degradado mas funcionando, ganha resposta em quatro horas úteis. Severidade 3 cobre dúvidas e defeitos menores, em um dia útil.

Defina números que sua equipe consiga cumprir em uma semana ruim, porque um compromisso descumprido todo mês custa mais confiança do que um compromisso nunca assumido. Colocar os limites no papel é também o que torna o suporte sustentável quando você passa de dez clientes.

Janelas de manutenção e condições de saída

Manutenção planejada e avisada com antecedência fica fora do cálculo de disponibilidade, e as suas janelas anunciadas precisam caber dentro das janelas do fornecedor, para que a manutenção dele nunca conte contra você. Comprometa-se com 72 horas de aviso ou mais.

Condições de saída são as cláusulas de que os compradores se lembram. Declare que o cliente pode exportar os dados em formato documentado e legível por máquina durante o contrato e no encerramento, defina o prazo e defina o custo, de preferência zero. Em uma plataforma com APIs completas essa cláusula custa quase nada para honrar, e ela ganha negociações contra concorrentes cujo silêncio sobre a saída já diz tudo. Ignorar o custo de saída até a hora de sair é um dos erros mais caros que integradores cometem, e a mesma pergunta está no centro do aprisionamento a fornecedor.

Modelos de cláusula que você pode adaptar

Estes são padrões de redação para entregar ao seu jurídico, não orientação legal. Algumas formas que funcionam:

“Percentual Mensal de Disponibilidade significa o total de minutos do mês civil, menos os minutos de Indisponibilidade, dividido pelo total de minutos do mês. Manutenção Programada avisada com pelo menos 72 horas de antecedência está excluída da Indisponibilidade.”

“Incidentes de Severidade 1 recebem resposta de um engenheiro qualificado em até uma hora do registro, 24 horas por dia, sete dias por semana. Metas de restabelecimento são objetivos, não garantias.”

“Os dados do Cliente permanecem de propriedade do Cliente. Em até 30 dias do encerramento, o Fornecedor disponibilizará todos os dados do Cliente para exportação em formato documentado e legível por máquina, sem custo adicional.”

“Créditos de serviço são calculados como percentual da mensalidade, limitados a 100 por cento de uma mensalidade, e constituem o único remédio para falhas de disponibilidade.”

Monte espelhado

O método é mecânico. Coloque o SLA do fornecedor e o seu rascunho lado a lado e, para cada cláusula sua, escreva o nome da cláusula do fornecedor que a sustenta ou a margem que a precifica. O que não tiver nenhuma das duas é doação para o seu cliente.

Revise esse pareamento a cada ano, porque as condições do fornecedor, o seu quadro de pessoal e o tamanho da sua frota todos mudam. É também o documento que muda quando você sai de projetos pontuais para serviços recorrentes, já que uma assinatura é uma promessa que se renova todo mês.

A distância entre o que você recebe e o que você promete nunca desaparece. Um bom SLA a encurta, a precifica e coloca o seu nome apenas no que você controla. Comece de uma base publicada: o SLA da TagoIO está em tago.io/sla. Agende uma demonstração ou comece grátis.