How we scope an operational assessment

Requests for an operational assessment usually start with a feeling at the top of the company. Operations seems slower or more expensive than it should be, or someone doubts it will cope with the next stage of growth, and they want an outside view.

That is a reasonable thing to want, and it is impossible to assess in three weeks. We work in four stages: Discovery, Assessment, Implementation and Ongoing Support. The assessment itself takes two to three weeks, so most of the Discovery conversation goes into narrowing the question and agreeing what we will leave out.

Starting from a decision

We ask what decision the assessment should inform, and who will make it. The answers get concrete quickly once you push. Should we hire four more people into disputes, or fix the evidence process first? Can our reconciliation setup take on a second sponsor bank? Is the case management tool the problem, or the way we use it?

A question like that gives the work edges. It tells us which process to follow from end to end, which teams sit along it and what data we will need. If the question is about disputes, we follow a chargeback from the moment the notification arrives to the moment the case closes and the money lands in one ledger or another, including the steps that happen in customer support and risk. That flow tends to belong to nobody, for reasons we set out in an earlier post on chargebacks.

When nobody can name the decision, we usually suggest waiting. An assessment that ends with everyone agreeing the findings are interesting, and nothing changing, is a poor use of your team's time, and your team is the one giving up hours to talk to us.

If the answer would not change a decision someone is about to make, the assessment is either too early or pointed at the wrong process.

What the two to three weeks contain

The first week is mostly interviews. We talk to the person accountable for the process, then to team leads and to the analysts who work the queue, across shifts if there are shifts. We also talk to the teams on either side of it, the ones who hand work in and the ones who receive it. Those neighbors usually know where the process leaks, because they get the phone call when it does.

Then we sit with people while they work. Clients are sometimes wary of this part, and it is the one we would keep if we could keep only one. Interviews tell you how people believe work moves. Sitting next to an analyst while they clear a queue shows you the second screen, the spreadsheet tab for items the system cannot hold, the reference copied by hand from the bank portal into the case tool, and the chat channel where someone asks what a status code means. None of that appears on a process map.

We send a data request on the first day, because it always takes longer than anyone expects. For a queue-based process it usually covers:

• A case or ticket export for the last three months, with created, assigned and closed timestamps and every status change in between
• The aging report for whatever sits unresolved, such as unmatched items or open investigations
• Rotas and headcount by team for the same period, so volume can be set against the hours available
• Service level reports you send to partners or receive from them
• Manual adjustments, write-offs and journal entries, if the scope touches finance

The data is never as clean as the team hopes. Different shifts use status fields differently, timestamps go missing when a case is reopened, and a queue that looks like one queue in the tool turns out to be three. By the end of the first week we tell you which questions the data can answer and which we will have to estimate from observation, so the method holds no surprises when the report arrives.

Weeks two and three go on analysis and checking. We play findings back to the people we interviewed before anything goes into the report. If an analyst tells us we have misread how returns are handled, it is far better to hear it on a Tuesday afternoon than in front of the COO.

What you get at the end

You get a written report short enough to read in one sitting, and a working session to go through it with the people who will act on it. The report opens with the process as it runs today, unofficial steps included, with the points where work waits marked and measured where the data allows. Findings follow, each tied to its evidence: an interview, an observation or a number from the data pull. Then comes a prioritized list of changes, each with a rough effort, an owner and what we expect it to change. The last section covers what we could not assess, and why.

That last section matters more than it sounds. Three weeks is a snapshot. If your peak falls in December and we assess in September, we see the process under ordinary load and say so. If most of a process runs inside your sponsor bank or program manager, we see your side of it and the handoffs. We will not guess at what happens behind their portal.

What we leave out

There is no 90-slide deck. Nobody reads slide 60, and a deck that size mostly exists to show effort. We also avoid comparing you with industry benchmarks we cannot source, and we do not recommend replacing a system until we have watched people use it.

You should also know that GSO does implementation work, so we have an interest in what comes after an assessment. We handle that by writing recommendations your own team, or another firm, could pick up and carry out without us. If the honest answer is that your team can fix most of it in a quarter, the report says so.

If you are considering an assessment, the first step costs nothing. Write down the decision it should inform, who will make it and by when. If that sentence is hard to write, you have found the first thing to work on.

Discuss your operations