What a design sprint costs, and who needs to be in the room

On-Off Group

October 2026

The main design sprint cost is not the facilitation. It is five days of the right people's time, usually six to eight of them, plus a fee for running it. What you get back is a tested customer journey instead of another set of slides.

Before you ask your boss for five days of people's time, here is what you pay for, how long it takes, and what you have to bring on day one.

If you have already run journey mapping sessions and now have to show your boss something real, this is the part nobody costs properly.

The short answer: the fee is the smaller number. The bigger cost is five days out of the calendars of six to eight people who are hard to book.

Most of the cost is people's time, not the fee

When someone asks what a design sprint costs, what usually worries them is the email they have to send, asking a head of product, a developer, a compliance person and two branch staff to block out a full week.

Five days of six to eight people is thirty to forty working days, closer to two months of one person's time. Next to that, the facilitation fee is rarely the thing that decides it.

So it helps to say what the week replaces. Doing nothing still costs you: months of meetings about scope, a set of slides, then a build that starts from assumptions nobody tested. A large insurer we worked with had customer-facing web journeys that used to take six months or more to get designed and live. With a series of five-day sprints, those journeys were designed and tested with customers in two weeks and live in four. Twenty-six weeks down to four.

That is the comparison to put in the request, not the day rate.

Who actually needs to be in the room

The usual way a week goes wrong is that the person who can say yes never turns up, or turns up on Friday.

Who we ask for: someone who can make the decision and will be there at the start and the end. Someone who owns the business area. A designer. A developer, or anyone who knows what the systems can and cannot do. And at least one person who talks to customers every day, usually branch or contact centre staff.

Six to eight people. More than ten and the room slows down. Fewer than five and you spend the week guessing at the bits nobody in the room is responsible for, usually the systems or the compliance side.

The decision maker is the awkward one. If they can only give you two hours, take them at the start of Monday and the end of Thursday. Otherwise a good week gets parked because the person who could approve it only heard about it second hand.

The hour by hour breakdown of the five days is here: What is a design sprint and what you have at the end of it.

Run the five days back to back, not one day a week

A sprint is five consecutive days. Teams often ask to spread it over three weeks, one day at a time. It does not work well. Each session starts with re-explaining where you got to, and the customer test at the end tends to get dropped because nobody can book users in time.

After the week you are not finished. Expect around two weeks in total to a tested design, and about four weeks to live if the build is already lined up. That is what happened on the insurer's journeys.

One warning on the diary. Month-end close, audit season and school holidays will eat your week. Book the dates before you settle the problem.

What you bring on day one

Three things. Most teams bring the first two.

One customer journey, narrow enough to say in a sentence. "Onboarding a new savings account through the app" works. "Improve customer experience" does not.

Whatever you already know. Complaint logs, drop-off data, the notes from the last journey mapping session, what branch staff say when they are annoyed. It does not need to be tidy.

And a current number. Turnaround time on the flow as it stands, completion rate, or calls about one step. Without it, your boss asks whether the pilot worked and all you can do is shrug. On the insurer's journeys, completion rates rose 80 per cent and the old drop-off points disappeared. They had the completion rate written down before the sprint, which is the only reason anyone can quote that 80 per cent now.

If your team has not worked this way before, a shorter session first is often cheaper than a full week. Design thinking training for cross-functional bank teams covers what that looks like.

What you have at the end of the week

A prototype real customers have used. Notes on where they got stuck. A decision: build it, change it, or stop.

You do not have a finished product, and you do not have a roadmap. If the week ends in a roadmap, nobody built anything and nobody tested it with a customer.

The thing worth showing your boss is usually the recording of a customer getting stuck on a step, next to the version where they get through it. A slide showing how the flow will look one day does not do that. And with the before number, when someone asks in three months whether the pilot moved anything, you have an answer.

Sometimes the gap turns out to be small. Say so anyway. You can still plan with a small number.

What to do this week

Pick one customer journey and write it in a single sentence.
Find the current number for that journey: turnaround time, completion rate, or call volume on one step. If it does not exist, get it measured before the sprint.
List the six to eight names you need, and check who can actually clear five days.
Get the decision maker to commit to Monday morning and Thursday afternoon, in writing.
Book the week around month-end close and audit, not through it.

Questions people ask

How many people do we need in the room?
Six to eight is enough: someone who can decide, someone from the business area, a designer, a developer or someone who knows the systems, and someone who deals with customers daily, such as branch or contact centre staff.

Do all five days have to be consecutive?
Yes, keep them together. Spreading the days over three weeks means re-explaining the problem each time and losing the customer test at the end, which is the part that produces evidence.

What should we bring on day one?
One customer journey narrow enough to describe in a sentence, whatever research and complaint data you already have, and a current number such as turnaround time or completion rate so you can compare afterwards.

What do we have at the end of the week?
A prototype that customers have used, notes on where they got stuck, and a decision on whether to build, change it or stop. Not a roadmap.

On-Off Group trains teams, tests products with real customers, finds where a transformation has stalled and builds what gets it moving, for banks, insurers and enterprises in the Philippines, since 2015. How we help with design sprints.