Índice do artigofaltam 4 min de leitura
A Microcity aluga e gerencia computadores e equipamentos de informática para outras empresas. Cada contrato promete um nível de serviço, como o prazo de atendimento, e o cliente dependia do relatório que chegava por e-mail para saber se a promessa era cumprida. A Microcity quis levar os números do nível de serviço a um lugar que o cliente abrisse quando quisesse, no navegador ou no celular.
Antes do contrato com a X-Apps, que construiu o portal e os aplicativos, a Microcity apresentou formalmente discordâncias técnicas sobre a forma de fazer os aplicativos: um aplicativo só, que roda no iPhone e no Android, em vez de dois separados. Quem contrata pode assinar com a dúvida aberta. No caso da Microcity, a resposta veio antes do contrato.
Dúvida da equipe técnica é motivo para desistir?
Não é motivo para desistir, e também não é motivo para passar por cima da equipe. Quem já contratou software conhece o impasse. A sua equipe técnica diz que tem dúvidas sobre a proposta, o vendedor do fornecedor diz que está tudo certo, e quem assina fica no meio, sem conhecimento para julgar quem tem razão e com a tentação de escolher um lado pela confiança que tem nas pessoas.
A discordância em si é um bom sinal: alguém leu a proposta com atenção e enxergou um risco. O que preocupa é a dúvida que fica no corredor, que ninguém escreve, e a resposta que o fornecedor deixa para depois da assinatura. Quando a dúvida só é dita em reunião, ela costuma ser esquecida ou reaparecer no meio do projeto, quando mudar de caminho já custa caro. No papel, o fornecedor tem de responder, e você consegue ler a resposta mesmo sem ser técnico.
A Microcity formalizou a discordância antes do contrato
A X-Apps respondeu às discordâncias da Microcity antes do contrato. Os aplicativos foram feitos sobre uma mesma base e estão publicados nas duas lojas. A página do case não detalha cada discordância nem cada resposta. O que ela conta é a sequência: primeiro a discordância formal, depois a resposta, depois o contrato e a construção.
Depois da resposta, a X-Apps desenhou e construiu o portal que o cliente da Microcity acessa, o painel de administração da Microcity e os aplicativos, publicados nas lojas da Apple e do Google. O cliente entra com o usuário e a senha que já usa na empresa, e os números que ele vê são os mesmos que a Microcity usa por dentro, sem passar pela mão de ninguém. O relatório que antes chegava por e-mail agora sai na hora: o cliente escolhe o contrato, o período e o que quer ver. Segundo o case, os pedidos manuais de relatório caíram 84%.
A página do case traz também uma fala do gerente de sistemas da Microcity sobre uma proposta técnica que a X-Apps fez no projeto e que a Microcity aprovou. A página não diz qual era a proposta nem em que momento ela foi feita.
A X-Apps propôs uma alternativa técnica que consideramos excelente para tornar o projeto mais seguro e melhorar seu desempenho. Aprovamos a sugestão prontamente e reconhecemos a contribuição da equipe para uma solução mais robusta e confiável.
O que mudou para o cliente da Microcity
Para o cliente da Microcity, mudou o jeito de saber se o que foi prometido no contrato está sendo cumprido. Segundo o case da Microcity, 86% das consultas ao nível de serviço são feitas pelo próprio cliente, sem pedir a ninguém.
Antes
Relatório por e-mail- Espera o relatório chegar
- Vê um número que passou pela mão de alguém
- Pede o relatório a alguém
Hoje
Portal a qualquer hora- Abre quando quer, no navegador ou no celular
- Vê o mesmo número que a Microcity usa
- Gera o relatório na hora, em PDF ou planilha
Vale o mesmo na hora de contratar quem vai construir o sistema: resposta no papel fica guardada, e qualquer pessoa pode reler depois.
Como transformar a dúvida da sua equipe em resposta
Da Microcity, a página conta só a ordem: discordância formal, resposta antes do contrato. O modo de fazer que segue é recomendação da X-Apps, e você não precisa entender a parte técnica para usá-lo. O primeiro passo é pedir à equipe que escreva cada discordância em uma frase, junto com o que ela teme que aconteça. A frase boa diz o que pode dar errado e para quem, de um jeito que você consiga repetir para o seu sócio. Um molde que serve: "discordamos de tal ponto da proposta porque, se acontecer tal coisa, o resultado é este, e quem sente é este grupo de pessoas". Se a equipe não conseguir explicar o que pode dar errado, converse com ela mais uma vez antes de procurar o fornecedor.
Com as frases prontas, mande o documento ao fornecedor antes de assinar e peça a resposta também por escrito. Se ele insistir em deixar tudo para depois do contrato, leve isso em conta na decisão: depois da assinatura, mudar de caminho custa mais caro. Quando a resposta chegar, guarde pergunta e resposta junto do contrato e peça que entrem como anexo dele. Assim elas ficam registradas como parte do que foi combinado e ajudam quem entrar no projeto mais tarde a entender por que ele foi feito daquele jeito.
Por fim, leia a resposta mesmo sem ser técnico. Veja primeiro se ela trata do ponto que a equipe levantou e se explica o motivo da escolha. Veja depois se diz o que muda na proposta quando a equipe tem razão e o que se perde quando nada muda. Em seguida, devolva a resposta à equipe e pergunte, ponto por ponto, se ela ficou satisfeita. Se sobrar discordância, peça que a equipe escreva o que faltou e mande de novo ao fornecedor. Se ainda assim um ponto ficar sem acordo, a decisão volta a ser sua, mas agora você sabe qual é o risco, quem o apontou e o que o fornecedor respondeu.
Discordância técnica respondida por escrito antes do contrato protege os dois lados, porque cada um sabe o que foi decidido e por quê.
Fonte: página do case Portal do Cliente da Microcity, da X-Apps. Leitura em 14/11/2026.





