1.1 · The record is the start of a decision

An Employment Coach finishes an appointment. The next participant is already in reception, and this appointment has run over. Near the end, the participant mentioned that childcare has fallen through and the next fortnight could be difficult.

The EC heard it. It mattered. But the laptop is closing, someone is waiting, and there is no proper gap before the next appointment. The note becomes "discussed barriers", or it waits for a quieter moment that never arrives.

Three weeks later, that participant has stopped answering calls. The Business Manager sees engagement dip on a dashboard and asks what happened. Nobody can say for certain, because the signal that would have explained it never left the appointment room.

This is not about an EC not caring. The signal was heard. What beat it was pressure: an appointment that overran, the next person waiting, and a day with no space for the record to land properly.

That is the trap. We ask people to capture the most important signals in the smallest gaps of the busiest days.

The record still matters because of where it goes next. It is not something separate from the real work. It is how the next person knows what to do. An EC uses it to plan a follow up. A BM uses it to understand caseload movement. A Head of Operations uses it to spot contract drift. BI uses it to build a reliable picture of delivery. Finance may use related evidence to reconcile activity and payment.

A barrier that stays in someone's head cannot trigger an action, shape a caseload review or warn a manager that someone is starting to drift.

That is why the record is the start of the decision, not the admin after it.

1.2 · The Decision Test, on the front line

The Decision Test is simple: data is only worth holding if it changes what someone does.

On the front line, that becomes practical. Before you skip a field, rush a note or fill something in just to clear the screen, ask whose decision depends on this, and what they would do differently if it were missing or wrong.

Sometimes the honest answer is "nobody", or "nothing". If so, the field may be the problem, and that is worth raising. More often, the answer is a real person and a real action: an EC follow up, a BM intervention, a safeguarding step, an evidence chase, a quality check, a contract risk conversation.

This is why "we need more data" is rarely the right starting point. More fields and more reports do not help AKG unless they improve a decision someone is already trying to make.

The better question is this: what decision are we trying to make better, and what does that decision need from us?

2.1 · One record, read many ways

An EC records that a participant has a transport barrier and agrees an action. To the EC, that record is one person and one next step: chase the travel support, follow up on Thursday, keep the participant engaged.

By the end of the week, that same entry is one of many barrier records across a Business Manager's site. The BM is not reading one participant story. They are reading a pattern: transport barriers are rising, mostly in one team or location. The question has changed from "what does this participant need?" to "is something happening across my caseload that I need to act on?"

Move up again. A Head of Operations is looking across sites, contracts or services. The same transport flags have become part of a wider trend. The question changes again: is this local, regional, contract specific or part of a wider delivery issue?

BI reads the same chain differently. BI has to ask whether "transport barrier" means the same thing everywhere it has been recorded. If one team logs any travel difficulty and another logs only the barriers that prevent attendance, the trend is partly real and partly recording habit. The dashboard may be technically correct, but the meaning underneath it is not stable.

Finance may read related information through a different lens again: cost, claimability, evidence, funding rules or payment timing. IT reads the system chain: whether the record is captured, moved, secured and made available to the right people.

One record. Several readers. Several questions. None of those readers is wrong. They are reading the same data at different altitudes.

2.2 · You are recording for people you will never meet

The EC who logs a barrier will probably never sit with the Head of Operations reading the trend. They may never meet the BI analyst checking whether the definition holds. But both are downstream of those few seconds at the keyboard.

That is what makes good recording difficult. The feedback loop is invisible. You rarely hear that a record you made helped a decision two levels up. You rarely hear that a record you did not make caused confusion three weeks later.

The reward for a good record is often silence. The cost of a poor one lands somewhere else.

There is also a translation problem. The language of the day and the language of reporting are not always the same. In conversation, engaged might mean someone turned up and talked openly. In a dashboard, it has to mean something countable, consistent and comparable.

Part of the work is meeting in the middle. The record must remain true to the person in front of you, but clear enough for someone else to understand it without being in the room.

