Engenharia de serviços: o que é, de onde vem e por que a IA trouxe o assunto de volta

O setor de serviços não financeiros do Brasil reuniu 1,9 milhão de empresas ativas e ocupou 15,9 milhões de pessoas em 2024, com R$ 3,5 trilhões em receita operacional líquida e R$ 2,1 trilhões de valor adicionado. Os números são da Pesquisa Anual de Serviços do IBGE, cuja nova série histórica começa justamente em 2024, depois da substituição da RAIS pelo eSocial na apuração; os resultados foram divulgados em agosto de 2026. Em escala macro, serviços respondem por 59,7% do PIB brasileiro, segundo o indicador de valor adicionado do Banco Mundial referente a 2025.

Setor enorme. E, em boa parte dessas empresas, a pergunta "como exatamente isso é entregue?" não tem resposta escrita em lugar nenhum.

Essa lacuna tem nome, tem método e tem quase cinco décadas de literatura. Chama-se engenharia de serviços.

O que é, em uma frase

Engenharia de serviços é a aplicação de método de projeto — o mesmo tipo de disciplina usada para desenvolver um produto físico ou um software — ao desenvolvimento e à operação de serviços.

Em vez de tratar o serviço como algo que "depende de quem atende", ela o trata como um sistema projetável: etapas explícitas, papéis definidos, pontos de contato mapeados, capacidade dimensionada, pontos de falha previstos e critérios de qualidade acordados antes da primeira entrega.

A tese por trás da disciplina é simples e incômoda. Se o serviço não foi desenhado, ele foi improvisado. E improviso não é neutro: aparece na margem, no retrabalho, na variação de qualidade entre dois clientes e na impossibilidade de treinar alguém novo sem um veterano ao lado.

De onde vem

A origem não é uma data única. São três ondas.

1. Industrializar o serviço (anos 1970)

Em setembro de 1972, Theodore Levitt publicou na Harvard Business Review o artigo Production-Line Approach to Service. O argumento: o setor de serviços sofria de ineficiência e de variação de qualidade porque operava num modelo artesanal, tratando cada atendimento como evento isolado. A saída proposta era planejamento, processo, consistência e investimento de capital.

Seis anos depois, em novembro de 1978, Richard B. Chase publicou na mesma revista Where Does the Customer Fit in a Service Operation?, classificando serviços pelo grau de contato do cliente com o sistema de entrega. Sua proposta: quanto menor o contato direto do cliente com a operação, maior o potencial de ela operar em eficiência máxima. Dali vem a separação entre linha de frente e retaguarda que até hoje organiza qualquer operação de serviço séria.

Essas duas ideias resolveram parte do problema e criaram outro. Serviço tratado como linha de produção tende a padronizar exatamente onde o cliente valoriza julgamento.

2. Desenhar o serviço (anos 1980)

Em janeiro de 1984, G. Lynn Shostack publicou na Harvard Business Review Designing Services That Deliver e apresentou o service blueprint. Vale registrar de onde ela falava: Shostack era então vice-presidente sênior responsável pelo Private Clients Group do Bankers Trust. A proposta não veio da academia, veio de dentro de uma operação.

O argumento central é que a raiz da maioria dos problemas de serviço é a ausência de desenho e de controle sistemáticos — e que um blueprint permite testar premissas no papel antes de expor o cliente ao erro.

O blueprint segue sendo a ferramenta mais prática da disciplina: um diagrama que mostra a jornada do cliente, as ações visíveis, o que acontece nos bastidores, os sistemas de apoio e, no ponto que costuma doer, onde o processo pode falhar.

3. Formalizar a disciplina (anos 1990 e 2000)

O termo "service engineering" se consolidou na Alemanha a partir de meados dos anos 1990. Em 1995, o ministério federal alemão de educação e pesquisa lançou a iniciativa "Dienstleistungen für das 21. Jahrhundert" — Serviços para o Século XXI. A coordenação técnica ficou com Hans-Jörg Bullinger, então diretor do Fraunhofer IAO, em Stuttgart, e o trabalho reuniu cerca de 300 especialistas de empresas, universidades e governo em grupos de trabalho encarregados de definir a agenda de pesquisa do setor de serviços, como registra o capítulo dedicado ao tema dentro da iniciativa alemã.

A produção desse período foi organizada por Bullinger e August-Wilhelm Scheer no volume Service Engineering: Entwicklung und Gestaltung innovativer Dienstleistungen, publicado pela Springer em 2003, com segunda edição em 2006. É a referência que consolidou modelos de procedimento para desenvolver serviços de forma estruturada, em etapas, com entregáveis definidos.

