How to run a workshop for reluctant teams in a bank

Articles › Custom workshops

A workshop for reluctant teams works when the session runs on the team's own live work, not exercises. Pick one real task, take a before number such as turnaround time, and let branch and operations staff fix something in the room that they keep on Monday.

Training budget approved, list of names attached, and nobody on that list asked to be there. The names belong to people who did not ask to attend. Branch staff, back office, case processors. Some of them have sat through sessions before and used none of it the following Monday.

Here is how those sessions run so the team leaves with one fix they keep using, and a number to show for it.

On-Off Group has run workshops for Philippine banks and insurers since 2015, most of them with people who were told to be in the room. The pattern below comes from those sessions.

What mandatory attendance looks like on a normal day

The invite lands with two days blocked out, no agenda, and a title with the word training in it. The team lead is already behind on cases and now loses two staff for a week between the session and catching up.

So people arrive and protect themselves. Phones face up. One person answers every question. The rest wait to be told the answer so they can write it down and go back to work.

At the end, the feedback forms come back positive. Everyone says it was useful. Nobody can name a thing they will do differently on Monday, because nothing in the two days was about their own cases.

That is the thing to plan around. A room can be lively for two days and leave no trace in the work. The test is the first real task after the room empties.

Bring the team's own work into the room

The change that does most of the work is to stop using invented examples. No fictional customer called Juan. No generic persona exercise.

Instead, take the onboarding flow the team handles every day, or the last twenty returned applications, or the actual screens branch staff use to open an account. Put those on the wall. Ask the people who work them what goes wrong and where cases sit waiting.

This changes who the expert is. The processor who handles these cases all week knows more about the failure points than anyone at the front of the room. Once that is obvious, people stop waiting to be told the answer.

It also makes the session hard to dismiss. A team can say a case study about a coffee chain is not like us. They cannot say that about their own backlog.

The material gets built out of your own cases before day one, so ask for that when you scope it.

Take a before number, even a rough one

Most teams have no baseline. When the boss asks whether the training worked, the honest answer is a shrug, and a shrug is what kills the budget for next year.

Pick one number the team already argues about. Turnaround time on an onboarding case. Share of applications returned for missing documents. Days a decision sits in a queue. Measure it in the week before the session, even if the measurement is twenty cases counted by hand on a spreadsheet.

Then measure the same twenty-case sample again after the session. If it moved, you have something real to show. If it did not move, you know the session did not reach the work, which is also worth knowing before you buy more of it.

We ran a series of five-day design sprints with a large insurer, and the before numbers were what made the result provable. Customer journeys that used to take 26 weeks were designed and tested with customers in two weeks, and live in four. Completion rates on the new journeys rose 80 percent, measured by the client, and the old drop-off points disappeared. None of that would have been provable without the before numbers.

Let the room change one thing, not just learn about it

People switch on when they are allowed to change something, not just suggest it.

So build the session around one decision the team can make and keep. Rewrite the document checklist branch staff hand over. Redraw the approval steps for one product and cut two of them. Draft the message customers get when a case is delayed.

Give the output a name and an owner before people leave. Otherwise it becomes a photo of sticky notes in a shared drive.

The person pushing back is worth listening to here. The person who spent the morning saying it will never work in branch is the one who knows which steps head office added and why nobody follows them. Listen to that person on purpose. They are usually right about the constraint.

When processors, branch, product and risk are in one room together, the session has to be run so they are all working on the same cases.

Decide whether you need a workshop at all

Sometimes the honest answer is no. If the problem is that four managers disagree about which customer journey to fix first, putting thirty staff in a room for two days will not settle it. You need the four managers in a shorter session with the numbers in front of them.

Sort that before the invites go out, because a workshop sent into an unsettled argument produces a plan nobody owns.

The other thing to check is sequence. If the onboarding flow loses people at step three, training staff to work faster inside that flow will not recover them, and adding AI to it will just automate the same failure at speed. Fix the step first, then train on the version that works.

Some of the people in those 2015 insurer workshops are senior in the industry now. They still remember the sessions that used their own cases.

What to do this week

  • Pick one task the team does every day, such as one onboarding case type, and make that the whole scope of the session.
  • Count a before number by hand on the last twenty cases, and write it down where your boss can see it.
  • Ask two of the most reluctant people on the list what they would fix, and put their answers on the agenda.
  • Cancel any exercise that uses an invented customer, and replace it with real cases from the backlog.
  • Name the one change the team is allowed to make and keep, with an owner, before anyone leaves the room. More workshop scripts, and the projects they came from, are at onoffgroup.com.

More on Custom workshops

Questions people ask

Why do mandatory workshops fail?
Because attendance is the only thing being measured. A full room and a good feedback score tell you people showed up, but nothing about whether anyone did the work differently the following week.

What should we measure before a workshop?
One number the team already argues about, such as turnaround time on an onboarding case, the share of applications returned for missing documents, or how long a branch waits for a decision. Take it before the session so you can compare later.

How long should a session be for operations staff?
Long enough to get through one real task, usually half a day to two days depending on the task. Length matters less than whether the team leaves with something they built on their own cases.

Is design thinking training useful for bank teams?
It is, when the exercises use the team's own customer journey and cases. Generic exercises with invented personas are the fastest way to lose a room that did not choose to be there.

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 custom workshops.