Terceiros: Um programa de suporte da Microsoft – Como os DSEs aceleram os serviços de suporte da Microsoft (ep6).

Essa é uma boa pergunta. Como gestor de arquitetura empresarial, a minha equipa analisou ofertas que já existem há algum tempo em várias organizações e criámos o DSE, sigla em inglês para «engenheiro de suporte designado». Eles são arquitetos empresariais, mas desempenham a função de engenheiros de suporte — basicamente, um tratamento VIP para os nossos clientes. Um dos nossos objetivos é construir um relacionamento com o cliente.

Isso é importante para nós porque, por exemplo, já tiveste a experiência de ligar para a tua operadora de telemóvel, receber suporte e falar com quem quer que seja. Às vezes, eles são bons, mas outras vezes tens que explicar a tua situação repetidamente. E se ligares no dia seguinte, adivinha só? Falas com outra pessoa. Tens que recomeçar toda a história do zero.

Não queríamos proporcionar essa experiência aos nossos clientes, se pudéssemos evitar. Como fazemos isso? Tornamo-nos parte da organização deles. É essa a função do DSE: eles são os proprietários dessa tecnologia para os seus clientes e sabem tudo sobre ela.

Parte dessa responsabilidade é colocar notas internas nos tickets para que, quando os engenheiros abrirem um ticket de avaria/reparação com um nível de gravidade um, dois, três ou quatro, fique claro que temos um DSE que está familiarizado com essa tecnologia e que sabe tudo sobre ela, para que possam provavelmente saltar grande parte do trabalho preparatório introdutório. Isso pode incluir perguntas como: «Como é o contexto? Qual é o contexto histórico? O que está a acontecer no ambiente que pode ter levado a isso?»

É bom que os nossos engenheiros possam contar com essa propriedade para preencher essas lacunas e dar uma ajuda, porque às vezes eles podem estar muito familiarizados com a tecnologia e ter ideias adicionais. Trata-se de serviços puramente reativos apoiados por serviços proativos: aprender com outro especialista que já conhece esse ambiente e evitar que os clientes tenham que contar a sua história repetidamente.

O outro objetivo principal que temos está relacionado com a realidade de que, atualmente, a tecnologia está muito convergente. Fico muito feliz que a Microsoft não construa autoestradas, porque não há faixas — todos os carros colidiriam. Com todos esses «carros» a bater, se tivermos técnicos que conhecem SQL, os problemas com esse sistema podem passar para o Intune e, depois, para o Azure ou o M365. Depois disso, o problema fica todo misturado. Por outras palavras, 80% do problema, tecnologia, atualização ou serviço proativo que está a ser tratado pode ser SQL. Os outros 20% podem ser qualquer outra coisa.

Para a US Coud, isso é comum, mas para outras organizações — e eu trabalho com consultoria há 40 anos — não é muito comum. E o que é realmente bom é que, como eu disse, combinamos os serviços reativos e proativos para oferecer aos nossos clientes uma oferta completa. Também contratamos outros tecnólogos, se os clientes precisarem deles para resolver os outros 20% dos seus problemas com a Microsoft. Isso pode incluir SQL, SharePoint, Power BI ou o que for necessário para resolver esses tickets. Fazemos tudo.

Tivemos um caso assim na semana passada. O CEO de uma grande empresa listada na Fortune 100 — provavelmente uma posição abaixo do número 100 — estava numa reunião do Teams a fazer uma apresentação. Havia 80 ou mais pessoas na chamada, todas executivas de nível C. No entanto, o nosso cliente foi expulso da reunião enquanto fazia a apresentação. Isso não é nada bom; significa que alguém na reunião do Teams tinha a capacidade de expulsar o apresentador.

Foi uma falha de configuração na organização, e foi devido ao momento e à mensagem que estava a ser enviada para essa organização naquele momento, então o CEO foi expulso da reunião do Teams — e isso não ficou muito bem.

Por isso, abriram um caso Sev. 1. Tinham um DSE relacionado com o Teams. Assim, o DSE da equipa foi notificado pela equipa de reparação devido à nota interna que dizia: «Rob, o nosso DSE está a trabalhar nesta tecnologia. Talvez seja melhor contactá-lo.»

Ele entrou na chamada e, na primeira meia hora, analisou a situação, descobriu exatamente o que tinha corrido mal e ajudou-os a implementar uma política para evitar que isso voltasse a acontecer no futuro. Agora, não há motivo para que mais ninguém consiga expulsar o CEO de uma chamada quando ele está a fazer uma apresentação.

Todo esse processo foi muito rápido devido ao nível de complexidade do ambiente, à natureza do problema e aos participantes envolvidos na sua resolução.

O cliente também decidiu que queria que a Microsoft analisasse essa questão.

