Que as LLMs têm trazido impacto a diversas áreas, todo mundo sabe. Contudo, uma área de que pouco se fala é a padronização de processos internos das empresas.
Uma skill feita em um dia pode causar um impacto gigantesco e trazer padronização onde as regras eram consideradas opcionais. Como exemplo, vou citar um problema com que a engenharia teve de lidar por anos: tickets mal escritos, com dados faltando e informações pela metade ou até falsas.
Para resolver o problema, criei uma skill que automatizava a criação de tickets. Ela pegava as informações a que já tinha acesso na conversa e, fazendo perguntas, preenchia qualquer outra informação mínima necessária que não encontrava.
A empresa já tinha um padrão, e a skill foi criada e implementada sobre ele. Contudo, o padrão não era seguido e muitas vezes era contornado para que o criador do ticket terminasse de preencher rápido e seguisse seu caminho, sem parar em perguntas cuja resposta não sabia onde procurar.
Imagine comigo: você trabalhava no suporte da empresa. Tinha cinco clientes diferentes te perguntando ao mesmo tempo sobre problemas diferentes que encontraram.
Você estava tentando responder a todos de forma mais ou menos rápida. Fazia uma pequena mudança aqui, copiava um texto padrão ali, respondia um email. No meio, encontrava um problema que só conseguia resolver abrindo um ticket pra engenharia.
Aí seu workflow, já caótico, quebrava de vez. Você parava e tinha que responder a um monte de perguntas com detalhes que começava a misturar com o contexto de outros clientes. No meio do preenchimento do ticket, tinha que parar pra atender um cliente mais nervoso e, depois, outro, funcionário de uma empresa VIP.
A pessoa que preenchia o ticket, em geral, era alguém do suporte com clientes na orelha querendo resposta. Cada minuto parado era mais um cliente com raiva querendo uma solução e mais um ticket de suporte acumulando na fila.
O resultado eram tickets com pouca informação chegando aos times de engenharia. O engenheiro responsável pelo ticket acabava perdendo tempo correndo atrás de várias pessoas pra conseguir as informações mínimas para começar a trabalhar.
Com a skill, vimos isso mudar de forma drástica e rápida. A skill trouxe solução para os dois lados. Para quem criava o ticket, ela pegava o que já estava na conversa e respondia várias perguntas padrão, como:
Qual é o problema?
Qual o impacto para o usuário final?
Em que página o usuário viu o erro?
Se for uma feature nova, como ela vai aparecer para o cliente final?
O que não é pra ser feito?
Isso trouxe velocidade para quem criava o ticket: se o contexto estivesse completo, a pessoa só chamava a skill e o ticket saía pronto, sem nenhum input a mais. Para os engenheiros, trouxe a garantia de que o ticket tinha tudo que o suporte sabia sobre o problema.
Em termos de resultado, a skill começou como um projeto individual, com poucos tickets, e passou para 650 tickets criados por mais de 10 times e 23 pessoas diferentes em 3 meses de uso. Nenhum processo interno ou reunião de aprendizado foi feito. A skill sequer foi mencionada para esses usuários e times, mas isso não a impediu de se tornar o novo padrão e se espalhar. Uma única skill padronizou algo que a engenharia lutou por anos para padronizar e resolveu um problema que o suporte tinha, liberando tempo para lidar com mais clientes.
O que se espalhou não foi só a skill, foi o formato do ticket. Cada ticket criado com ela tinha as mesmas seções, na mesma ordem, e era lido por quem o recebia, comentava ou abria o ticket seguinte. Quem lia passava a reconhecer o formato e a esperar por ele; quem escrevia passava a segui-lo, com ou sem a skill. O ticket bem escrito virou um gênero de texto, e um gênero se aprende lendo, não em reunião.