
The context
Hireup could no longer grow with the existing bookings platform. A combination of legacy tech stack, legacy visual language, accessibility issues, and costly technical debt meant it wasn’t easy to scale for our needs.
Where we started
Bookings are the core of the Hireup platform and facilitate the user’s primary needs. Filling shifts and gaining work. It’s a high stakes area of the platform to work on, is incredibly complex and perhaps like many rapid scale-ups, involves navigating considerable technical and experience debt.
The bookings platform had not been touched by product teams since the early days of Hireup.

1:1 and 1:many relationships and accommodating teams of all sizes.
Our traditional user base consisted of independent workers, and self-managed clients. Clients traditionally employed a small number of workers in their ongoing support.
We wanted to attract more Providers to the business, and to do so we needed to scale our infrastructure and experience to accommodate them.
Providers typically are multi regional, with workforces of up to 500 - 600 people. Our current booking experience was tailored for 1:1 relationships, where a client knew specifically which worker they wanted to book.
Our B2B users treated their workforce more like a pool so we designed and built an experience that Providers (or clients) to share a booking request with a group of workers of their choice, with a first to accept wins model on the worker side.


Alongside a fresh flow to create bookings, we needed to redesign the way bookings were managed. A Provider with a team of 500 workers might have thousands of bookings.

Expanding the bookings relationship to include a 1:many model meant the worker experience also needed to be redesigned and rebuilt.

The platform should do the heavy lifting, not the user
The primary need of a Client/Provider when creating a booking is to fill a shift and receive support. When that booking is sent to more than one worker, the chances of them receiving the support increases, as does the time it takes for a shift to be accepted.
When something goes wrong on a booking like a worker isn’t available, or a worker cancels, the platform steps in to automatically triage the booking. If the booking has been sent to more than one worker, the remaining workers get another chance to accept the shift.

Where we are going
The first phase of this project was to overhaul the legacy bookings platform. We know that through research and data analysis, our solution is an improved experience however still isn’t accommodating the specific needs of some of our markets. While still more a vision rather than a scheduled item on the roadmap, the first brush strokes of a bespoke B2B platform are being considered.



Outcomes
📈 Over 10k booking requests have been sent to multiple workers
📈 Bookings sent to more than one worker were 3x times more likely to be accepted
📈 Automatically re-filling cancelled bookings has captured 1000+ approved hours since launch
📈 Booking requests has contributed to +25% booked hours growth since launch