5.9 Design de serviços

Visão geral e motivação

O design de serviços é a prática de dar forma ao serviço inteiro que uma pessoa vivencia, entre todos os canais e ao longo de todo o espaço de tempo, e não a uma única tela ou aplicativo. Quando alguém renova um passaporte, abre uma conta bancária ou relata um poste quebrado, essa pessoa não vivencia o seu produto. Vivencia um serviço: uma ligação telefônica, um site, uma carta pelo correio, uma fila, um e-mail que nunca chega, um atendente que precisa redigitar os dados dela num sistema que não enxerga o que o site já sabe. O capítulo 5.1 cobre o ofício de projetar interfaces individuais. O design de serviços amplia o foco para a jornada inteira e para tudo que fica atrás do balcão e faz a frente do balcão funcionar.

Essa distinção do “atrás do balcão” é o coração da questão. O design de serviços divide o mundo em palco, tudo que o usuário vê e toca, e bastidores, as pessoas, sistemas e processos que entregam o serviço mas ficam invisíveis ao usuário. Boas experiências de palco falham o tempo todo porque os bastidores não conseguem sustentá-las. Um formulário de reserva elegante que despeja numa planilha que um funcionário confere duas vezes por dia é um palco rápido parafusado em bastidores lentos, e o usuário sente o descompasso como um silêncio de três dias. Projetar o serviço inteiro significa projetar as duas metades juntas, e as costuras entre elas.

Para grandes equipes isso é inevitavelmente um problema organizacional. Os serviços quase sempre abrangem várias equipes, departamentos e sistemas, e as fronteiras entre esses donos são exatamente onde a experiência do usuário desmorona. Em contextos corporativos, uma única jornada de cliente pode cruzar vendas, provisionamento, cobrança e suporte, cada um com suas próprias ferramentas e metas e nenhum responsável pelo todo. No governo as apostas são ainda maiores: uma pessoa diante de um evento de vida como um luto ou um recém-nascido precisa navegar uma dúzia de agências separadas, cada uma pedindo a mesma evidência, porque os serviços são organizados em torno da estrutura do governo e não da necessidade da pessoa. O design de serviços é como vocês fazem o todo funcionar para o ser humano no centro dele.

Princípios fundamentais

Projetem o serviço inteiro entre canais e ao longo do tempo, não uma tela. O usuário não se importa com onde ficam as fronteiras das suas equipes.
Palco e bastidores são um só sistema. Uma experiência é só tão boa quanto as operações por trás conseguem sustentar.
O organograma aparece no serviço. Se as equipes são isoladas, o serviço parecerá isolado, então o design de equipes e o design de serviços precisam andar juntos.
As passagens de bastão entre canais e equipes são onde os serviços quebram. Projetem as costuras tão deliberadamente quanto os passos.
As ferramentas voltadas à equipe fazem parte do serviço. Um atendente frustrado com um console ruim produz um cliente frustrado.
Meçam o serviço de ponta a ponta, da primeira intenção do usuário ao resultado real, e não a métrica local de um canal.
Organizem em torno do objetivo do usuário ou do evento de vida, não dos seus departamentos internos.

Recomendações

Mapeie a jornada do cliente por todos os canais

Comecem traçando a jornada real que uma pessoa percorre para chegar a um resultado, como parte da experiência do cliente mais ampla. Um mapa de jornada dispõe as etapas pelas quais o usuário passa, desde perceber pela primeira vez que tem uma necessidade até alcançar o objetivo e além, e registra em cada etapa o que ele tenta fazer, o que pensa e sente e em que canal está. O valor vem de abranger os canais: a maioria das jornadas reais salta entre um site, uma linha telefônica, um e-mail, um aplicativo e um local físico, e a pior dor mora nas lacunas entre esses canais, onde o contexto se perde e o usuário precisa recomeçar. Fundamentem o mapa na pesquisa (capítulo 5.8) e não nas suas suposições, porque a jornada que vocês imaginam e a jornada que as pessoas de fato percorrem raramente são a mesma. Marquem os “momentos que importam”, os poucos pontos em que a experiência decisivamente tem sucesso ou fracassa, e concentrem o esforço ali em vez de espalhá-lo por igual. Uma jornada que parece suave em qualquer canal isolado ainda pode ser miserável de ponta a ponta, e só a visão entre canais a revela.

