Training that survives the second week

A session of two hours teaches the click path, and teaches it well. What it cannot teach is the judgement the second week asks for: which exception to escalate, which of two similar values is right, and when to stop and ask. That grows from practice on the work the clerk will do, with the person who will be asked — so the question is not how long the session runs, it is whose records are on the screen.

Who should be trained first?

The person the others already ask. In every counter, workshop and stockroom there is one, and colleagues phone them before they phone the manager.

Adoption travels along lines people already use: a colleague's answer is trusted more than a trainer's slide, because the same work stands behind it. Train that person first, one level deeper, and give them a name in the plan.

Training the manager first is the default and usually wrong. The manager is not at the counter, and what they learn reaches the clerk second-hand, minus the exceptions. If they attend, they attend to decide — who may correct data, what goes on paper — not to learn the clicks.

Why train on their own data instead of demo data?

Because recognition is most of the skill, and demo data gives nothing to recognise.

A clerk learns where the screen is; what they really learn is what a correct line looks like. "Client A" and "Product 1" carry no memory, so the errors a clean demo allows are the ones real data punishes: the customer with a credit note, the item sold in two units, the return that must go back to stock.

Take a copy of real records, anonymised if it leaves the building, and use their customers, prices and exceptions. If real data is unavailable, rebuild a few real cases from memory; a clean invented set teaches a world that does not exist. Train in the order the work happens, not the manual's order.

What must a clerk do unaided on day one?

Three things, all of them about judgement rather than navigation.

• Complete the transaction they do most often, including the exception that appears most weeks — a discount, a missing price, a returned item.
• Find something they did not enter: a customer's balance, an order's status, whether an item is in stock. The question at the counter is usually about someone else's record.
• Correct their own mistake from yesterday unaided, and know which corrections they may not make.

If any of the three needs a call to the builder, day one is not ready — and the session was not the problem.

What goes on the card that stays at the counter?

One card per role, one side, small enough to sit under the keyboard. Not a manual.

• the actions of the role, in the order they happen in a day;
• what to do when something fails: the paper fallback, and a person's number, not a queue's;
• the two or three actions that need permission, named;
• one line on where the data goes and who reads it.

Write it during the session, from the questions people asked. Date it, and name whoever keeps it current: a card with no owner is never updated, and an out-of-date card fails the first time it is used.

Who gets the second session?

One or two people per site — the ones who will be asked. The second session is not a repeat for slower learners; it carries different content: the exception paths, the reports, the corrections, and the authority to say no.

Give that person a status, a direct line to the builder for the first weeks, and a boundary: they may correct data, not change the system. Requests for change go on a list with a date, otherwise "the system ought to do this" is said at the counter and lost by lunchtime. Give them hours: the fastest clerk is the busiest, and a role with no time disappears in a month.

Is training the fix when the tool is slower than the spreadsheet?

No, and running the session again makes it worse: it makes people fluent in a slower job.

The test needs no study. Sit beside the clerk and count the actions for their most frequent task, old tool and new. More actions, more reading, or more moving between screens is a design problem, and the training budget is paying for it. Training answers "I did not know where the field was"; it cannot answer "I know where it is, and it is three screens away".

What a session teaches	What the second week needs	Where that comes from
The click path	Which exception to escalate	Rehearsing real exceptions
Where the field is	Which of two values is right	Their own records
What the screen says	When to stop and ask	A named person to ask

What looks like a training gap is sometimes a legibility one. If clerks misread the screen, check size, contrast and target size against WCAG 2.2 before booking another session. A small font is not a knowledge gap.

How do you run training that lasts?

1. Name the person the others already ask, and give them the second session first.
2. Copy real records, or rebuild real cases, and drop the demo set.
3. Write the three day-one tasks as tests someone can pass or fail.
4. Run it at the counter, on the machine the clerk will use, in the order the work happens.
5. Let the clerk drive; the trainer watches and speaks only when asked.
6. Write the card during the session, from the questions that came up.
7. Stay for the first live day with your hands off the keyboard.
8. Review after week two: what was asked twice, what went back to paper, what still needs a call.

Where this goes wrong

• The manager is trained and teaches the counter from memory. The exceptions are lost first, and nobody notices until one arrives.
• Clean demo data, so the credit note and the part payment appear for the first time on a real customer.
• The trainer types during the live day. The clerk never gets past watching and the paper fallback becomes the process.

What this does not cover

It gives no duration: that depends on how many exceptions the work contains, and a workshop with a few is a different job from a counter with dozens. It assumes a system stable enough to be learned; if the same screen changes weekly, no card survives. It does not cover pay or the super-user's status, which is a management decision, nor replace the rule about who may correct data: a session cannot grant a permission the system does not have.

We build the first week of training around the clerk's own records, because a session that ends at the door of the training room ends before the work starts.