The situation
ClearGlass analyses, validates and benchmarks what pension schemes pay their asset managers. LGPS fund data arrived as an operational bottleneck, they included deeply hierarchical structures, processed by hand across every collection cycle. The platform that came out of it wasn't on my roadmap when the deal was made. It turned into a revenue line in its own right, built on the lessons that the first collection cycle taught us.
Build, don't staff
The obvious answer to a growing manual workload is more people and that was leadership's first instinct. However, scaling the ops team with the workload ties cost to revenue permanently and every new scheme means new hands. The change requirements were largely structural so there was an obvious case to make that we should automate the processing once, and LGPS revenue could grow while the cost base stood still.
Under-engineering on purpose
The engineers recommended full reconciliation engines - elegant, complete, correct on the whiteboard. After review, I said no, for one reason: there was too much we didn't know. Before our first real collection cycle, a heavy build would have encoded our guesses. So we deliberately built lighter than we could have, shipped into the cycle, and let the cycle teach us what the second version actually needs.
A new client type, priced as one
LGPS funds aren't typical corporate pension clients. The scheme is statutory, funded and defined-benefit, administered locally by dozens of funds with pooled assets and thousands of participating employers, this is why the data arrives as deep hierarchies rather than tidy tables. This is the main reason we decided to treat them as a new client type. The platform absorbed the structural complexity, and a new charging scheme was defined rather than stretching the existing commercial model.