CASE STUDY

A recruitment website built for two audiences: the Avolon Group website, construction recruitment, Hove

A holding page became a recruitment site with a page per vacancy, a registration that writes into the CRM, and a staff request that reaches a person.

The Avolon Group website on a laptop and a phone: the home page headed Groundworks and civil engineering over an aerial photograph of a groundworks site, with Find work and Request staff buttons, and the phone showing the For employers page.

The finished site. Candidates are offered Find work and clients Request staff on the first screen, and the same two paths run through the navigation.

Scott Burns, founder of Glo Business Solutions. Published 13 September 2026. Avolon Group and Chris Tunnicliffe are named with their permission.

The business

Avolon Group, the trading name of Avolon Grp Limited, is a construction recruitment business in Hove and has been since 2010. It runs two service lines. Labour supply: groundworkers, 360 operators, dumper drivers, gangers, banksmen and telehandler drivers. And white collar: site engineers, setting out engineers, site managers, contracts managers and quantity surveyors, on contract or permanent. In its own words it works throughout the UK, across the South and Home Counties. Chris Tunnicliffe is its director, and he is the person the rest of this page quotes.

What was not working

The starting point was a holding page. It read "Under construction" and "new site coming 2026", and that was the whole of Avolon's presence online. That is not a criticism of anyone; it is where a lot of good businesses are. But a recruitment business that has to bring candidates to roles and clients to the desk cannot do either from a holding page, and Chris's own summary of what he needed still holds: "We needed a site that brings work in, not just one that exists."

The other half of the problem only came out in the first meeting. Chris went looking for a website, and what surfaced was, in his words, "a list of things we were doing by hand that did not need doing at all". The brief grew from a site into a site with the admin underneath it thought about.

What was built

The build was described at the time in one sentence, and it still holds: a site built around the two things that matter, candidates finding roles and clients requesting staff. Everything below follows from that.

Two audiences, not one

A recruitment site serves two different visitors who want two different things. Candidates bring the traffic; they are the people searching for work. Clients bring the revenue; they are the contractors who need a gang on site and will only ever look at one page. The site had to carry both from the first screen down. On the home page the two buttons are Find work and Request staff, side by side, and the navigation keeps them apart the whole way through: For employers and Request staff for one audience, Jobs, Register and Join us for the other.

One page per role

Each role has a page of its own, at its own URL, carrying JobPosting structured data so that a search engine can read it as a job rather than as a paragraph on a jobs page. The markup was verified on both branches, the hourly labour roles and the salaried white-collar ones, which describe pay differently and have to be marked up differently.

The jobs come from the CRM the desk already runs on. A scheduled job reads the open vacancies, writes them into the site's own database, and the pages are built from that rather than from a live call out to Bullhorn every time somebody loads one. A page still works when the CRM is slow or its session has expired, and every role gets a real URL that can be shared and linked rather than a filtered view of a list.

Registrations that arrive as records, not emails

A candidate registering on the site gives their details, ticks the qualifying cards for the role they are after, and photographs the front and back of each one. That lands in the site's own database first, with the documents in a private bucket that cannot be read back through the API. A separate scheduled job then creates the candidate in the CRM, flagged as a website registration, with the documents attached.

Two steps rather than one, deliberately. If the CRM is unavailable or a credential has rotated, the registration is already saved and the push retries. Nothing a candidate typed is lost because a third party was down.

A request-staff form that lands somewhere real

The Request staff form writes to a database table rather than sending an email that can be lost. The table is insert-only for anonymous visitors and has no select policy at all, so the public can submit a request and nobody can read the requests back through the public API. Server-side check constraints reject a submission that does not make sense, and a honeypot field catches the bots that fill in every box.

The brand, as the designer drew it

Avolon arrived with a logo, and several attempts to rebuild it were rejected, rightly. The designer's original pack was obtained instead and the logo used as drawn. The palette was taken from Avolon's own published material rather than sampled off the logo, so the site reads as the brand people already knew. The imagery is Avolon's own kind of work, an aerial photograph of a groundworks site, given a light grade rather than the duotone treatment that makes every construction site look like every other. Chris's description of the whole approach is that Scott "took our brand, our jobs and the way we actually run the desk, and got on with it".

In the client's words

Chris Tunnicliffe
“I went to Scott for a website. What came out of the first meeting was a list of things we were doing by hand that did not need doing at all. Registrations from the site now go straight into Bullhorn without anyone retyping them, and the jobs board runs off the same connection. It has taken real admin off the team, and none of it was on my list when I walked in.”
Chris Tunnicliffe, Director, Avolon Group, Hove

What it runs on now

One connection, running both ways

A client-side application, its own Supabase database, and a scheduled connection to Bullhorn running both ways: vacancies out of the CRM and onto the site, registrations off the site and into the CRM. The site holds its own copy of everything, so nothing a visitor sees depends on another system answering at the moment they arrive.

The first days

What happened when it went live

Two client enquiries came through the site in its first two days. Client enquiries are the half of a recruitment business the old holding page could not serve at all, so the first two arriving that quickly matter more than the number suggests.

Chris puts the saving on candidate registrations at around ninety per cent of the staff time it used to take. That is his own estimate rather than a measured figure, and the mechanism behind it is straightforward: a registration that was keyed into the CRM by hand now arrives as a record with its documents already attached.

Next step

Bring the list of things done by hand

Avolon's build started with a holding page and a first meeting that found the admin underneath it. The first meeting is free, in person where it is drivable, and it starts the same way.