Construa um blueprint de serviço que ligue o palco aos bastidores

O artefato central dessa disciplina é o blueprint de serviço. Onde um mapa de jornada assume a visão do usuário, um blueprint acrescenta as camadas por baixo. Um blueprint típico corre em raias horizontais: as ações do cliente no alto, depois os pontos de contato de palco com que ele interage, depois uma “linha de visibilidade” abaixo da qual ficam as ações de bastidores que a equipe executa e por fim os sistemas de apoio e processos que viabilizam tudo acima. Leiam uma coluna de cima para baixo e vocês enxergam exatamente o que precisa acontecer nos bastidores para um momento de palco funcionar e onde ele quebrará se um sistema estiver lento ou uma passagem de bastão for nebulosa. Os blueprints são onde vocês acham as falhas silenciosas: a redigitação manual, o trabalho em lote noturno, a equipe que não sabe que é uma dependência. Desenhem-nos com a equipe operacional que de fato conduz os bastidores, não apenas com designers, porque essas pessoas sabem onde o trabalho real acontece. Um blueprint que mostra só o caminho feliz é decoração. Façam o blueprint também dos caminhos de falha e de recuperação.

Projete os bastidores e as ferramentas voltadas à equipe como de primeira classe

Tratem as ferramentas que a sua equipe usa como parte do produto, porque para o cliente elas são. Quando um atendente de central, um assistente social ou um separador de armazém luta contra um console interno lento, feio e meio quebrado, esse atrito é passado direto para a pessoa que ele atende, como esperas mais longas, respostas erradas e frustração visível. As ferramentas internas são cronicamente subfinanciadas justamente porque seus usuários são cativos e não podem ir embora, que é exatamente por que o capítulo 5.1 adverte que o software para usuários cativos é pago em erros e produtividade perdida e não em evasão. Deem aos sistemas voltados à equipe a mesma pesquisa, o mesmo design e o mesmo patamar de qualidade que dão aos voltados ao cliente. Prestem atenção especial às passagens de bastão, os momentos em que um caso passa de uma equipe, sistema ou canal para outro, porque uma passagem derrubada é invisível para todos, exceto o usuário deixado esperando. Projetem o que o lado receptor vê, que contexto viaja com o caso e o que acontece quando a passagem falha.

Alinhe o design de equipes com o design de serviços

Esperem que o organograma apareça no serviço. Essa é a lei de Conway, a observação de que os sistemas passam a espelhar as estruturas de comunicação das organizações que os constroem, tratada a fundo no capítulo 1.2. Se quatro equipes são donas de quatro passos de uma jornada e raramente conversam, o usuário sentirá quatro passos desconexos com rachaduras entre eles. Então o design de serviços e o design de equipes são o mesmo problema visto de dois ângulos, e vocês não consertam uma experiência fragmentada puramente com telas melhores se a propriedade subjacente está fragmentada. Usem os blueprints de serviço e os mapas de jornada para perguntar se as suas equipes são desenhadas em torno da jornada do usuário ou da conveniência interna e estejam dispostos a remodelar as equipes, ou a criar um papel que seja explicitamente dono de uma jornada de ponta a ponta, para que alguém responda pelo todo e não só pela sua fatia. Quando não conseguem redesenhar as equipes, ao menos tornem as passagens de bastão entre elas contratos explícitos, com contexto e níveis de serviço acordados.

Meça a qualidade do serviço de ponta a ponta

Escolham métricas que acompanhem o usuário da primeira intenção ao resultado real, e não métricas que lisonjeiam um canal isolado. Uma equipe de site pode atingir 98 por cento de conclusão de formulários enquanto um terço dessas conclusões falha em silêncio numa fila de bastidores, e a métrica local jamais mostrará. Meçam a conclusão de ponta a ponta (a pessoa realmente obteve o que veio buscar), o tempo de ponta a ponta (quanto tempo da intenção ao resultado, incluindo as esperas invisíveis de bastidores) e o esforço (quão difícil foi, em todos os canais que ela precisou usar). Combinem os dados operacionais com uma leitura direta de como foi a sensação, por uma pesquisa transacional, uma pergunta no estilo Net Promoter Score ou pesquisa contínua. Observem em especial os abandonos de canal para canal, porque essas costuras são onde a qualidade medida e a qualidade sentida mais divergem. Liguem essas métricas de serviço ao acompanhamento de resultados da gestão de produto (capítulo 10.14) para que os números conduzam a priorização e não fiquem num painel em que ninguém age.

