O service blueprint (em tradução livre, "planta do serviço") é um diagrama que descreve um serviço em camadas: o que o cidadão faz, o que ele vê do atendimento e o que acontece por trás, nos bastidores e nos sistemas de apoio. Ele foi proposto pela executiva bancária G. Lynn Shostack no artigo "How to Design a Service", publicado em 1982 no European Journal of Marketing (v. 16, n. 1, p. 49-63), e divulgado ao público de gestão em "Designing Services That Deliver", na Harvard Business Review de janeiro-fevereiro de 1984. Para o gestor municipal, serve para entender por que um serviço demora ou falha: muitas vezes o problema não está na frente do balcão, mas em um passo invisível ao cidadão.
O que é o service blueprint
O artigo de Shostack abre falando dos sintomas de falha em serviços, como a camisa devolvida pela lavanderia com um botão quebrado ou o retorno de ligação prometido e nunca feito. A abordagem que ficou associada a ele é a de desenhar o serviço como um processo, com sequência, tempos e responsáveis, sempre a partir da perspectiva do cliente. Este texto é uma explicação própria, sem vínculo com a revista ou com a autora.
Na forma mais difundida, o blueprint tem estes elementos, segundo as descrições acadêmicas consultadas.
- Ações do cidadão: o que a pessoa faz ao longo do serviço.
- Ações de linha de frente: o que o servidor faz diante do cidadão.
- Ações de bastidor: o que o servidor faz fora da vista do cidadão, como conferir um documento ou registrar um pedido.
- Processos de apoio: o trabalho de quem não atende o público, mas sem o qual o serviço não acontece, como a tecnologia, o jurídico ou o almoxarifado.
- Linha de visibilidade: a divisória entre o que o cidadão vê e o que não vê.
- Linha de interação e linha de interação interna: divisórias opcionais entre o cidadão e a organização e entre a frente e o apoio.
Muitos blueprints acrescentam ainda evidências físicas (formulário, protocolo, senha), tempos de espera e emoções do usuário. As descrições variam, e não há um modelo único.
Por que funciona no setor público
O cidadão enxerga só a ponta do serviço: o guichê, o sítio eletrônico, a resposta final. A demora, porém, costuma estar atrás da linha de visibilidade: um parecer parado, um sistema que não conversa com outro, uma assinatura em fila. O blueprint obriga a equipe a colocar todos esses passos no mesmo desenho e a ver quem depende de quem.
Também ajuda a separar responsabilidades. Quando o mapa mostra que o atraso está em um processo de apoio, a conversa deixa de ser sobre "o atendente que demorou" e passa a ser sobre o fluxo. Além disso, o desenho é um bom ponto de partida para simplificar, eliminar etapas e definir prazos de cada área.
Como aplicar na prefeitura, passo a passo
- Escolha um serviço e um cidadão típico. Por exemplo, a emissão de alvará de funcionamento para um pequeno comércio.
- Liste as ações do cidadão. Do primeiro contato ao recebimento do resultado, na ordem em que ocorrem.
- Para cada ação, escreva o que a prefeitura faz na frente. Quem atende, onde, com que documento.
- Escreva os bastidores. Quem analisa, quem assina, quem registra, quais sistemas e quais setores participam.
- Marque tempos e pontos de espera. Anote quanto cada passo leva, na prática, e onde o processo para.
- Procure falhas e redundâncias. Passos repetidos, documentos pedidos duas vezes, setores que não conversam.
- Proponha mudanças e teste. Ajuste o desenho, defina responsáveis e prazos e acompanhe o resultado.
Modelo para preencher
Use a grade abaixo, com uma coluna por etapa do serviço. Adapte à legislação e à realidade do seu órgão.
| Camada | Etapa 1 | Etapa 2 | Etapa 3 | Etapa 4 |
|---|---|---|---|---|
| Ações do cidadão | ||||
| Linha de frente (visível) | ||||
| Bastidores (invisível) | ||||
| Processos de apoio e sistemas | ||||
| Tempo e pontos de espera |
Exemplo prático
Exemplo hipotético. Uma prefeitura recebe queixas de que o pedido de uma certidão leva muito tempo. A equipe desenha o blueprint e percebe que o cidadão faz apenas três ações, mas que, nos bastidores, o pedido passa por quatro setores, dois deles com análise em papel. Em um deles, o processo espera dias por uma assinatura. A prefeitura combina com a área jurídica a possibilidade de assinatura eletrônica, define um prazo interno por setor e passa a informar o cidadão sobre cada etapa. Nenhuma dessas mudanças aparece no guichê, mas o tempo de espera cai.
Erros comuns
- Desenhar o fluxo ideal e não o real. Mapeie o que acontece de fato, conversando com quem executa.
- Esquecer a perspectiva do cidadão. O ponto de partida é a experiência dele, não o organograma.
- Mapear tudo de uma vez. Comece por um serviço e um tipo de usuário.
- Deixar o mapa na gaveta. O desenho só vale se resultar em mudanças com responsável e prazo.
- Ignorar as exceções. Casos especiais, como pessoas com deficiência, podem exigir caminhos diferentes.
Perguntas frequentes
Qual a diferença entre blueprint e fluxograma?
O fluxograma mostra a sequência de atividades. O blueprint organiza essas atividades por camadas, separando o que o cidadão vê do que não vê.
E a jornada do cidadão?
A jornada foca a experiência e as emoções da pessoa. O blueprint acrescenta o que a organização faz por trás. Os dois se complementam.
Precisa de software?
Não. Um quadro, papel e post-its bastam. O valor está na conversa entre as áreas.
Quem deve participar?
Quem executa cada etapa, quem atende o público e quem cuida dos sistemas e do jurídico.