Em paralelo, duas frentes ampliaram o escopo da conversa.

Em 2004, Stephen Vargo e Robert Lusch publicaram no Journal of Marketing o artigo Evolving to a New Dominant Logic for Marketing, propondo inverter a lógica herdada da economia de bens: serviço, e não produto manufaturado, como base da troca econômica, com valor cocriado junto ao cliente.

Entre 2004 e 2005, a IBM passou a defender publicamente o estudo de serviços como disciplina acadêmica, sob a sigla SSME — Service Science, Management and Engineering. A iniciativa foi conduzida por James Spohrer e Paul Maglio a partir do Almaden Research Center, na Califórnia, e incluiu currículos universitários e um white paper desenvolvido com a Universidade de Cambridge.

Quando alguém apresenta desenho de serviço como novidade de 2026, portanto, o que está em curso é redescoberta. Não invenção.

O que exatamente se projeta

Dizer "desenhe seu serviço" é vago. Os objetos concretos de projeto são estes:

• Escopo e promessa: o que está incluído, o que não está e qual resultado o cliente pode esperar, em qual prazo.

• Jornada e pontos de contato: cada momento em que o cliente interage, por qual canal, com quem, e o que acontece antes e depois de cada um.

• Linha de frente e retaguarda: o que exige contato humano e o que pode operar desacoplado do cliente.

• Papéis e decisões: quem decide o quê, e para quem escala o caso que sai do padrão.

• Capacidade: quantas entregas simultâneas a estrutura atual sustenta antes da qualidade cair.

• Pontos de falha: onde o processo quebra com mais frequência e qual é a resposta prevista.

• Evidência de valor: como o cliente enxerga que o trabalho foi feito, e não apenas que foi cobrado.

• Preço e modelo: se a cobrança é por hora, por entrega, por assinatura ou por resultado, e por quê.

Nenhum desses itens é técnico. Todos são decisões de negócio. E quando não são tomadas explicitamente, elas são tomadas por omissão, em geral pela pessoa mais júnior da operação, no meio de um atendimento.

Por que o assunto voltou agora

O reenquadramento que me parece mais útil é este: a inteligência artificial não criou a necessidade de engenharia de serviços. Ela tornou visível o custo de não ter.

Durante décadas, o gargalo de uma operação de serviço foi capacidade. Para atender mais, era preciso contratar mais gente. Hora-homem é caro, e isso limitava a escala de forma natural — além de esconder o desenho ruim atrás da falta de braços.

A IA removeu parte dessa restrição. E, removida a restrição de capacidade, o gargalo apareceu onde sempre estivera: no desenho.

Automatizar um processo exige descrevê-lo. Um agente de IA precisa saber quais são as etapas, quais dados consultar, quando pode decidir sozinho, quando precisa escalar e qual é o critério de concluído. Empresa que não tem isso escrito não tem o que automatizar. Tem uma intenção. É nesse ponto que os projetos param.

Os dados públicos disponíveis apontam nessa direção, com as ressalvas de sempre. A Gartner projeta que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027, por custo crescente, valor de negócio pouco claro ou controles de risco inadequados. A projeção, divulgada em junho de 2025, apoia-se em levantamento com mais de 3.400 organizações que investem na tecnologia. Projeção não é resultado observado — mas o mecanismo descrito pela consultoria é de desenho e governança, não de modelo.

Na mesma direção, o relatório The GenAI Divide: State of AI in Business 2025, produzido pela iniciativa NANDA do MIT, estimou que cerca de 95% dos pilotos corporativos de IA generativa não geraram impacto mensurável no resultado financeiro. Segundo o relatório, a causa principal não é a qualidade dos modelos, e sim uma lacuna de aprendizado: ferramentas genéricas não se adaptam ao fluxo de trabalho da empresa.

Aqui cabe um cuidado que a repercussão do número engoliu. O estudo, divulgado em agosto de 2025, baseia-se em 150 entrevistas com executivos, uma pesquisa com 350 funcionários e a análise de 300 implantações públicas. É uma amostra qualitativa ampla, não uma amostra probabilística do universo de empresas. O 95% circulou muito mais do que a metodologia que o sustenta.

Um caso documentado

O exemplo mais citado é o da Klarna, e ele serve justamente porque tem as duas metades.

Em fevereiro de 2024, a empresa anunciou que seu assistente de IA, construído em parceria com a OpenAI, havia assumido cerca de dois terços dos atendimentos no primeiro mês — 2,3 milhões de conversas — volume que a companhia descreveu como equivalente ao trabalho de 700 atendentes. Os números são da própria Klarna, não de auditoria independente.

