Service Design: o método que falta quando a IA vira serviço

A maioria dos projetos de IA que fracassa não fracassa por causa do modelo. Fracassa porque ninguém desenhou o serviço em volta dele. O modelo funciona na demonstração, responde bem no piloto, e ainda assim a coisa desanda em produção porque o handoff para o humano não existe, o caso de erro não foi previsto e o processo de suporte é um vazio. Existe uma disciplina inteira, com mais de quarenta anos, feita exatamente para resolver isso. Chama-se service design, e ela ficou mais relevante, não menos, com a chegada da IA.

De onde vem o método

Em 1984, a executiva de banco Lynn Shostack publicou na Harvard Business Review um artigo chamado Designing Services That Deliver. O problema que ela atacava era antigo: serviços são intangíveis e efêmeros, difíceis de padronizar e de melhorar justamente porque não dá para segurar um serviço na mão como se segura um produto. A proposta dela foi o service blueprint, um mapa que torna o serviço visível e, portanto, gerenciável. Foi o nascimento prático do que hoje chamamos de design de serviço.

A ideia central do blueprint é separar em camadas o que normalmente vive embolado na cabeça de cada área. Acima de uma linha, chamada de linha de visibilidade, fica o frontstage: tudo o que o cliente enxerga e vive, o palco. Abaixo dela fica o backstage: as ações do time e os processos de suporte que o cliente nunca vê, mas dos quais cada momento do palco depende. O blueprint desenha a jornada do cliente na horizontal e, para cada passo dela, mostra na vertical o que precisa acontecer nos bastidores. De repente, um serviço difuso vira um objeto que pode ser documentado, medido, controlado e melhorado.

Décadas depois, Marc Stickdorn e Jakob Schneider organizaram a disciplina no livro This is Service Design Thinking, com cinco princípios que envelheceram bem: o serviço deve ser centrado no usuário, cocriativo, sequencial, evidente e holístico. Sequencial porque um serviço é uma sequência de momentos no tempo, e a experiência é a soma deles, não a média. Holístico porque o cliente sente o sistema inteiro, não a sua parte favorita. Guarde esses dois: eles explicam por que a IA sozinha nunca é o serviço.

Por que a IA reabre esse velho mapa

Quando você coloca um modelo de IA em produção, ele ocupa uma posição muito específica no blueprint: é uma peça de backstage. Um componente poderoso, sim, mas ainda assim um componente abaixo da linha de visibilidade. O que o cliente vive continua sendo o frontstage, e o frontstage é feito de muito mais que o modelo. É a interface, a linguagem, o tempo de resposta, o que acontece quando a IA acerta e, principalmente, o que acontece quando ela erra.

É aqui que o service design cutuca a ferida dos projetos de IA. A conversa técnica se concentra quase toda em uma célula do mapa, a do modelo, e ignora a jornada em volta. O resultado é conhecido: chatbots que respondem bem até o momento em que o cliente pede algo fora do script e caem num beco sem saída. Agentes que executam a tarefa e não sabem a quem entregar quando travam. Assistentes que funcionam para o caso feliz e não têm plano nenhum para o caso infeliz, que em produção é a maioria. Cada uma dessas falhas é uma célula do blueprint que ninguém desenhou.

O cliente não compra o seu modelo. Compra o resultado do serviço que o modelo sustenta. E serviço se sente por inteiro, do acerto ao erro.

Isso conecta com uma verdade que já rondou outros textos nossos. Quando a leva de lançamentos empurra agentes que assumem operações inteiras, a pergunta de service design é imediata: onde está a linha de visibilidade, e o que acontece logo abaixo dela quando o agente precisa de um humano? Um agente sem handoff desenhado não é autonomia, é um buraco no palco esperando o cliente cair.

Como aplicar, passo a passo

O valor prático do service design não está na teoria, está no exercício de desenhar o blueprint antes de plugar o modelo. Um roteiro enxuto para times que colocam IA em produção.

Primeiro, desenhe a jornada do cliente na horizontal, momento a momento, do gatilho ao desfecho. Sem IA ainda, sem tecnologia. Só a sequência do que a pessoa está tentando fazer. Esse é o princípio sequencial de Stickdorn na prática: você está mapeando o tempo vivido, não a arquitetura do sistema.

Segundo, marque a linha de visibilidade e preencha o backstage de cada momento. Para cada passo do cliente, o que precisa acontecer atrás do palco? É aqui que o modelo de IA entra, como uma das peças do backstage, ao lado de bases de dados, integrações e, crucialmente, pessoas. Ver o modelo nesse contexto já cura metade da ilusão de que ele é o serviço.

Terceiro, e este é o passo que quase todo mundo pula, desenhe os caminhos de erro e os handoffs. Para cada ponto em que a IA age, pergunte: e quando ela erra? Quem assume? Como o caso passa para um humano sem o cliente recomeçar do zero? Qual é o plano B quando a integração cai? Um blueprint honesto tem tantas setas de exceção quanto de caminho feliz. É esse desenho que separa o piloto bonito da operação que aguenta o mundo real, o mesmo abismo que discutimos entre piloto e produção quando a governança atrasa.

Quarto, evidencie. O princípio de evidenciar, de Stickdorn, lembra que o cliente precisa perceber o que acontece nos bastidores para confiar. Mostrar que um humano vai revisar, que a resposta foi checada, que existe um caminho para falar com uma pessoa, tudo isso é design de serviço, não detalhe de interface. Confiança em IA se constrói tornando visível o cuidado invisível.

O que muda na operação

Adotar service design não exige contratar uma consultoria de design nem produzir mapas bonitos para pendurar na parede. Exige uma mudança de ordem: desenhar o serviço antes de escolher a tecnologia, e não o contrário. A pergunta que abre o projeto deixa de ser qual modelo vamos usar e passa a ser que serviço vamos entregar, e onde a IA ajuda a entregá-lo.

Essa inversão tem parentesco com outros fundamentos que já cobrimos. O story mapping organiza a jornada em fatias de valor antes de detalhar tarefas, e o Lean UX cobra que se meça o resultado, não a entrega. O service design é a peça que amarra as duas na experiência real do cliente, incluindo os bastidores onde a IA vive. São lentes complementares para o mesmo hábito: pensar no desfecho para a pessoa antes de pensar na máquina.

Shostack criou o blueprint para tornar tangível algo que parecia impossível de controlar, o serviço. Quarenta anos depois, a IA trouxe de volta a mesma tentação de achar que a tecnologia é o serviço. Não é, nunca foi. O modelo é uma peça de backstage brilhante. O serviço é o mapa inteiro, e quem desenha o mapa antes de plugar o modelo é quem coloca IA em produção de verdade, não em demonstração.

Se você quer desenhar o serviço em volta da sua IA antes de escalar, mapeando handoffs e caminhos de erro que sustentam a operação, fala com a gente no WhatsApp.