A UK recruitment firm tried digital transformation twice

TL;DR: A UK HR team was running its entire appraisal process on spreadsheets and email. They tried an off-the-shelf platform first. It did not work, not because the software was poor but because the evaluation structure was too specific to be configured without building something bespoke anyway. This post walks through what the decision-making process actually looked like, why the first attempt stalled and what a better approach produced. It ends with three questions any HR or recruitment firm should ask before commissioning a digital build. Not the technology questions. The organisational ones.

There is a version of this story that most HR and recruitment teams have either lived through or watched happen to someone they know.

A platform that everyone agreed was needed. A selection process that felt thorough. An implementation that started promisingly and then quietly stalled. And a moment, usually somewhere around month six or seven, when the honest conversation finally happened: this is not going to work.

According to Deloitte UK research cited by Prox Digital Agency, over 70% of digital transformation initiatives fail to achieve their intended outcomes and the pattern behind most of those failures is not a technology failure. It is an alignment failure that the technology made visible. 

What follows is drawn from a real engagement. The details have been anonymised but the specifics are real.

The starting point

An HR team managing performance appraisals across a medium-sized organisation. The process had been running on a combination of spreadsheets and email for years. Every appraisal cycle involved the HR Admin maintaining a master spreadsheet per cycle, emailing managers with deadline reminders and manually aggregating ratings at the end.

The problems were consistent and well-understood. No centralised visibility into who had completed what. No audit trail of performance decisions. Rating variance between managers that only became apparent at the end of the cycle when it was too late to normalise. Employees emailing to ask when results would be released. Managers calculating weighted scores manually in personal spreadsheet templates and occasionally getting them wrong.

The HR Admin knew exactly what the problem was. What was less clear was what the right solution looked like.

The first attempt

The team evaluated several off-the-shelf HR platforms. The selection process was thorough. The chosen platform had strong reviews and had been implemented successfully at comparable organisations.

The implementation stalled within a few months, and the reason was not the platform's core functionality. It was one specific requirement that had not been fully understood at the point of selection: the evaluation role structure.

In this organisation, a manager was not a single role. The system needed to support configurable evaluation roles, named roles created by HR Admin and assigned to specific users. A single person could hold multiple evaluation roles simultaneously. The same person might be the Reporting Manager for one employee but only the Security Manager for another, with completely different KRA scope in each case.

No standard HR platform handles this without significant custom development. The cost and complexity of configuring the off-the-shelf platform to accommodate it would have exceeded the cost of building something purpose-built. That conversation would have been useful earlier in the process. It engaged after six months of implementation work instead.

Who the real blocker was

The HR Admin had documented the appraisal workflow carefully. The requirements covered the core cycle: KRA assignment, self-evaluation, manager review, HR finalisation and result release.

What the requirements did not capture was the evaluation role structure, because it was so embedded in how the organisation worked that nobody had thought to surface it as a requirement. It was simply how things were done. The assumption was that any HR platform would accommodate it.

That assumption was the blocker, not a person, not a budget, but an assumption that went untested until the implementation was already underway.

The HR Admin was not wrong to document requirements carefully. The IT lead was not wrong to recommend a well-regarded platform. Each person did their job correctly. The process that connected those jobs was missing a step: a structured conversation about the specific ways this organisation's appraisal process differed from the standard model any off-the-shelf platform is built around.

What a better approach looked like

The decision to build bespoke was made not because off-the-shelf was the wrong choice in principle but because the specific requirements, once properly surfaced, could not be met by a configurable platform without a level of customisation that made bespoke the more practical option.

The build that followed was scoped around the actual workflow rather than a generic appraisal model. The configurable evaluation role structure was built in from the start. HR Admin could create named evaluation roles, assign them to user accounts and define the scope of each role per employee. A single user could hold multiple roles simultaneously with different KRA scopes in each. The system enforced 100% total KRA weightage per employee with a live warning rather than discovering the error after submission.

The outcome targets were specific and measurable: a 30% reduction in appraisal cycle close time, a 90% on-time manager submission rate and an 85% self-evaluation completion rate within the review window. Those targets came from understanding the current baseline before the build started rather than estimating what an improvement might look like.

The audit log covered every significant system action, including user account changes, KRA assignments, self-evaluation submissions, score changes and result releases, each with a timestamp, the actor and the before and after values where applicable

