The Word 'Onboarding' Is Doing Three Jobs in Your Building

Every UK office has a word that everyone uses and nobody owns. In one building it might be "onboarding". In another it is "CRM", "handover", or the deeply optimistic "done". The word appears in slide decks, job ads, Teams channels and software procurement forms. It sounds like agreement. It is usually just a shared spelling.

The trouble starts when a change programme lands on top of that shared spelling. A new automation is switched on. A workflow is redesigned. A dashboard is rebuilt. Everyone nods in the workshop, then goes back to their desks and does three different jobs under one label. Nobody is being difficult. They are simply working from the definition their team learned the hard way.

The same word, three perfectly sensible processes

Take "onboarding". For HR, it means contracts, right-to-work checks, payroll setup and the first-week diary. For sales, it means getting a new client from signed proposal to first value: kick-off call, access requests, account setup, maybe a handover to delivery. For a support team, it can mean teaching a new starter where the escalation paths are and which Slack channel is for genuine emergencies versus lunch recommendations.

All three are real. All three are important. None of them are the same process. If your new workflow tool has one "onboarding" pipeline, one set of statuses and one notification rule, you have not created alignment. You have created a queue where three processes compete for the same labels.

"CRM" has the same problem. One team means the sales pipeline. Another means the account history. A third means the place where support tickets are supposed to be linked but never quite are. By the time an AI assistant is asked to summarise "the CRM", it is summarising a compromise nobody wrote down.

And "done" is the quiet killer. Done can mean the ticket is closed. It can mean the client has been told. It can mean the invoice has been raised. It can mean the file is in the right folder, which is a different kind of fiction altogether. If your workflow triggers the next step on "done", you need to know which done you mean.

Why the glossary does not fix this

Most teams respond to vocabulary drift with a glossary. Someone creates a shared document, adds twelve definitions, shares it in a channel and considers the matter closed. The glossary then joins the wiki graveyard alongside the old process maps and the emergency contact list from a previous office move.

The glossary fails because it treats the problem as documentation. It is not. It is an ownership problem. A word means what the person doing the work needs it to mean at the moment they do it. If two teams have different needs, a single definition will either be ignored or quietly bent back into shape.

What you need is not a dictionary. You need a short, structured argument about what actually happens. That is where the definition hour comes in.

Run a definition hour, not a definition workshop

A definition hour is a 60-minute session with three to five people from each team that touches the word. No slides. No 40-page pre-read. No one from the programme team presenting the future state. The rule is simple: show me the last real one.

Ask each team to bring one recent example: the last client onboarded, the last deal moved through the CRM, the last project handed over, the last ticket marked done. Then walk it through, step by step, on a whiteboard or a shared board. Not the ideal process. The one that actually happened, including the WhatsApp message and the spreadsheet that nobody admits to using.

Capture six things for each example:

• The trigger: what starts this process?
• The owner: who is accountable when it stalls?
• The first action: what happens first, in the system and outside it?
• The handoffs: who passes what to whom, and how do they know?
• The definition of done: what must be true before the next step is allowed?
• The system of record: where is the truth kept, and who can change it?

You will usually find one of three things. Sometimes the same word hides genuinely different processes, which need different names. Sometimes different words describe the same process, which needs one name and fewer tools. Occasionally everyone really does mean the same thing, and the hour confirms it. That is still a win. Confirmed agreement is cheaper than assumed agreement.

Make the output useful, not ceremonial

At the end of the hour, do not write a glossary. Write a short decision note with three parts: what we mean, what we do not mean, and where this definition lives in the workflow itself.

If "onboarding" means three things, name them: "client onboarding", "colleague onboarding", "supplier onboarding". If "done" has two meanings, split the status: "work complete" and "client notified". Put those labels in the tool where the work happens, not in a document nobody opens. Add an owner and a review date. Vocabulary drifts because teams change, tools change and people leave. A definition hour is not a one-off ceremony. It is a maintenance task.

This matters more now that automation and AI agents are moving into the workflow. A bot does not infer your team's culture from context. It follows the labels it is given. If your CRM means three things, your automation will faithfully do three things badly. If your handover has no agreed definition, the agent will hand over to the wrong place with impressive confidence.

The fix is not expensive. One hour, three teams, one live example each. It is the least glamorous work in digital transformation, and often the most useful. Before the next change programme lands, find the word everyone uses and ask what it means. Then keep asking until the answers stop matching the slide.

That is not a delay. That is the work.