That is the gap this playbook keeps closing: between the record someone makes and the decision someone else takes.

3.1 · The dashboard is only as good as the data that fed it

A monthly review opens with one site showing low numbers for participant job interviews and job applications completed. The immediate reading is simple: the site is not generating enough employment activity, and someone needs to step in.

The Business Manager pushes back, because they know the work. Coaches have helped participants apply for roles. Participants have attended interviews. Some have sent applications independently after support from their coach. Others have spoken to employers, updated CVs, or followed up on vacancies discussed in appointments.

So the dashboard feels wrong.

The meeting can quickly become a standoff. Operations can point to the work that happened. BI can only report what the system can see. Both sides may be partly right.

When the number is traced, the dashboard may be doing exactly what it should. It is showing the job interviews and job applications that were recorded in the right place, in the right format, at the right time.

The work may have happened. It may even be mentioned in a note. But if the job application or interview was not recorded in the correct part of the system, the dashboard cannot count it safely. A sentence in a case note may be meaningful to the coach who wrote it, but invisible to the report that is trying to count completed activity across a site, contract or service.

The work happened. The record did not carry it across the line.

That is the important distinction. The site may not have failed. The dashboard may not have failed. The weakness may sit between them, in the recording step that turns real delivery activity into something AKG can see, measure and act on.

A dashboard cannot show what the underlying records cannot support. If a participant completed three applications after coaching support, but those applications were never recorded as completed activity, the participant may have been supported well while the dashboard still shows a gap.

This is why the record matters. It is not just admin after the work. It is the way the work becomes visible to the next person who needs to make a decision.

There is also a timing issue. A low number at the end of the week may not mean the activity is not happening. It may mean the activity is happening faster than the recording discipline around it. That belongs to Part 5, where we look at how to read dashboards well.

3.2 · Three ways a true thing becomes a wrong number

Most bad numbers start as something true that lost the race against the day.

A participant applied for jobs. An interview took place. A coach supported the activity. The progress was real.

But the record did not protect it.

There are three common ways this happens.

First, the record is missing. The job application happened, the interview took place, or the participant reported the activity back to their coach, but nothing carried it into the right part of the system. The activity may sit in someone's memory, in an email, in a case note, or in a conversation, but it does not become countable.

Second, the record is late. The activity happened and was eventually recorded, but after the moment when it could have informed a review, supported a performance conversation, or counted in the right period. Timing is not a small detail here. A true record entered too late can mislead almost as much as no record at all.

Third, the record is inconsistent. The same activity is recorded differently by different people, teams or services. One coach records every application a participant completes. Another only records applications completed during an appointment. One site records interviews when the participant is invited. Another records them only after attendance is confirmed. Everyone may be acting in good faith, but the combined number no longer has one clear meaning.

This resets the usual argument. Data quality is not something BI can fix at the end.

BI can detect missing values, unusual movements, duplicate records, empty fields and logic issues. That detection matters. But BI cannot record an interview that nobody entered, count an application hidden in a note, or decide after the fact whether an employer conversation should have been recorded as an interview.

The quality of data is produced where the data is produced: in delivery, in the day, by the people closest to the work.

That does not mean the recording burden sits only with coaches. The system has to be usable. Managers have to set expectations. Leaders have to create the conditions for good recording. BI has to make the logic clear. If the system makes the right behaviour difficult, that is a design issue as well as a data issue.

But the central point still holds. BI can check what was recorded. Whether it reflects the work begins earlier.

4.1 · Two true numbers that do not agree

A senior leader asks what should be an easy question: how many people are we supporting across the group right now?

Three answers come back from different parts of AKG. They do not reconcile. The meeting naturally starts looking for the wrong number. The uncomfortable answer is that none of them may be wrong.

The numbers can disagree because the word underneath them means different things in different places. One business may count someone from the point a referral is accepted. Another may count only those who have attended a first appointment. Another may count only people active during the month.

