Offering Map
Un Offering Map es un diagrama de lo que un servicio ofrece a sus usuarios, que desglosa la propuesta de valor general en grupos de funcionalidades. La colección Service Design Tools, que cita la tesis doctoral de Daniela Sangiorgi de 2004 en el Politecnico di Milano, lo describe como un artefacto que puede hacerse con palabras, imágenes o un gráfico sencillo y que siempre se escribe desde el lado del usuario. La fuente define el artefacto y no un procedimiento fijo de taller; los pasos que siguen son una forma práctica de construirlo con un equipo.
Guion de facilitación
- 1
Encuadrar la sesión: qué servicio, qué grupo de usuarios y para quién es el mapa terminado. Acordar la propuesta de valor en una frase y escribirla a la vista.
10 min - 2
Inventario en silencio. Todos escriben lo que el servicio hace por el usuario, un elemento por nota, usando el material de referencia que está sobre la mesa.
10 min - 3
Pegar las notas y agruparlas en áreas de oferta. Nombrar cada área con las palabras del usuario y eliminar duplicados.
15 min - 4
Estructurar cada área en funcionalidades y subfuncionalidades. Usar el segundo color de nota para los elementos previstos que aún no existen.
15 min - 5
Revisión desde el lado del usuario. Recorrer el mapa elemento por elemento, reformular el lenguaje interno como beneficio y pasar los habilitadores puros a una lista aparte.
15 min - 6
Tomar distancia. Marcar vacíos, solapamientos y áreas que no respaldan la propuesta de valor. Acordar quién dibuja la versión limpia y quién la revisa.
15 min
Consejos
Conviene poner a prueba cada elemento preguntando si un usuario lo describiría así a un amigo; si no, probablemente es un proceso interno y su lugar es un service blueprint.
Mantener la primera versión en texto simple y en una página, porque un mapa sencillo que la gente lee es más útil que uno detallado que no lee.
Distinguir entre lo que existe y lo que está previsto evita prometer a las partes interesadas un servicio que todavía no está.
Errores comunes
Enumerar procesos internos, sistemas y departamentos como ofertas, lo que convierte el mapa en un organigrama que los usuarios no reconocerían
Mezclar funcionalidades existentes y previstas sin marcarlas, de modo que las partes interesadas se van creyendo que el servicio ya hace todo lo que hay en la hoja
Bajar al detalle de subfuncionalidades en un área y quedarse en lo vago en otra, lo que distorsiona la imagen de dónde está el valor
Construir el mapa solo con el equipo del proyecto y no mostrarlo nunca a usuarios ni a personal de primera línea, con lo que las etiquetas reflejan jerga interna
Dar el mapa por terminado; hay que actualizarlo cada vez que cambia el servicio, o inducirá a error al próximo equipo que lo use
Variaciones
En una organización compleja o con varios servicios, construir un mapa por servicio y luego un mapa de nivel superior que muestre cómo se relacionan. Un mapa también puede llevarse como tabla estructurada o base de datos en lugar de dibujo: la página de Service Design Tools cita un proyecto del Essex County Council que registró cada servicio con atributos como pasos, plataformas tecnológicas, puntos de dolor y eventos vitales para encontrar patrones recurrentes entre servicios. Los equipos remotos pueden construir el mapa en una pizarra compartida con un marco por área de oferta. Para un servicio nuevo, partir de la propuesta de valor y derivar las funcionalidades; para uno existente, partir del inventario y trabajar hacia arriba.
Casos de uso
Cuándo usarlo
Los miembros del equipo describen el servicio de manera distinta según el departamento en el que trabajan
Un nuevo concepto de servicio existe como propuesta de valor y hay que convertirlo en un conjunto concreto de funcionalidades
Un servicio ha crecido durante años y nadie tiene una visión de conjunto de todo lo que hoy incluye
Hay que informar a desarrolladores, socios o a un cliente sobre lo que entra en el alcance de la implementación
Se está por dibujar un service blueprint y antes hace falta acuerdo sobre lo que contiene el servicio
Cuándo no usarlo
Hay que entender cómo se presta el servicio entre bastidores; un service blueprint muestra procesos, roles y sistemas
Se quiere describir la experiencia del usuario a lo largo del tiempo; para eso sirve un mapa de viaje del usuario
Todavía hay que averiguar qué necesitan los usuarios; antes van un Lienzo de Propuesta de Valor o entrevistas a usuarios, porque un Offering Map solo organiza lo que se pretende ofrecer
Hay que elegir qué funcionalidades construir primero; después del mapa conviene usar MoSCoW o una Matriz de Impacto y Esfuerzo
Métodos relacionados
Preguntas frecuentes
¿Qué es un Offering Map?▾
Un Offering Map es una herramienta de diseño de servicios que muestra lo que un servicio da a sus usuarios. Desglosa la propuesta de valor en grupos de funcionalidades y las presenta como texto, gráfico o imágenes. Se escribe desde la perspectiva del usuario y se usa para dar forma a un modelo de servicio y explicarlo.
¿En qué se diferencia un Offering Map de un service blueprint?▾
El Offering Map muestra lo que reciben los usuarios. Un service blueprint muestra cómo lo presta la organización, con acciones visibles y entre bastidores, roles y sistemas a lo largo de una línea de tiempo. Los equipos suelen hacer primero el Offering Map y después el blueprint de las ofertas más importantes.
¿Cuánto se tarda en crear un Offering Map?▾
La fuente no indica duración. Una primera versión para un servicio y un grupo de usuarios puede construirse en un taller de 60 a 90 minutos; esa es nuestra propia estimación. Dibujar una versión limpia y revisarla con las partes interesadas requiere tiempo adicional después de la sesión.
¿Qué formato debería tener un Offering Map?▾
No hay una plantilla fija. Los servicios sencillos pueden mapearse como lista de texto o árbol, y los más complejos como gráfico o panorama ilustrado. Conviene elegir el formato que la audiencia prevista pueda leer sin explicación.
¿De dónde viene el Offering Map?▾
Está documentado en la colección Service Design Tools. Esa página da como referencia la tesis doctoral de Daniela Sangiorgi sobre diseño de servicios, de 2004, en el Politecnico di Milano. La herramienta es de uso general en la práctica del diseño de servicios.
Planifica tu próximo taller con IA
Workshop Weaver te ayuda a combinar métodos como Offering Map en una agenda completa y cronometrada en minutos.
Probar gratisMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from Service Design Tools (reference: Daniela Sangiorgi, doctoral thesis, Politecnico di Milano, 2004).