Em maio de 2025, o cofundador e CEO Sebastian Siemiatkowski disse à Bloomberg que o custo havia pesado demais na decisão: "As cost unfortunately seems to have been a too predominant evaluation factor when organizing this, what you end up having is lower quality". Em tradução livre: quando o custo se torna o fator predominante de avaliação, o que se obtém é qualidade menor. A empresa passou a recrutar atendentes humanos novamente, com a garantia de que o cliente sempre teria a opção de falar com uma pessoa.

O detalhe que quase sempre se perde na versão resumida dessa história: a Klarna não desligou a IA. O assistente seguiu respondendo a maior parte das interações de alto volume. O que mudou foi o desenho — quais casos vão para a máquina, quais vão para uma pessoa e como o cliente atravessa essa fronteira.

Isso é engenharia de serviços. Não é escolha entre IA e gente. É a decisão de onde colocar cada uma, e com base em quê.

Para quem vale entender isso

O assunto é diretamente útil para:

• Donos e sócios de empresa de serviço, onde a estrutura de custo é dominada por hora-homem e a margem depende de desenho, não de volume.

• Quem lidera operação, entrega ou sucesso do cliente e precisa sustentar qualidade com pessoas diferentes entrando e saindo do time.

• Quem está avaliando comprar ou implantar IA, porque a pergunta de diligência mudou de "a ferramenta é boa?" para "meu processo está descrito o suficiente para ser entregue a ela?".

• Quem vende serviço profissional — consultoria, contabilidade, jurídico, agência, saúde, engenharia —, em que o produto é literalmente o processo.

• Quem precifica, já que preço por hora e preço por resultado exigem desenhos de entrega diferentes.

• Quem combina produto e serviço no mesmo contrato, situação em que a parte de serviço costuma ser a que consome margem sem ninguém perceber.

Vale também dizer para quem isso importa menos: operação transacional simples, de baixo volume e baixa variabilidade, em que o custo de projetar excede o retorno. Nem todo serviço precisa de blueprint.

Limites, e o contraponto honesto

Quatro ressalvas que considero necessárias.

A primeira é sobre o momento. Desenhar cedo demais é desperdício. Antes de escrever a regra, é razoável executar manualmente algumas vezes, até o padrão ficar óbvio — documentar um processo que ainda vai mudar três vezes produz manual morto. Essa é uma posição minha, não um consenso da literatura.

A segunda é a que Levitt criou sem querer. Padronização excessiva destrói valor onde o cliente compra justamente julgamento. A pergunta não é quanto padronizar, é o que padronizar.

A terceira é que blueprint não é execução. Diagrama bonito em parede de sala de reunião não muda operação nenhuma; o que muda é a decisão sobre papel, alçada, capacidade e preço tomada a partir dele.

A quarta é de contexto. A literatura fundadora da disciplina nasceu em grandes empresas alemãs, americanas e japonesas, com estruturas de pesquisa e de processo que uma pequena ou média empresa brasileira não tem. Aplicar isso aqui é trabalho de adaptação de escala, não de cópia de framework.

Cinco perguntas para diagnosticar

Um checklist curto, para usar antes de contratar qualquer ferramenta:

1. Se o seu melhor atendente sair amanhã, o que exatamente se perde — e onde isso está escrito?

2. Quantas entregas simultâneas a sua estrutura sustenta hoje antes de a qualidade cair? Como você sabe?

3. Em qual etapa o processo falha com mais frequência? Existe resposta prevista, ou cada caso é resolvido do zero?

4. O cliente consegue enxergar o que foi entregue sem que você precise explicar?

5. Do que você quer automatizar, o que já está descrito em etapas, com critério de decisão e ponto de escalonamento definidos?

Se as respostas às duas primeiras dependem de perguntar para alguém, o serviço ainda não foi projetado. Foi acumulado.

O que acompanhar adiante

Três coisas valem observação nos próximos meses: se a taxa de cancelamento de projetos de IA agêntica confirma ou desmente a projeção da Gartner até 2027; se os relatórios seguintes sobre adoção corporativa mantêm o diagnóstico organizacional em vez do tecnológico; e se as empresas que rebalancearam automação e atendimento humano, como a Klarna, sustentam qualidade e custo ao mesmo tempo — algo que, por ora, não está demonstrado.

Enquanto isso, a pergunta que vale, quando um fornecedor de IA chega com uma proposta, não é o que a ferramenta faz.

É qual parte do seu serviço você consegue descrever bem o suficiente para entregar a ela.

A resposta a essa segunda pergunta é o diagnóstico de verdade. E ela não depende de tecnologia nenhuma.