Each rule can make sense locally. Each may fit the contract, delivery model and reporting history it came from. The problem appears when those local truths are added together and treated as one group view.

This does not look like a data problem at first. No field has to be broken. No system has to be down. The issue is meaning.

Where AKG has not agreed what a shared word means, the definition still gets made. It just gets made accidentally, in different ways, by different teams, reports or systems.

A definition is a decision about meaning. If the group does not make that decision on purpose, local versions will fill the gap.

4.2 · A shared word is a tool, not a rule

Shared definitions can sound like the group trying to flatten every business into one way of working. That is not the point.

The aim is not to force every local process to look the same. The aim is to make sure that words used in group decisions mean the same thing wherever they are read.

The practical tool is a business glossary: a short, plain list of important terms, each with one agreed meaning and one named owner.

Not every word needs to be in it. The glossary should focus on the words that travel across teams, contracts or businesses and shape decisions. Examples might include what counts as a start, what counts as engaged, what counts as active, what counts as progression, what counts as an outcome, what counts as support delivered, and what counts as a quality issue.

Most local language can remain local. A service should use the words that make sense for its work. The definition only needs to be shared where the number crosses a boundary and informs a shared decision.

That is how this stays useful rather than bureaucratic. AKG should not standardise a word because tidy language feels better. It should standardise a word because a decision depends on comparing it fairly across more than one place.

Keep the list short. Give each definition an owner. Review it when contracts, systems or reporting needs change. Then the three answers meeting starts to disappear, because everyone is finally counting the same thing when it matters.

5.1 · A number tells you where to look, not what happened

A Business Manager opens the site view on Monday morning and one number is red. First Earnings are down at a location.

The pull is immediate: find out who. Which EC? Which team? What has slipped?

The dashboard feels like it has given a verdict.

But a red number is not a verdict. It is the start of a question. It tells you where to look. It does not tell you what you will find.

The jump from this number is down to someone has underperformed skips the steps that matter. Many of those steps lead somewhere other than individual performance.

Is the number real, or is work missing, late or unevidenced as described in Part 3? Has the activity matured, or is it a healthy pipeline that has not reached the point where it can show up yet? Is the definition consistent, or is one site recording something differently from another as described in Part 4?

Only after those checks are complete are you looking at the work itself. Even then, the number gives a location, not a cause. It says look here. It does not say this is what happened, and it certainly does not say this person is responsible.

This is the difference between a snapshot and a story. A single month is one frame of a film. On its own, it can make healthy movement look like failure, especially where starts, earnings and outcomes mature over time.

The number can be true and the reading can still be wrong.

5.2 · How you use a number changes the number

There is a quieter cost to the who reflex. It lands back where this guide started: in the record.

When a dashboard is used mainly to decide who is in trouble, people learn how it is being read. Once a number can be held against you, the rational response is to manage the number.

People become more careful about recording what makes the screen look calm. They become slower to record the messy barrier, the disengagement risk, the honest note that makes a caseload look harder than another team's. Most of this does not happen through deliberate gaming. It happens because people adapt to what the organisation rewards or punishes.

That means the dashboard can quietly damage the very data it depends on.

Part 3 said the record is the product. This is the other side of that idea. How you use a number changes how people record. How people record changes the number. If a dashboard is used as a scoreboard, people start recording for the scoreboard. If it is used as a question, people are more likely to record honestly, because the honest record is the one that gets the right support.

For any dashboard, ask what you would actually do differently if the number moved. If First Earnings are genuinely down at a site, what action follows? Support? A review of referrals? A look at employer engagement? A conversation about evidence collection? A coaching intervention?

If the answer is nothing, the number is not informing a decision. It is just being watched. And a number that is only watched can become noise, theatre or pressure. The dashboards worth keeping are the ones that change what someone does.

6.1 · The most useful thing you can do with a wrong number is say so

An EC glances at a dashboard and something stops them. A participant is flagged as having no CV uploaded, but the EC remembers doing it with them at the last appointment.

