Offering Map
An Offering Map is a diagram of what a service provides to its users, breaking the overall value proposition down into clusters of features. The Service Design Tools collection, which credits Daniela Sangiorgi's 2004 doctoral thesis at Politecnico di Milano, describes it as an artefact that can be made of words, pictures or a simple graph and that is always written from the user's side. The source defines the artefact and not a fixed workshop procedure; the steps below are a practical way to build one with a team.
Facilitation script
- 1
Frame the session: which service, which user group, and who the finished map is for. Agree the one-sentence value proposition and write it up.
10 min - 2
Silent inventory. Everyone writes what the service does for the user, one item per note, using the reference material on the table.
10 min - 3
Post and cluster the notes into offering areas. Name each area in the user's words and remove duplicates.
15 min - 4
Structure each area into features and sub-features. Use the second note colour for items that are planned and do not exist yet.
15 min - 5
User-side check. Go through the map item by item, rephrase internal language as a benefit and move pure enablers to a side list.
15 min - 6
Step back. Mark gaps, overlaps and areas that do not support the value proposition. Agree who draws the clean version and who reviews it.
15 min
Tips
Test each item by asking whether a user would describe it that way to a friend; if not, it is probably an internal process and belongs on a service blueprint.
Keep the first version in plain text on one page, since a simple map that people read is more useful than a detailed one they do not.
Distinguishing between what exists and what is planned avoids promising stakeholders a service that is not there yet.
Common pitfalls
Listing internal processes, systems and departments as offerings, which turns the map into an organisation chart that users would not recognise
Mixing existing and planned features without marking them, so stakeholders leave believing the service already does everything on the sheet
Going into sub-feature detail in one area and staying vague in another, which distorts the picture of where the value lies
Building the map only with the project team and never showing it to users or front-line staff, so the labels reflect internal jargon
Treating the map as finished; it needs updating whenever the service changes or it will mislead the next team that uses it
Variations
For a complex or multi-service organisation, build one map per service and then a top-level map that shows how they relate. A map can also be kept as a structured table or database instead of a drawing: the Service Design Tools page cites an Essex County Council project that recorded each service with attributes such as steps, technology platforms, pain points and life events to find recurring patterns across services. Remote teams can build the map on a shared whiteboard with one frame per offering area. For a new service, start from the value proposition and derive the features; for an existing one, start from the inventory and work upwards.
Where it fits
When to use it
Team members describe the service differently depending on which department they work in
A new service concept exists as a value proposition and has to be turned into a concrete set of features
A service has grown over years and nobody has an overview of everything it now includes
You need to brief developers, partners or a client on what is in scope for implementation
You are about to draw a service blueprint and need agreement on what the service contains first
When not to use it
You need to understand how the service is delivered behind the scenes; a service blueprint shows processes, roles and systems
You want to describe the user's experience over time; use a user journey map
You still need to find out what users need; a Value Proposition Canvas or user interviews come first, because an offering map only organises what you intend to provide
You need to choose which features to build first; follow the map with MoSCoW or an Impact & Effort Matrix
Related methods
Frequently asked questions
What is Offering Map?▾
An Offering Map is a service design tool that shows what a service gives its users. It breaks the value proposition into clusters of features and presents them as text, a graph or pictures. It is written from the user's perspective and is used to shape and explain a service model.
How is an Offering Map different from a service blueprint?▾
The Offering Map shows what users receive. A service blueprint shows how the organisation delivers it, with front-stage and back-stage actions, roles and systems along a timeline. Teams often make the offering map first and then blueprint the most important offers.
How long does it take to create an Offering Map?▾
The source states no duration. A first version for one service and one user group can be built in a workshop of 60 to 90 minutes, which is our own estimate. Drawing a clean version and reviewing it with stakeholders takes additional time after the session.
What format should an Offering Map have?▾
There is no fixed template. Simple services can be mapped as a text list or tree, and more complex ones as a graph or illustrated overview. Choose the format the intended audience can read without explanation.
Where does the Offering Map come from?▾
It is documented in the Service Design Tools collection. That page gives Daniela Sangiorgi's 2004 doctoral thesis on service design at Politecnico di Milano as its reference. The tool is in general use in service design practice.
Plan your next workshop with AI
Workshop Weaver helps you combine methods like Offering Map into a complete, timed agenda in minutes.
Try it freeMethod 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).