Compromissos: prós e contras

Abordagem	Prós	Contras
Propriedade do serviço de ponta a ponta (uma equipe é dona de uma jornada)	Responsabilização clara, experiência coerente, as costuras são projetadas	Atravessa a estrutura organizacional existente, difícil de dotar de pessoal e de financiar, pode gerar gargalo
Propriedade por canal ou por passo	Encaixa nas equipes existentes, escopo local claro, fácil de dotar de pessoal	Ninguém é dono do todo. Lacunas entre canais. Otimização local
Blueprint completo de serviço antecipado	Revela falhas de bastidores antes de entregar, entendimento compartilhado	Demorado, pode ficar obsoleto, risco de análise antes da ação
Apenas mapeamento leve de jornada	Rápido, barato, bom o bastante para ver as piores lacunas	Perde as falhas de bastidores e de sistemas que um blueprint pegaria
Consistência omnicanal (unificada entre canais)	Passagens de bastão sem emendas, o contexto atravessa os canais	Integração cara, exige dados compartilhados e equipes alinhadas

A tensão central é entre o serviço de que o usuário precisa, que flui através das suas fronteiras, e a organização que vocês de fato têm, que é desenhada ao longo delas. Resolvam de forma proporcional e não dogmática. Vocês não precisam reorganizar a empresa inteira para projetar bem um serviço, mas precisam de ao menos uma pessoa ou equipe responsável pelo resultado de ponta a ponta, armada com um blueprint que torna visíveis os bastidores e um mandato para consertar as costuras. Gastem o blueprint mais pesado nas jornadas de alto volume, alto risco ou alta falha e usem mapas de jornada mais leves para o resto. O objetivo não é um artefato perfeito: é um serviço que funcione para a pessoa no centro dele.

Perguntas para discutir com sua equipe