The flag is wrong.

Then comes the calculation that decides what happens next. If they say something, they might have to admit the upload failed. It might be a system issue. It might be a small glitch. Either way, it creates a conversation and possibly an awkward one. Leaving it alone costs them nothing in the moment.

So the flag stays.

That one flag does not stay small. It becomes part of a BM view of outstanding actions, then part of a Head of Operations view of site progress, then possibly part of a wider decision about whether a team is keeping pace. A participant might be chased for something already done. A site might look behind on work it completed.

The person who saw the error pays no obvious cost for staying quiet. The cost lands somewhere else, on a decision they may never see.

This is why the person who notices is doing one of the most valuable jobs in the quality chain. They are usually in Operations, because they are closest to the work. BI can build alerts for patterns: sudden changes, unusual blanks, values outside a normal range. That matters. But no alert can always catch a false flag that looks normal from above.

Sometimes it takes the person who was there to say, that cannot be right.

The quality of AKG's data depends not only on systems and reports, but on whether people feel able to say that out loud.

That feeling is created by the response. If the last person who raised an issue got blamed, sighed at or ignored, the lesson spreads quickly. If they were thanked and the issue was fixed, the organisation has just turned people closest to the work into an early warning system.

AKG cannot choose whether errors happen. It can choose whether the people who see them first say so.

6.2 · Fix the cause, not just the instance

Suppose the EC does say something. The next common failure is quieter: the CV gets uploaded again, the flag clears, and everyone moves on.

The instance has been fixed. The cause may not have been.

If the upload silently failed once, it may fail again. If the field mapped incorrectly once, it may keep mapping incorrectly. If people do not know the right process, the same mistake will repeat across other participants, teams or sites.

A problem fixed one case at a time is a problem AKG has agreed to fix forever.

The better loop is simple: spot it, trace it, prevent it.

Spotting is often Operations' strength because Operations sees the work directly. Tracing asks why the issue happened: was the record missing, was the upload failed, was the wrong field used, did the dashboard logic misunderstand it, or did the system not commit the change? Preventing means changing the process, system, guidance or report so the same issue is less likely to happen again.

The test is simple. The same error twice is not bad luck. It is a process that was tidied, not fixed.

For this to work, AKG needs two things. First, a known route, so the person spotting the issue does not have to invent who to tell. Second, a named owner at the other end, someone who can decide the right answer and make the prevention happen.

The urgency depends on the decision attached to the number. A wrong flag feeding a live contract review, safeguarding judgement, payment claim or operational intervention needs to be raised quickly. A wrong flag that no one is about to act on can take its place in the queue.

Not every wrong number is an emergency. The ones attached to decisions are.

7.1 · "Everyone's job" is nobody's job

A recurring issue appears in a review. A particular field is unreliable across several sites and has been quietly bending a number for months.

The room agrees it matters. It should be sorted.

Then the question lands: who owns it?

Operations says it depends how BI defined the field. BI says it depends what Operations records. IT says the system is doing what it was configured to do. Everyone is partly right, which is exactly the problem.

A thing that is everyone's responsibility in general is no one's responsibility in practice.

This is where data problems survive. Not because people do not care, but because no name is attached. The work described in the first six parts only happens if someone owns each piece of it: recording well, agreeing definitions, reading dashboards properly, raising errors and fixing causes.

Otherwise the issue sits between roles. Everyone can see it. Nobody is wrong to leave it for someone else.

The fix is not heroics or another standing meeting. The fix is explicit ownership. For anything that matters, who owns this should have an answer before the problem appears.

7.2 · Five owners, one chain

The answer is not one team owning all data. The answer is each function owning the part of the chain only it can own, and knowing where its responsibility hands to the next.

Operations owns recording behaviour and the local use of data: what is captured, how accurately, how completely and how promptly. It also owns the local meaning of the terms it records, what a word like outcome or barrier means in the work, while the group-agreed version of a shared word is settled with leadership. No other function is in the appointment, the review or the delivery moment, so no other function can own the record itself. Operations also owns the first sign that something looks wrong, because it sees the work closest.