A Microsoft respondeu em dez minutos após analisar a nossa análise (que já estava pronta), o nosso plano de projeto e como proceder com a resolução, e especialistas diretamente da Microsoft disseram: «Não faríamos nada diferente. É exatamente assim que se deve lidar com isso.»

Conseguimos lidar com essa questão de forma muito oportuna, reconectar o cliente à chamada, resolver todo o problema e garantir que isso não voltasse a acontecer no futuro. Essa resposta e resolução ágeis não teriam sido possíveis sem a dedicação do nosso DSE.

Sim, isso acontece diariamente, por isso não é uma ocorrência rara! Há muita recolha de dados quando um ticket chega e um engenheiro fala pela primeira vez ao telefone com um cliente. Eles fazem perguntas como: «Preciso de saber a sua história. Por que está a ligar-me? O que está a acontecer? Como é o ambiente? Quantos utilizadores são afetados?» Eles passam por todo esse processo.

O que acontece é que, mais uma vez, devido a essa nota interna, um DSE é chamado e pode fornecer algumas informações ao técnico. Muitas vezes, isso ajuda muito a restringir a resolução do problema, reduzindo o tempo necessário para que um ticket inicie o processo de resolução.

É como uma situação em que tu e eu somos novos numa conversa, mas estamos a planear que as nossas famílias passem algum tempo juntas. Não sei quantos filhos tu tens e não sei o que vamos fazer juntos, mas ainda assim tenho de te fazer esse tipo de perguntas.

Bem, digamos que eu já sei, por um amigo que o conhece há mais tempo, que não tem uma filha, então não preciso fazer perguntas relacionadas ao que as meninas gostam de fazer. Acabei de reduzir a árvore de perguntas pela metade para nos ajudar a decidir como vamos organizar um encontro para as crianças brincarem.

Não preciso fazer um monte de perguntas bobas, como quantos anos tem a sua filha ou o que ela gosta de fazer. Esse seu amigo de longa data é como um DSE para um cliente: um especialista que sabe mais sobre o contexto digital e a infraestrutura de TI do cliente e pode ajudar os novatos na conversa sobre como ajudar o cliente a ter sucesso.

Digamos que o seu amigo de longa data (o DSE neste cenário) me tenha dito que tem um filho de 12 anos que adora basebol. Quando entro na conversa consigo, já estamos a restringir novamente essas perguntas. Dessa forma, posso eliminar ainda mais conversas sobre se o seu filho gosta de futebol ou basebol. Posso ir direto ao que ele precisa.

Todas essas coisas são o que posso obter do DSE, e podemos simplesmente ir direto à conversa sobre o que eles realmente precisam. Eles precisam de um treinador para ajudá-los a melhorar as suas RBIs no bastão? Se for esse o caso, então não levarei o suporte de bastão para o encontro, porque ele nem precisará dele.

Graças ao DSE, chegamos diretamente ao cerne do problema, em vez de ter uma conversa inteira restrita ao seu histórico. Embora o histórico seja ótimo, ele não resolve a tarefa em questão. Como os DSEs têm um conhecimento profundo do ambiente, eles podem ajudar a equipa de manutenção a eliminar uma série de coisas.

Se já fez alguma vez resolução de problemas, sabe que os especialistas precisam de dedicar muito tempo a identificar o problema para encontrar a solução. O DSE ajuda-nos a identificar o problema muito mais rapidamente.

Atualmente, o suporte de escalonamento da Microsoft inclui o uso de várias organizações e, devido às leis de privacidade, muitas vezes não é permitido compartilhar essas informações.

Se o funcionário de suporte concluir um turno e forem 17h, por exemplo, ele poderá acabar enviando esse ticket de escalonamento para outro fornecedor que não pode obter alguns dos dados do primeiro fornecedor devido a questões de privacidade, pois nenhum deles é funcionário da Microsoft.

Todos eles são«V-Dash», que significa «fornecedor» e fornece a esses funcionários apenas acesso de nível de fornecedor ao ticket.

Todos os nossos funcionários são da US Cloud, por isso o processo da nossa parte é bastante simples. Quando abre um ticket através da US Cloud, vai falar com um DSE ou com um técnico de reparação.

E todos eles poderão comunicar-se entre si e partilhar dados de forma segura, com encriptação e de ponto a ponto. Os nossos técnicos podem comunicar-se de forma aberta e livre.

E então, se precisarmos trazer alguém para ajudar na resolução do ticket, eles podem trazer um especialista que seja um arquiteto empresarial e que possa analisar o panorama global para juntar as peças. Às vezes, é muito complexo e são necessários vários pares de olhos de diferentes disciplinas para chegar a uma solução. Os tickets de avaria/reparação quase nunca são mais claros — envolvem várias tecnologias e questões. Temos a capacidade de trazer essas equipas.