Quem é dono do serviço inteiro, de ponta a ponta, da primeira intenção do usuário ao resultado real, e que poder essa pessoa realmente tem? Na maioria das grandes organizações a resposta honesta é “ninguém”, porque a propriedade é dividida por canal e por departamento, e cada dono é medido pela própria fatia. Essa lacuna é onde os serviços falham, já que as costuras entre os donos não pertencem a ninguém e não recebem atenção. Decidam se criarão um dono explícito de ponta a ponta, um dono de serviço ou dono de jornada, e sejam claros sobre se essa pessoa consegue de fato mudar os sistemas de bastidores e as fronteiras das equipes ou é meramente responsável por uma métrica que não consegue mover. Levem o organograma atual e o blueprint da sua principal jornada e ponham-nos lado a lado para ver quem toca a jornada e quem responde por ela. Se os dois não coincidem, vocês acharam a fonte das suas piores falhas de passagem de bastão. A resposta deve mudar como vocês financiam e dotam de pessoal o trabalho, e não apenas quem comparece à reunião diária.
As nossas equipes são desenhadas em torno da jornada do usuário ou da nossa conveniência interna, e estamos dispostos a mudar isso? A lei de Conway (capítulo 1.2) significa que o seu serviço espelhará a sua estrutura de comunicação quer vocês queiram ou não, então uma jornada dividida entre quatro equipes que não se comunicam parecerá quatro passos desconexos. O movimento confortável é consertar as telas e deixar o organograma em paz, mas isso trata um sintoma enquanto a causa continua regenerando-o. Olhem com honestidade se as fronteiras das suas equipes criam exatamente as lacunas de passagem de bastão de que os seus usuários reclamam e pesem o custo real de remodelar as equipes contra o custo contínuo de uma experiência fragmentada. Levem os pontos de dor do mapa de jornada e verifiquem quantos ficam precisamente numa fronteira de equipe. Se a maioria fica, uma UI melhor não os salvará, e a conversa precisa ser sobre o design das equipes. O que vocês decidirem aqui determina se as melhorias do serviço pegam ou se erodem em silêncio.
Quão bem as nossas ferramentas voltadas à equipe servem as pessoas que as usam, e como isso aparece para o cliente? As ferramentas internas são o software mais consistentemente negligenciado de qualquer grande organização, porque seus usuários são cativos e seus orçamentos são reflexões tardias, e ainda assim um assistente social ou atendente que luta contra um console quebrado passa esse atrito diretamente ao cliente como atrasos e erros. Perguntem quando foi a última vez que fizeram pesquisa sobre os seus próprios sistemas voltados à equipe, ou se presumem que, como os funcionários são pagos para dar um jeito, as ferramentas estão bem. Considerem que os bastidores são onde acontece a maior parte das falhas silenciosas de serviço, na redigitação manual e no contexto perdido nas passagens de bastão, nada disso visível às métricas de palco. Levem um funcionário de verdade para a sala e observem-no completar uma tarefa comum e depois rastreiem como a luta dele chega ao cliente. Se vocês nunca financiaram ferramentas internas como produto, essa provavelmente é a sua maior melhoria barata na qualidade de serviço de ponta a ponta.
Que métrica única de ponta a ponta nos diria se o serviço inteiro realmente funciona, e por que não a acompanhamos hoje? Para uma grande equipe essa pergunta é desconfortável porque a resposta honesta costuma ser que todo canal e departamento tem uma métrica local verde enquanto ninguém mede se a pessoa obteve o que veio buscar. As taxas de conclusão de formulários, os tempos de atendimento de chamadas e as contagens de chamados fechados lisonjeiam o dono que os reporta, e cada um pode continuar saudável enquanto o resultado conjunto falha numa fila de bastidores. Decidam uma medida de conclusão ou de tempo de ponta a ponta que acompanhe o usuário da primeira intenção ao resultado real e sejam claros sobre quem a instrumentará em sistemas que nunca foram construídos para compartilhar dados. Levem os painéis atuais por canal, o blueprint de uma jornada de alto volume e uma estimativa do abandono silencioso entre canais para que a lacuna entre o verde local e o vermelho de ponta a ponta fique visível. Em contextos corporativos e governamentais, combinem quem responde pelo número da jornada inteira e quem tem autoridade para agir sobre ele, porque uma métrica que nenhum dono isolado consegue mover é uma métrica que não muda nada.
Onde o nosso serviço força o usuário a se repetir, e quanto custaria construir uma versão “conte uma vez”? A captura duplicada de dados é o sinal mais claro de que um serviço está organizado em torno das suas fronteiras internas e não da necessidade do usuário, e é cara dos dois lados: o usuário digita de novo a mesma evidência a cada passagem de bastão, e cada departamento paga para recoletar e reverificá-la. A consideração concorrente é que o registro compartilhado que torna possível o “conte uma vez” exige integração entre sistemas e equipes que talvez não tenham histórico de confiar nos dados uns dos outros, então o custo de construção e o trabalho de governança de dados são reais. Levem um mapa de jornada anotado com cada ponto em que o usuário fornece informação que vocês já têm e uma contagem aproximada de quantos registros separados guardam o mesmo campo. Para um serviço governamental que abrange várias agências, acrescentem a base legal para compartilhar esses dados entre elas, já que o consentimento, a lei de privacidade e as regras de governança da informação decidem se o “conte uma vez” sequer é permitido antes de se perguntar se é acessível.
Quando o contexto é passado entre uma equipe, sistema ou canal, o que de fato viaja com o caso, e o que acontece quando a passagem falha? As passagens de bastão são onde os serviços quebram em silêncio, porque a falha é invisível para todos, exceto o usuário deixado esperando, e numa grande organização cada passagem cruza uma fronteira onde nenhum dono isolado se sente responsável pelo que é derrubado. Decidam deliberadamente que dados, histórico e status precisam se mover com um caso, se o lado receptor consegue vê-los e qual é o caminho de recuperação quando uma transferência empaca ou chega incompleta. Levem o blueprint de serviço de uma jornada real e rastreiem cada linha em que o caso muda de mãos, marcando que contexto é preservado e o que é redigitado ou perdido. Em serviços corporativos e do setor público sujeitos a acordos de nível de serviço ou a prazos estatutários de resposta, tratem cada passagem como um contrato explícito, com contexto acordado e uma alternativa definida, porque uma passagem não documentada é uma violação esperando para acontecer que nenhum painel avisará.

Perspectiva por setor