You can see how we approach platform builds for organisations with specific and non-standard workflow requirements in our case studies, including our work with Realsafe on a bespoke compliance platform built around how construction site teams actually work and our work with Insite Energy on replacing a legacy billing system that had outgrown the business it was built for.

The three questions worth asking before you start

These are not technology questions. The technology questions come later. These are the organisational questions that determine whether a digital build will succeed regardless of which technology is chosen.

Have the people who will use the platform daily been involved in defining what it needs to do, not through a survey but in a direct conversation about how they actually work?

The gap between documented requirements and actual working practice is almost always larger than anyone expects. In this case, the evaluation role structure was not in any requirements document because nobody had thought to put it there. It was just how things worked. The only way to surface that kind of requirement is a direct conversation about working practice, not a review of existing documentation.

Is there a single person who has the authority and the credibility to make decisions when stakeholder requirements conflict, and does everyone involved know who that person is?

An appraisal platform serves at least four distinct user groups: HR Admin, Directors, Managers and Employees. Each has different access requirements and different pain points. Without a clear decision-maker, those conflicts get resolved by the build rather than before it, which is almost always more expensive.

Is there anything about how your organisation works that you have never needed to explain to a colleague because everyone already knows it?

That is the requirement most likely to be missing from your brief. The thing so embedded in daily practice that it is invisible until a platform that does not accommodate it arrives. Surfacing it before the build starts is the most useful thing a discovery phase can do.

Off-the-shelf versus bespoke: the honest spectrum

The choice between an off-the-shelf platform and a bespoke build is not simple and should not be framed as one being obviously right.

Off-the-shelf platforms work well when the organisation's requirements map closely to what the platform was designed to do, when the organisation is willing to adapt its processes to the platform rather than the other way around and when implementation timeline and cost are the primary constraints.

Bespoke builds make sense when working practices are specific enough that customisation costs would exceed the cost of building something purpose-built, when integration with existing systems is complex enough that a configurable platform cannot handle it cleanly or when the requirements that matter most are the ones no existing platform was designed around.

In this case, the evaluation role structure was the requirement that shifted the decision. Once it was properly understood, the comparison between customising an off-the-shelf platform and building something purpose-built was straightforward. That understanding came too late the first time. The second attempt started by surfacing it.

Frequently asked questions

Why do digital transformation projects fail in HR and recruitment firms? The most common cause is not technology failure but alignment failure. Requirements are documented by one stakeholder and do not reflect how the people who will use the platform actually work. The gap only becomes visible after implementation. Research from Warwick Business School confirms that transformation success depends more on leadership alignment and capability maturity than on technology selection.

Should a UK HR or recruitment firm choose an off-the-shelf platform or a bespoke build? It depends on how closely the firm's requirements map to what existing platforms were designed to do. Off-the-shelf works well when the firm is willing to adapt its processes to the platform. Bespoke makes sense when working practices are specific enough that customisation costs would exceed a purpose-built alternative. The decision should be made after requirements are properly surfaced, not before.

What should an HR or recruitment firm do before commissioning a bespoke digital build? Three things matter more than the technology decision: involve the people who will use the platform daily in a direct conversation about how they actually work; identify a single decision-maker with the authority to resolve stakeholder conflicts; and surface the requirements so embedded in daily practice that nobody has ever needed to write them down.

How long does a bespoke HR platform take to build? It depends on the complexity of requirements and the integration landscape. A platform covering a complete appraisal cycle with configurable roles, real-time score calculation and audit logging for an organisation of up to 500 people typically takes four to six months from a completed discovery phase to MVP deployment. The discovery phase, done properly, may take four to six weeks and is the part most often compressed.

What does a discovery phase for an HR platform build actually involve? A structured process of mapping how the organisation actually works rather than how it is documented to work. This includes direct conversations with every user group, an honest assessment of which processes the organisation is willing to change and which it is not, and clear identification of requirements so embedded in practice that they have never been written down.

How Aecor helps

We work with professional services firms and HR teams at the point where a platform decision needs to be made, with a clear picture of the organisational requirements behind it rather than just the technology ones. Every engagement starts with a structured discovery phase that surfaces the requirements that rarely appear in a brief. 

If you are working out which approach is right for your organisation, a free consultation is a good place to start.

Book a free consultation