You Can't Expect Service Standards You Haven't Taught

We ask candidates to complete practical assessments. We test their knowledge. We give them scenarios. We want evidence that they can troubleshoot, diagnose problems and understand the technology they'll be working with.

That makes complete sense.

How they explain a technical issue to someone who doesn't understand the technology?

How they respond when they don't yet have an answer?

How they take ownership when something goes wrong?

Or how they balance following process with delivering a good customer experience?

These things are often grouped together as soft skills.

Yet in a customer-facing role, they can have just as much impact on the customer experience as technical competence.

And that creates a problem.

We are often very deliberate about teaching people how to do the technical parts of their role, but much less deliberate about teaching them how the organisation expects that service to be delivered.

Then, later, we hold people accountable when they get it wrong.

Someone can be technically excellent and still create a poor customer experience.

They can solve the issue but fail to keep the customer updated.

They can know the system inside out but pass work to another team without confirming ownership.

They can fix the problem quickly but communicate in a way that leaves the customer feeling dismissed or confused.

They can understand the technology but not the process around it.

That doesn't necessarily mean they are a bad employee.

It may simply mean nobody has properly shown them what good looks like.

For customer-facing roles, onboarding should develop capability across four areas.

Can they perform the practical requirements of the role?

Do they understand how work moves through the organisation, where handoffs happen, when to escalate, what needs to be documented and who owns the next step?

Can they communicate clearly, manage expectations, take ownership and handle difficult situations appropriately?

Do they understand what the organisation actually wants the customer to experience when they interact with them?

Those four areas should sit together.

Because good service is rarely the result of technical capability alone.

Technical knowledge tells someone how to complete a task.

Process knowledge tells them how that task fits into the wider service.

A new employee needs to understand what happens before their part of the process, what happens afterwards and what their responsibilities are when something goes wrong.

Without that understanding, people naturally create workarounds.

An engineer messages someone directly instead of following the agreed escalation route.

A case is handed to another team without confirming whether they have accepted ownership.

A customer is told somebody else will contact them, but nobody checks whether that actually happens.

Individually, those can look like small process failures.

To the customer, they look like poor service.

This is why process training shouldn't just explain what someone needs to do next.

It should explain why the process exists and what it is trying to protect.

If people understand the impact of a missed step, they are much more likely to understand why that step matters.

If a role is customer-facing, I think there is a strong argument for assessing judgement during recruitment as well as technical ability.

A situational judgement assessment could give candidates realistic scenarios and ask them how they would respond.

What would they do if a frustrated customer wanted an immediate answer but they didn't yet know the cause?

How would they handle another department failing to complete an action?

What would they do if they realised they had given a customer incorrect information?

Would they bypass an agreed process because it seemed quicker?

The purpose isn't to find someone who knows the organisation's exact answer before they even join.

It is to understand how they think.

Do they naturally take ownership?

Do they consider the customer impact?

Do they communicate clearly?

Do they recognise when to escalate?

Do they understand the importance of process?

Technical tests tell us whether someone can do the work.

Situational judgement can help us understand how they are likely to behave while doing it.

But recruitment is only the starting point.

You still have to teach people what good looks like in your organisation.

A probationary period shouldn't be three or six months of watching somebody work and deciding at the end whether they were good enough.

It should be a structured development period.

That means setting expectations early, monitoring performance carefully and addressing gaps while there is still plenty of opportunity to improve.

For a customer-facing role, that could include reviewing calls, checking written communication, sampling tickets or cases, observing process adherence and discussing how the individual handled particular situations.

If someone misunderstands an escalation process in week two, correct it.

If their customer communication isn't clear enough, show them what better looks like.

If they are technically capable but struggling with ownership, coach them on it.

If they repeatedly miss part of a process, understand why.

The point isn't to catch people out.

It is to reinforce the standards of the business before poor habits become established.

And before customers repeatedly experience them.

Customers paying for a premium service expect a premium experience.

They expect fast, efficient service.

They expect the person dealing with them to be capable and informed.

They expect clear communication.

They expect processes to work.

And when something goes wrong, they expect somebody to take responsibility for resolving it.

What they don't expect is to become part of somebody's training programme.

Of course, every new employee needs time to learn.

Nobody walks into a new organisation understanding every system, process or customer.

But that learning curve needs to be managed by the employer, not absorbed by the customer.

When someone hasn't been sufficiently trained, supported or monitored, the customer doesn't see an onboarding issue.

They see poor service.

They experience the delay. The incorrect information. The missed handoff. The poor communication. The issue they have had to chase three times.

And once that happens repeatedly, something else starts to change.

The customer begins to question the service.

Then they question the relationship.

And eventually they question whether they are receiving the value they are paying for.

That is especially important when you are selling a premium service.

The higher the expectation, the less tolerance there is for inconsistency.

Structured onboarding and probation aren't only about protecting the customer.

They give the employee the best possible opportunity to succeed too.

If the organisation clearly explains its technical, process, service and experience standards from the beginning, the employee knows what is expected of them.

If their performance is reviewed regularly, they know where they need to improve.

If they receive coaching early, they have an opportunity to correct mistakes before those mistakes become habits.

And if, after all of that, someone still cannot meet the required standard, the organisation can make that decision knowing the individual was properly supported.

That makes accountability fairer.

It also creates better employees.

Because the aim shouldn't simply be to recruit someone who can technically perform the role.

It should be to develop someone who understands how your organisation expects that role to be delivered.

The strongest model is simple:

Because you can't expect service standards you haven't taught.

So, if a new employee delivered a poor customer experience tomorrow, could you confidently say you had shown them exactly what good looks like?