Startup. Com um punhado de pessoas e sem tempo para artefatos elaborados, façam o blueprint apenas da única jornada que carrega o seu valor central e apenas o bastante para ver onde o palco passa o bastão a bastidores lentos ou manuais. Façam numa lousa em uma tarde e não como um estudo de seis semanas. A sua vantagem é que o serviço inteiro vive em poucas cabeças, então consertar uma passagem quebrada é uma conversa e não uma negociação entre departamentos. Gastem essa vantagem antes de crescer as fronteiras que tornam caras as passagens.

Pequena empresa. Vocês não têm designer de serviços nem orçamento para um, então o movimento prático é percorrer a própria jornada como cliente, anotar todo ponto em que fazem alguém se repetir ou esperar um passo manual e consertar o pior. Prefiram ferramentas que já unem os seus canais (uma caixa de entrada compartilhada, um sistema de reservas que notifica a equipe) a construir uma integração que vocês não conseguem manter. Ao comprar um sistema, pesem quão bem ele passa o contexto ao passo seguinte, porque uma ferramenta barata que derruba os dados do cliente entre a venda e o atendimento custa mais em negócios repetidos perdidos do que poupa.

Grande empresa. O problema central é que uma única jornada cruza vendas, provisionamento, cobrança e suporte, cada um com métricas locais verdes e nenhum responsável pelo todo. Invistam em blueprints completos de serviço para as jornadas de alto volume e alto risco, nomeiem um dono de ponta a ponta com autoridade sobre as costuras e padronizem uma métrica de ponta a ponta que sobreviva à auditoria e conduza a priorização entre equipes. Tratem o registro compartilhado do caso e os consoles voltados à equipe como produtos financiados e façam de toda passagem entre equipes um contrato explícito, com contexto e níveis de serviço acordados.

Governo. Os serviços devem ser organizados em torno do evento de vida do cidadão e não da estrutura da agência, e sujeitos a padrões publicados de serviço, com transparência e responsabilização pública. As regras de contratação moldam o que vocês podem construir, então favoreçam registros compartilhados e padrões de “conte uma vez” onde existe base legal para compartilhar dados e documentem essa base antes de projetar o fluxo. Pesquisem com usuários reais, inclusive os mais vulneráveis, façam o blueprint dos bastidores entre agências e meçam a jornada inteira e não a fatia de cada agência, porque o público julga o serviço por ter obtido o resultado, não por qual departamento teve sucesso.

Exemplos

Startup. Uma startup de dez pessoas que vende um produto de seguro residencial se achava uma empresa de aplicativo, e seu aplicativo era genuinamente bom. Mas a evasão era alta e o suporte estava se afogando, então os fundadores fizeram o blueprint da jornada real de sinistros. Descobriram que o serviço real era o momento em que um cliente tinha um cano estourado à meia-noite: o aplicativo passava o bastão a uma fila de e-mail, que passava a um avaliador terceirizado que o cliente não enxergava, que ligava de volta em horário comercial de um número desconhecido que caía na caixa postal. O palco polido ficava sobre bastidores lentos e opacos, e o “momento que importa”, um sinistro estressante, era exatamente onde falhava. Consertar as passagens de bastão, dar ao cliente visibilidade da etapa do avaliador e tratar o fluxo de sinistros como parte do produto fez mais pela retenção do que qualquer nova funcionalidade do aplicativo.

Grande empresa. Uma empresa de telecomunicações vendia internet empresarial com um pedido online de dois minutos e um pesadelo de entrega de duas semanas. Vendas, provisionamento, engenharia de campo e cobrança eram cada um donos de um trecho da jornada e cada um atingia suas próprias metas, enquanto o cliente vivenciava pedidos repetidos das mesmas informações, janelas de visita perdidas e uma primeira fatura que não correspondia à cotação. O blueprint de serviço entre os quatro departamentos expôs as costuras: o contexto morria em cada passagem de bastão porque nenhum registro compartilhado do pedido seguia o cliente. A empresa nomeou um dono de ponta a ponta do pedido à ativação, construiu um registro compartilhado do caso que viajava com o pedido e reorganizou os incentivos das equipes em torno do resultado conjunto. As métricas locais mal mudaram. O tempo de ativação de ponta a ponta e a taxa de reclamações caíram bastante.

