Teams ask this more than any other question, usually after building a map that explains what hurts and not why.
The short version
A journey map describes the experience from the customer's side: what they do, feel, touch, and where it breaks.
A service blueprint adds what the organisation does to deliver that experience: frontstage people the customer sees, backstage processes they do not, and the systems underneath. A line of visibility separates the two halves.
Start with the journey
Always. The journey map is where the customer's voice is loudest, and it is the artefact everyone outside the service team can read. A blueprint without a journey above it is an org chart with arrows.
Add a blueprint when the cause is behind the counter
You will know the moment. A pain point on the map says "ID check takes three days". Nobody in the room can say why. That is the signal: the cause is in backstage handoffs and legacy systems, and you need operations at the table. The blueprint is how you invite them.
Keep them linked
Do not copy the journey into the blueprint. Nest the blueprint under the stage it explains with a linked-map lane. Readers click down into the detail; editors keep one source of truth. In Journima both use the same editor and the same lane types, so the blueprint's frontstage and backstage lanes sit a click below the customer's Verify stage.
One map, two audiences
The journey map goes to leadership. The blueprint goes to the teams who own the steps. Both place the same portfolio items, so when PAT-6 gets fixed, both maps show it.