O Holmes não é um produto vertical. Isso significa que não há um único segmento, uma única proposta de valor com escopo bem definido, um único nicho. Justamente por este motivo ele é parametrizável (que tende a ser customizável?). Nestes casos, a complexidade envolvida em encontrar a funcionalidade ideal para o usuário final é bem grande. Afinal de contas quem é o usuário final? O que envia impostos para o cliente? O que lida com documentos de semi-novos? O que digitaliza Notas Fiscais nas obras? O que aprova pagamento a fornecedores? O que pesquisa os carros pelas placas? O que envia documentos para os clientes? O que cadastra documentos o dia inteiro? O que faz consultas para encontrar documentos para auditoria? O que pesquisa por Notas Fiscais? O que consulta documentos para fazer lançamentos contábeis? Compare isso com o Uber cujo objetivo é chamar taxi, ou com o Airbnb que o objetivo é alugar imóveis. O Holmes está mais para um CRM como o Dynamics, onde a consultoria ou um usuário administrador o deixa com “a cara da empresa”, do que para estes produtos B2C focado e com propostas de valor muito bem definidas. Isso não é ruim, é apenas um fato! Afinal de contas qual o tamanho empresas como a SAP, Totvs e até mesmo Microsoft? Talvez pudéssemos compreender melhor o caminho a seguir se empresas como estas fossem nosso principal Benchmark.
Já tivemos solicitações de clientes para ocultar este ou aquele botão, mas o Holmes hoje ainda não permite isso. Pois, adivinhe, quais funcionalidades devem estar ou não disponíveis para o usuário? Depende do processo! E os processos, entre as variadas empresas e seguimentos, podem ser bem diferentes embora o objetivo seja o mesmo.
Porém, mesmo diante deste universo enorme de possibilidades ainda, é possível classificar os usuários em três grandes categorias:
1. Usuário final
2. Implantação (admin)
3. Suporte
Para cada um deles um princípio de Design é mais adequado. Respectivamente:
1. Simplicidade
2. Flexibilidade e
3. Diagnóstico
++ Talvez caiba um desenho aqui. Com ligar um e outro ++
Como empresa desenvolvedora de software sempre tivemos em mente que a principal premissa de Design é a simplicidade. O problema é que simplicidade é o oposto de flexibilidade. Todas as vezes que tentamos fazer algo simples o suficiente acabamos por “limitar” a funcionalidade, e quando o processo demanda mas não somos capazes de atender temos que envolver a equipe de desenvolvimento. Lutamos um bom tempo para minimizar suporte de nível 1 mas a falta de flexibilidade e ferramenta fez explodir a quantidade de suporte de nível 2. Para que o nosso produto possa atender os mais variados processos ele precisa ser flexível. Em outras palavras, para o usuário final a simplicidade é desejável, mas para o consultor de implantação ou o administrador do sistema a flexibilidade é mais importante. Para que possamos prestar um bom serviço o consultor deve ser capaz de implantar rápido e de modo aderente aos processos dos clientes. A agilidade do consultor em colocar o processo em produção é percebida como qualidade no serviço prestado, isso sem falar que um processo bem implantando tende a ter adesão mais fácil e quanto mais rápido implantarmos maior a nossa escalabilidade.
Para o usuário final a simplicidade é desejável, mas para o consultor de implantação ou o administrador do sistema a flexibilidade é mais importante.
Por fim, ao conversar com o pessoal do Suporte percebe-se que boa parte do tempo de atendimento é dedicado a entender o que o cliente deseja. Como já foi dito aqui o cliente fala Negociês e nós somos fluentes apenas em Tecniquês. Mais uma vez o fato de não ter um produto verticalizado complica a situação uma vez que é bem difícil falar tantos idiomas dos inúmeros processos e seguimentos. É por isso que se tivermos em mente que o diagnóstico rápido do problema ajuda na prestação do serviço isso pode influenciar o Design da funcionalidade e resultar em qualidade de atendimento.
Um dos grandes avanços do Holmes em termos de suporte foi a criação do Watson, um sistema de uso interno que nos permite ter a mesma configuração que os usuários com dúvidas. Ter boas maneiras de diagnosticar os problemas não só nos permite prestar um melhor suporte como evita que os outros níveis de suporte precisem ser envolvidos. Em outras palavras, quanto mais o suporte de nível 1 puder identificar os problemas melhor! Ao que tudo indica, a adoção do Intercom melhorou bastante a comunicação dos diferentes níveis de suporte permitindo um diagnóstico e solução de problemas mais rápido. Mas, no final das contas, como projetar funcionalidades ou ferramentas sob a perspectiva do diagnóstico pode impactar o nosso modo de pensar, seja você desenvolvedor, Designer ou até mesmo Comercial que pode usar isso como diferencial?