Governo. Um governo nacional redesenhou seu serviço de “falecimento de um familiar”, um dos eventos de vida mais difíceis que um cidadão enfrenta. Antes, o enlutado tinha de notificar separadamente a autoridade tributária, o serviço de pensões, a agência de veículos, o departamento de passaportes e o governo local, cada um com seu próprio formulário e cada um exigindo a mesma certidão de óbito. Organizando o serviço em torno do evento de vida e não das agências, a equipe construiu uma única jornada de “conte uma vez” que pegava a informação que uma pessoa inseria e a distribuía a todos os departamentos relevantes atrás da linha de visibilidade. Alinhando-se ao padrão de serviço do setor público, pesquisou com pessoas recém-enlutadas, fez o blueprint dos bastidores entre agências e mediu a jornada inteira e não a parte de cada agência. A conclusão subiu, o contato duplicado caiu e os cidadãos não precisaram mais reviver um luto uma dúzia de vezes.

Justificativa de negócio: motivações, ROI e TCO

O retorno do design de serviços vem de fechar as lacunas entre canais e equipes, porque é onde o valor vaza. As falhas de ponta a ponta são caras de modos que os painéis por canal escondem: uma jornada que se completa online mas falha nos bastidores gera um contato de suporte, um refazer e muitas vezes um cliente perdido, e nenhum desses custos cai no canal que parece bem-sucedido. Quando vocês medem e consertam o serviço inteiro, reduzem o esforço duplicado (os mesmos dados capturados cinco vezes), a demanda por falha (contatos causados puramente pelo serviço falhar da primeira vez) e a evasão de experiências que pareceram quebradas mesmo quando cada parte tecnicamente funcionou. Nas empresas, o ganho aparece como ciclos mais curtos do pedido ao recebimento e menos escalonamentos. No governo, aparece como menor custo de servir e maior conclusão bem-sucedida de serviços que as pessoas não conseguem obter em nenhum outro lugar.

O custo total de propriedade precisa pesar o custo de fazer design de serviços contra o custo muito maior da fragmentação que vocês já carregam. Os custos visíveis são a pesquisa, o blueprint, a coordenação entre equipes e às vezes o investimento em sistemas compartilhados e ferramentas da equipe. Os custos ocultos de não fazê-lo se espalham por orçamentos de suporte, operações e dano de reputação, que é exatamente por que a liderança os subestima: o orçamento de nenhuma equipe isolada mostra o preço total de uma passagem de bastão quebrada. Para defender o caso, ponham um número na demanda por falha e no trabalho duplicado numa jornada de alto volume, façam o blueprint e mostrem à liderança quanto do custo mora nas costuras entre as equipes existentes. Depois conduzam um piloto delimitado nessa jornada, meçam de ponta a ponta antes e depois e usem o resultado para defender as mudanças estruturais mais difíceis. Enquadrar o design de serviços como a remoção de custos que já estão sendo pagos, só que de forma invisível, tende a mover as partes interessadas de finanças e de governança mais que qualquer apelo à elegância.

Antipadrões e armadilhas

Ilhas de canais. Cada canal é projetado e medido por conta própria, de modo que a jornada parece bem em toda parte e não funciona de ponta a ponta em lugar nenhum.
Batom no palco. Uma UI polida parafusada em bastidores lentos ou manuais, de modo que a experiência quebra no momento em que o usuário precisa que os bastidores respondam.
Organograma como serviço. Serviços estruturados em torno dos seus departamentos em vez do objetivo do usuário, forçando o usuário a navegar as suas fronteiras internas.
Teatro de blueprint. Blueprints elaborados desenhados uma vez, admirados e nunca usados para mudar como o serviço de fato funciona.
Mapeamento só do caminho feliz. Jornadas e blueprints que ignoram a falha e a recuperação, que é onde os serviços reais doem.
Ferramentas da equipe negligenciadas. Tratar os sistemas internos voltados à equipe como de segunda classe, de modo que o atrito deles vaza direto para o cliente.
Amnésia de passagem de bastão. Contexto perdido em cada transferência entre equipe, sistema ou canal, de modo que o usuário reexplica sua situação de novo e de novo.
Métricas que lisonjeiam. Metas locais por canal que continuam verdes enquanto o resultado de ponta a ponta falha em silêncio.

Modelo de maturidade

