Scaling an agent network without adding operations staff

Context

Access Closa is Access Bank’s agent banking network, and it runs on the Closa 2.0 platform. The network grows by onboarding new agents: people and businesses who serve customers on the Bank’s behalf.

Agent onboarding was staff-led. The Bank’s own operations team handled each new agent, so the team’s capacity set the pace at which the network could grow. I worked on this as Business Analyst and Project Manager in Financial Inclusion.

The problem

A staff-led process scales with headcount. Every new agent added work for the same operations team, and as the network grew that team became the bottleneck. The alternative to hiring more operations staff was to change who does the work.

The question was how to keep growing the network without the Bank’s operations team sitting in the middle of every onboarding, while keeping the Bank in control of who joins and on what terms.

What I did

1. Mapped the current process. I mapped the staff-led onboarding process as it ran, lane by lane, to show where the work landed: most of it sat with Bank operations.
2. Redesigned it around aggregators. In the future-state design on Closa 2.0, third-party aggregators onboard and manage their own agents, within controls the Bank sets. The Bank moves from doing every onboarding to setting the rules that every onboarding follows.
3. Ran requirements and backlog refinement with the vendor. I worked with the platform vendor, CEVA Software, to turn the design into requirements and a refined backlog for Closa 2.0.

The swimlane below compares the two states. It is simplified: generic lanes and steps, not the Bank’s real procedure.

Techniques: current-state and future-state process mapping, swimlane diagrams, requirements elicitation and backlog refinement with a vendor.