Service blueprint (plano de servicio)
Coloca arriba los pasos del cliente y muestra debajo todo lo que hace la organización, a la vista y fuera de ella, para que cada paso ocurra.
- Tiempo
- 90 min
- Personas
- 4–8
- Tipo de trabajo
- Enmarcar · Planificar
En resumen
Un service blueprint es un diagrama de un servicio que alinea lo que hace el cliente con el personal de primera línea, el trabajo interno y los sistemas de soporte de cada paso. Para construirlo, elige un escenario, mapea primero las acciones del cliente, añade los carriles inferiores y marca puntos de fallo, esperas y traspasos entre equipos.
Qué es
Un service blueprint es un mapa de un servicio dibujado en carriles horizontales. Los carriles superiores muestran el lado del cliente: la evidencia física o digital con la que se encuentra, como una carta, un SMS o una ventanilla, y las acciones que realiza. Debajo están el personal y los sistemas que el cliente ve, la parte visible o frontstage. Una línea de visibilidad los separa de la parte interna o backstage: las personas y los pasos que el cliente nunca ve. El carril inferior recoge los procesos de soporte, como sistemas informáticos, normativas y otros departamentos, de los que depende todo el servicio.
El método lo presentó G. Lynn Shostack en la Harvard Business Review en 1984 y hoy es una de las herramientas centrales del diseño de servicios. Mientras un mapa de experiencia te dice cómo se siente la experiencia, un blueprint te dice por qué funciona o falla, porque muestra el trabajo oculto que produce cada momento. En esta ficha registras, para cada paso, la evidencia, las acciones del cliente, la parte visible, la parte interna, los procesos de soporte, los puntos de fallo y las esperas.
Cuándo usarlo
Úsalo cuando
- Los clientes se quejan de retrasos o de visitas repetidas y nadie sabe decir en qué parte de la organización se va el tiempo.
- Varios departamentos son dueños de una parte de un servicio y nadie lo ha visto completo en una sola página.
- Vas a rediseñar o digitalizar un servicio y necesitas saber a qué pasos internos afectará un cambio.
- Tienes un mapa de experiencia que muestra puntos de dolor y ahora necesitas encontrar sus causas dentro de la organización.
- Un equipo, proveedor o sistema nuevo asume una parte del servicio y hay que acordar los traspasos antes de la puesta en marcha.
Evítalo cuando
- Todavía no sabes cómo viven los clientes el servicio. Haz entrevistas u observación primero o los carriles superiores serán conjeturas.
- La pregunta es sobre la red más amplia de socios y valor, no sobre un servicio. Encaja mejor un mapa de sistema o un mapa de ecosistema.
- El proceso es puramente interno, sin momentos de cliente, como el cierre de mes. Un diagrama de flujo del proceso es más sencillo y suficiente.
Qué necesitas
- Tiempo
- Unos 90 minutos para un escenario con personas que conocen el trabajo; prevé una segunda sesión para contrastarlo con casos reales.
- Personas
- De 4 a 8 personas: alguien que hizo la investigación con clientes y al menos una persona de cada equipo que interviene en el servicio, incluido personal de primera línea.
- Materiales
- Una pared larga o un tablero compartido con los carriles dibujados, notas adhesivas de dos o tres colores, notas del recorrido o de la investigación y algunos expedientes reales para rastrear.
Cómo aplicarlo
Paso 1: Elige un escenario y sus límites
Acuerden qué cliente, qué servicio y qué situación van a mapear, por ejemplo "un hogar que solicita una nueva acometida de agua para una villa terminada". Escribe dónde empieza y dónde termina el escenario. Un blueprint por escenario lo mantiene legible; un caso poco habitual, como una solicitud rechazada, tendrá más adelante su propio blueprint.
Paso 2: Mapea primero las acciones del cliente
Rellena de izquierda a derecha el carril de acciones del cliente con lo que mostró la investigación, no con lo que dice el procedimiento que debería pasar. Usa una nota por acción, escrita como verbo: "envía el formulario", "espera la llamada", "paga la tasa". Encima de cada acción, anota la evidencia que el cliente ve o tiene en ese momento, como un SMS, un recibo o una tarjeta de visita técnica.
Paso 3: Añade la parte visible
Para cada acción del cliente, escribe con qué persona, pantalla o canal trata directamente. Deja la celda vacía si no hay nada; una celda visible vacía durante una espera larga ya es un hallazgo. Traza con claridad la línea de visibilidad bajo este carril.
Paso 4: Rastrea el trabajo interno y de soporte
Pide a quienes hacen el trabajo que rellenen el carril interno: las comprobaciones, aprobaciones, programaciones y entradas de datos que ocurren fuera de la vista. Debajo, añade los procesos y sistemas de soporte de los que depende cada paso. Recorre el mapa con uno o dos expedientes reales para comprobar que no falta nada.
Paso 5: Dibuja los traspasos
Dibuja una flecha cada vez que el trabajo pasa de un equipo, sistema o persona a otro. Cuéntalas. En los traspasos es donde los casos esperan en colas, se pierden o se devuelven, así que merecen su propio color en la pared.
Paso 6: Marca los puntos de fallo y las esperas
Pon una marca roja en cada paso donde las cosas suelen ir mal y escribe el tiempo de espera habitual entre pasos, con datos reales cuando los tengas. Vincula cada punto de fallo al momento del cliente que provoca. Es la parte del blueprint que la dirección lee primero.
Paso 7: Acuerden qué cambiar y quién se encarga
Elijan los dos o tres puntos de fallo con mayor efecto en los clientes y nombren un responsable para cada uno. Fotografía o transcribe el blueprint, ponle fecha y guárdalo donde los equipos puedan actualizarlo a medida que cambia el servicio.
Ejemplo práctico
Una empresa regional de aguas tardaba de media 34 días hábiles en conectar un hogar nuevo, frente a un objetivo publicado de 15. Los clientes llamaban al centro de contacto una media de cuatro veces por solicitud para pedir noticias, y el mapa de experiencia de la empresa mostraba largos silencios que nadie sabía explicar.
Siete personas se reunieron durante 90 minutos: una investigadora de clientes, un agente del centro de contacto, una planificadora de acometidas, un técnico topógrafo, un responsable de facturación, una analista de sistemas y el responsable de acometidas. Eligieron el escenario "nueva acometida para una villa terminada con licencia de obra aprobada".
El carril del cliente tenía solo seis acciones, desde la solicitud en línea hasta la primera factura. El carril interno necesitó 19 notas y mostró nueve traspasos entre cuatro equipos.
Al rastrear dos expedientes reales se vio que las visitas técnicas se programaban en un único lote semanal, así que una solicitud que llegaba un martes podía esperar seis días antes de que nadie la mirara.
El carril visible estaba vacío durante 22 de los 34 días. En ese tiempo el cliente no recibía ningún mensaje, lo que explicaba la mayoría de las llamadas.
Apareció un punto de fallo en el pago: la tasa se calculaba después de la visita técnica, pero el enlace de pago caducaba a las 48 horas, y aproximadamente uno de cada cinco clientes no llegaba a tiempo y tenía que empezar de nuevo.
El equipo acordó tres cambios con responsables: programación diaria de visitas técnicas, un SMS automático en cada hito interno y un enlace de pago válido durante 14 días. Planificaron medir los días hasta la conexión y las llamadas por solicitud durante los tres meses siguientes.
IlustrativoConsejos y errores
Consejos
- Parte de casos reales, no del manual de procedimientos. La distancia entre ambos suele ser donde están los problemas.
- Mantén el carril del cliente breve y sencillo. Si tiene más notas que el carril interno, quizá estés mapeando pantallas en lugar de acciones.
- Invita al personal de primera línea y deja que escriba él mismo las notas internas. Conoce los atajos que el proceso oficial deja fuera.
- Pon tiempos en las flechas de espera. Un blueprint con cifras mueve a la dirección más rápido que uno solo con cajas.
Errores frecuentes
- Mapear varios tipos de cliente a la vez, de modo que los carriles se llenan de ramas condicionales y nadie puede leer el resultado.
- Detenerse en la línea de visibilidad, lo que convierte el blueprint en un mapa de experiencia y oculta las causas.
- Dibujar el servicio como se supone que funciona y no como funciona de verdad.
- Dejar el blueprint en una pared después del taller, de modo que en pocas semanas está desactualizado y nadie se encarga de los arreglos.
Con qué terminas
Sales con un blueprint fechado de un escenario que muestra cada paso del cliente, el trabajo visible e interno que hay detrás, los traspasos y los puntos de fallo, además de dos o tres cambios acordados con responsables. El siguiente paso suele ser una matriz de puntos de contacto para planificar canales, o un diagrama de flujo del proceso para cualquier paso interno que necesite un rediseño detallado.
Preguntas frecuentes
¿Qué diferencia hay entre un service blueprint y un customer journey map?
Un customer journey map sigue al cliente y registra lo que hace, piensa y siente. Un blueprint toma esos mismos pasos y añade el personal, los sistemas y los procesos de soporte que hay detrás, para que veas por qué cada momento sale bien o mal. Muchos equipos construyen primero el mapa de experiencia y después el blueprint.
¿Qué es la línea de visibilidad en un service blueprint?
Es la línea que separa lo que el cliente puede ver, como un empleado de ventanilla o una web, del trabajo interno que no ve, como aprobaciones y programación. Mover trabajo a través de esa línea, en cualquier dirección, es una de las principales decisiones de diseño que un blueprint ayuda a tomar.
¿Qué nivel de detalle debe tener un service blueprint?
El suficiente para que alguien de cada equipo reconozca su propio trabajo y pueda señalar dónde esperan los casos. Para una primera versión, de 6 a 12 acciones del cliente suele ser lo adecuado. Si un solo paso interno necesita más detalle, mapéalo aparte con un diagrama de flujo del proceso.
Ficha de la herramienta
La ficha de trabajo que rellena tu equipo, una casilla por campo.
- Evidencia
- Acciones del cliente
- Parte visible (frontstage)
- Parte interna (backstage)
- Procesos de soporte
- Puntos de fallo
- Tiempos de espera