Nível 1, Iniciar: Cada canal e equipe é projetado e conduzido isoladamente, de forma reativa. Ninguém é dono do serviço de ponta a ponta, não há mapa de jornada nem blueprint e as falhas de bastidores permanecem invisíveis até surgirem como reclamações. Os usuários rotineiramente se repetem entre canais porque ninguém olhou para o todo.
Nível 2, Desenvolver: Algumas jornadas são mapeadas e as piores lacunas entre canais são conhecidas, mas a prática é irregular e depende do entusiasmo individual. Os mapas de jornada existem mas raramente chegam aos bastidores, a propriedade ainda é por canal, as ferramentas voltadas à equipe são uma reflexão tardia e, onde o blueprint acontece, varia de equipe para equipe.
Nível 3, Padronizar: As jornadas-chave têm blueprint do palco aos bastidores com a equipe operacional, usando um método documentado aplicado de modo consistente na organização. Donos de serviço nomeados respondem de ponta a ponta, as passagens de bastão são contratos explícitos com contexto acordado, as ferramentas da equipe são projetadas deliberadamente e a abordagem é imposta e não opcional.
Nível 4, Gerenciar: O serviço é medido e controlado com dados. A conclusão de ponta a ponta, o tempo de ponta a ponta (incluindo as esperas invisíveis de bastidores), o esforço do usuário, a demanda por falha e o abandono de canal para canal são acompanhados contra linhas de base, e as falhas de passagem de bastão e a captura duplicada de dados são quantificadas e não presumidas. Os blueprints são mantidos atuais, os donos de serviço respondem por metas de ponta a ponta e as decisões de seguir ou não sobre mudanças repousam nessa evidência e não em métricas locais de canal.
Nível 5, Orquestrar: O design de equipes e o design de serviços estão alinhados de modo que a propriedade segue a jornada, e a organização é estruturada em torno de objetivos do usuário e eventos de vida e não de departamentos. As métricas de ponta a ponta conduzem a priorização, a organização continuamente faz o blueprint, mede e remodela juntas a experiência e as operações e adapta o serviço inteiro à medida que as necessidades dos usuários, os canais e as fronteiras entre equipes mudam.

Ideias para discussão

Quando uma jornada cruza várias equipes, é melhor nomear um dono de ponta a ponta ou redesenhar as equipes em torno da jornada, e o que determina a escolha?
Quanto da qualidade do seu serviço pode ser consertado com um melhor design de palco, e quanto exige mudar os bastidores ou o organograma?
Onde no seu serviço os usuários mais frequentemente precisam se repetir, e quanto custaria construir uma versão “conte uma vez”?
Como vocês financiam e priorizam ferramentas voltadas à equipe quando seus usuários são cativos e não podem votar com os pés?
Os serviços devem ser organizados em torno de eventos de vida ou de objetivos do usuário mesmo quando isso corta diretamente contra suas linhas de financiamento e de relatório?
Que métrica única de ponta a ponta melhor diria se o seu serviço inteiro está funcionando, e por que vocês não a acompanham hoje?

Principais conclusões

Projetem o serviço inteiro entre canais e ao longo do tempo, não uma tela, e lembrem que o usuário não se importa com onde caem as fronteiras das suas equipes.
Palco e bastidores são um só sistema. Uma ótima experiência é só tão boa quanto as operações por trás conseguem sustentar.
O blueprint de serviço é o seu artefato central: liga os pontos de contato do palco às pessoas, sistemas e passagens de bastão dos bastidores que os entregam.
O organograma aparece no serviço (lei de Conway), então o design de serviços e o design de equipes precisam andar juntos.
Tratem as ferramentas voltadas à equipe e as passagens de bastão entre equipes como partes de primeira classe do serviço, porque o atrito delas chega ao cliente.
Meçam o serviço de ponta a ponta, da primeira intenção ao resultado real, e organizem em torno do objetivo ou evento de vida do usuário e não dos seus departamentos.

Referências e leitura complementar

Marc Stickdorn and Jakob Schneider, This Is Service Design Thinking
Marc Stickdorn, Markus Edgar Hormess, Adam Lawrence, and Jakob Schneider, This Is Service Design Doing
Andy Polaine, Lavrans Lovlie, and Ben Reason, Service Design: From Insight to Implementation
Lynn Shostack, “Designing Services That Deliver,” Harvard Business Review
Matthew Skelton and Manuel Pais, Team Topologies
Melvin Conway, “How Do Committees Invent?“, Datamation
UK Government Digital Service, Service Manual and the Service Standard
U.S. General Services Administration, 18F Methods and the U.S. Digital Service Playbook
Nielsen Norman Group, articles on service blueprinting and customer journey mapping