Outras escalações levam muito tempo com outros fornecedores porque eles não conseguem incorporar essas disciplinas. Eles são meio que categorizados e isolados. O profissional de SQL fará a sua parte, depois passará o ticket para o profissional de SharePoint, que fará a sua pequena parte e passará para o profissional de Power BI, e assim por diante.

Entretanto, o tempo continua a passar e o problema continua, certo? As coisas não estão a ser resolvidas. É muito frustrante. Não é uma experiência agradável e é muito difícil para os engenheiros saberem quando devem mudar. Eles têm de se perguntar: «Quando devo mudar do SQL para o SharePoint e para o Power BI? Quando é que terminamos?»

E então há muitas acusações (não intencionais, mas ainda assim acusações) sobre quem provavelmente cometeu o erro. E eles usam a palavra «provavelmente», o que não é bom para a resolução e solução de problemas quando se lida com tickets de avaria/reparação.

Se eu fosse o cliente, gostaria de respostas definitivas. Quero uma resposta e quero começar a trabalhar.

Então, abordamos três áreas diferentes. Uma delas é a consultoria de projetos. Os clientes podem nos procurar com perguntas sobre os seus produtos Microsoft e obter ajuda especializada. As perguntas podem ser sobre qualquer assunto para o qual desejem aconselhamento profissional, como um novo botão que acabou de aparecer na interface, ou uma nova determinação da Microsoft que diz que algo será descontinuado, ou algo que precisa ser atualizado dentro de um determinado prazo.

Não somos donos da nuvem, apenas a alugamos. Por isso, como a alugamos, o «proprietário» pode, a qualquer momento, dizer, por exemplo: «Vou pintar as paredes de roxo na próxima semana. Precisa de estar preparado.»

E nós respondemos: «Não estou pronto! Ainda tenho quadros na parede, por isso não posso pintá-la de roxo.» Então, os clientes vêm ter connosco e perguntam: «Preciso de me preocupar com isso? Quando pintarem de roxo, isso vai afetar-me? O que vai acontecer?»

É o que chamamos de ticket de consultoria de projeto. Os clientes podem precisar apenas trocar algumas perguntas ou talvez tenham um plano. Podemos intervir e ajudá-los a se preparar: “Eis o que vamos fazer. Vamos remover os pregos e aplicar massa corrida. Depois, a Microsoft pode entrar em cena e pintar tudo de roxo”.

Mas como nos preparamos para isso? Esquecemos alguma coisa? Por exemplo, se não houver lona para cobrir o chão durante a pintura, a parede ficará roxa, mas parte do chão também ficará roxa, porque haverá respingos e pingos. Esse é o tipo de processo em que os ajudamos por meio de consultoria de projetos.

A próxima coisa que fazemos nos serviços de consultoria é uma implementação completa do projeto. Agora, consideramos um projeto qualquer coisa que leve mais de 15 horas para ser resolvida. Então, pode ser que estejamos a atualizar 300 servidores. Pode ser que estejamos a fazer algumas migrações ou uma fusão e aquisição, e estamos a fazer a parte da fusão propriamente dita, alterando endereços de e-mail e movendo dados e outras coisas de um lado para o outro.

Para os projetos que exigem 15 horas ou mais, o custo pode chegar a milhares. Depende realmente do tamanho da organização e da quantidade de ajuda necessária da US Cloud.

Com os projetos, podemos trabalhar de forma prática para oferecer suporte completo. Não fazemos registos de pessoal, fazemos registos de consultoria.

Temos profissionais inteligentes que podem ajudar a executar um processo, porque muitas vezes você fica sem tempo. Quando você diz ao seu gerente: «Vamos ter isso pronto até sexta-feira», mas não vai conseguir porque não tem tempo ou profissionais que possam fazer isso. Você precisa de mais ajuda, porque às vezes é preciso uma equipe inteira para realizar alguns desses projetos, pois eles são grandes. Temos consultores de tecnologia e arquitetos empresariais que podem intervir e fazer isso.

Eles podem literalmente colocar a mão na massa e trabalhar para a sua equipa. E a razão pela qual digo que é consultoria é porque, como sabe, fazemos muitos testes e pilotos e tudo mais, mas às vezes há uma surpresa. Sabemos que há algo diferente na conta ou que há algo a acontecer na organização que ninguém abordou até começarmos a executar um novo processo. Podemos então mudar de rumo e resolver esses problemas na hora.

A última coisa que o nosso serviço de consultoria faz é o DSE, como já mencionámos. Portanto, o DSE é a nossa terceira oferta, que proporciona à organização uma experiência familiar de excelência, para que se torne realmente parte integrante da equipa, o que é ótimo para os clientes.