Blog
From manual work to automated research recruitment
How Bolt's research team replaced a stack of disconnected recruiting tools with one composed workflow — and why the people closest to the problem built it themselves.
Continuous discovery only works if you can keep finding people to talk to. The conversations themselves are rarely the challenge. The real work happens around them: finding the right participants, reaching out, scheduling interviews, tracking attendance, and then repeating the whole process again the following week.
At Bolt, product teams regularly speak with customers through our customer engagement programme. That steady feedback loop helps teams stay close to real user needs, but as the programme grew, so did the operational burden behind it.
Before we built a dedicated tool, recruitment relied on a collection of disconnected systems. Participant sourcing happened in one place, outreach in another, scheduling somewhere else, and tracking often lived in spreadsheets. Recruiters spent time moving information between tools, reconciling data, and coordinating handoffs.
None of these tasks were particularly difficult on their own. Together, they created a process that was slow, repetitive, and increasingly difficult to scale. As more teams and markets joined the programme, it became clear that the process that had worked before would not support the next stage of growth.
Why we chose to build
Like most teams, we started by looking at what already existed. There are plenty of research recruitment platforms on the market, and many of them solve similar problems, but none fit what we needed closely enough. We wanted something that worked with the tools we already used and matched the way our research programme operated. At the same time, building software had become much more accessible than it used to be.
Working with PoDojo over several months, we started building a tool ourselves. While our team had limited experience shipping production software, we understood the problem better than anyone because we were dealing with it every day. The project became an experiment in what happens when the people closest to a problem get the opportunity to solve it directly.
Rather than replacing existing systems, we connected them. The survey tools, messaging platforms, calendars, and internal data sources we already relied on became part of a single process.
That turned out to be a useful lesson. Companies often think they have two choices when it comes to internal tools: buy something or build everything from scratch. In many cases, there’s a third option. You can connect the systems you already have and build only the missing pieces.
What we learned
Looking back, the most valuable outcome wasn’t the tool itself. We built it because our customer engagement programme was growing. More teams wanted to speak with customers, more research was being conducted, and the operational work behind recruitment was growing alongside it.
The immediate benefit was having a simpler, more reliable process. Recruiting participants became easier to manage, information lived in one place, and far less time was spent coordinating across different tools and systems.
But the project also challenged a common assumption about how internal tools get built. Traditionally, solving a problem like this would have meant either adapting our process to fit an existing product or asking an engineering team to build something from scratch. Instead, we were able to create a solution around the way we already worked.
That mattered because the people involved in recruitment understood the challenges firsthand. We knew where the process slowed down, where information got lost, and which parts created the most overhead as the programme expanded. Ultimately, the goal was never to build software. It was to make it easier to keep customer conversations at the centre of product development.
As research programmes grow, the operational work behind them grows too. By simplifying that work, we’ve been able to spend less time managing the process and more time helping teams learn from customers. That’s probably the most important outcome of all.
This is the view from inside Bolt of the shift described in Discovery’s oldest bottleneck, meeting the newest way of building.
FAQ
How do you automate research participant recruitment?
You connect the tools you already use instead of adding another platform. At Bolt, participant sourcing, outreach, scheduling, and tracking had lived in separate systems and spreadsheets. The team joined its survey tools, messaging platforms, calendars, and internal data into one process, so recruiters stopped moving information between tools by hand.
Should you build, buy, or compose an internal tool?
There is often a third option beyond buying software or building from scratch. You can connect the systems you already have and build only the missing pieces. Bolt composed its recruiting tool from existing infrastructure over several months, coached by PoDojo, because the people closest to the problem understood it best.
Why did Bolt build its own recruitment tool instead of buying one?
Existing research recruitment platforms solved similar problems, but none fit Bolt's tools or the way its research programme ran. Building software had also become much more accessible. The team understood the problem firsthand, so it created a tool around how it already worked rather than adapting to someone else's product.
What is the main benefit of automating research recruitment?
The biggest gain is time, not the tool itself. With sourcing, outreach, scheduling, and tracking in one place, Bolt spent far less effort coordinating across systems and more time helping teams learn from customers. As the research programme grew, the operational work behind it stopped growing at the same pace.