BI owns reporting logic, traceability and insight products. BI does not decide what a word means; that is a business and leadership call. Its job is to apply the agreed meaning consistently wherever a number is read, to flag when a definition is drifting between sites, and to make sure reported figures can be traced and stood behind.

IT owns systems, access, security and data movement. If an upload fails, a feed breaks, access is wrong or data does not move as expected, IT owns the platform question, even when Operations spots the symptom and BI sees the reporting impact.

Finance owns reconciliation to cost, evidence, funding and payment. Finance does not own the delivery record or the reporting logic, but it owns the point where data becomes commercial confidence.

Leadership owns priorities, decisions and consequences: shared definitions, safe issue raising, time to record properly, and making sure honesty is never punished. Strong Operations, BI, IT and Finance teams can still fail if leadership creates conditions where people are rushed or defensive.

The point of ownership is not to draw lines so people can hide behind them. It is to make handovers clean. When a field is unreliable, the answer should not be a round of shrugs. It should be a short conversation between named owners about where the chain broke and what needs to change.

Ownership turns the chain from a pile of good intentions into a working system.

8.1 · Most reporting explains the drop after the person has already gone

A monthly pack lands. One site's engagement is down. The drop is real, checked and explainable. Several participants disengaged over the past few weeks.

The report is doing its job. It is telling leadership what happened.

The problem is timing.

By the time the number appears, the disengagement is weeks old. The participants are already further away from the service. The remaining decisions are mostly about damage that has already happened.

This is the ceiling most reporting sits under. Good reporting can still arrive too late. A backward looking number can explain, but it cannot prevent.

When the work is about participants, that gap matters. It is the difference between knowing a participant disengaged and reaching them in the week they started to drift.

Prevention does not have to mean something exotic. It is mostly about timing. Disengagement rarely appears from nowhere. There are usually signals: missed appointments, contact going quiet, a barrier logged but not resolved, a missed Work Pathway session, an action not completed, a participant becoming harder to reach.

The information may already exist. The question is whether AKG assembles it early enough to act, or only later when it becomes history.

Preventative insight is not a crystal ball. It is the things AKG already records, read early enough to matter.

8.2 · The whole chain only matters because of where it ends

Prevention is harder than reporting. It is not free.

Acting early means accepting that some signals will turn out to be nothing. A participant may be fine. A follow up may not have been needed. A flag may clear itself.

The instinct is to wait for certainty. But certainty often arrives too late.

The discipline is acting on a good enough early signal, because the cost of an unnecessary follow up is usually smaller than the cost of the follow up that never happened.

That trade matters for AKG because the work is about outcomes for people, not just clean reports.

This is where the whole guide closes its loop. Early insight is not possible without everything that came before it.

You cannot see disengagement forming if the records were never made. You cannot trust a pattern across sites if the definitions do not hold. You cannot act on a dashboard if people are recording defensively. You cannot fix a false signal if nobody feels safe to say it is wrong. You cannot prevent recurring issues if nobody owns the cause.

Preventative insight is not something AKG simply buys and bolts onto the top. It is what good recording, shared definitions, honest issue raising, clear ownership and evidence based management add up to when they work together.

That returns us to the sentence the whole playbook is built on: data at AKG is not about dashboards. It is about helping people make better decisions, earlier, and with more confidence.

By now, every word in that sentence has a job. Better decisions, because the record is true and the words mean the same thing. Earlier, because the signal is read while something can still be done. With more confidence, because the chain is owned and trusted.

And the reason it matters is the word the sentence does not say but always means: people. A participant reached in time. A barrier resolved before it becomes disengagement. A team that sees someone slipping and acts.

The value of data is not that AKG knows more. It is that AKG sees the signal early enough to act while the participant can still be supported.

That is what the data is for.