How many students are at offer stage? Why that question usually has no answer

An owner asks how many students are at offer stage, and on a spreadsheet the honest answer is that it would take an afternoon to find out. Not because nobody cares. Because the stage lives in whoever last touched that row's memory, not in a column anybody can filter, and a spreadsheet with three hundred students and two counsellors on leave is not something you count in your head.

The question sounds like it has one answer. It actually has two, and a consultancy that only ever tracks one of them is missing half of what it is asking.

The stage every student carries

Every student in the pipeline carries exactly one stage at a time: enquiry, counselling, test prep, applying, offer received, visa lodged, departed, or lost. It is a field on that student's record, set by whoever is running their file, the same way a next action or an assigned counsellor is a field rather than a fact someone has to remember. Because it is a field, it can be counted, and the office's Reports screen does exactly that: a bar for each stage, scaled against whichever stage currently has the most students in it, with the figure printed next to it. "How many are at offer stage" is the "Offer received" bar, read straight off the screen, no counting required.

That is the number an owner usually means when they ask the question out loud. It answers "how much of my office is close to the finish," which is a capacity question as much as a sales one: a run of ten students reaching offer stage in the same fortnight is ten families who are about to need fee payment help, an NOC and a visa appointment at the same time, whether or not anyone saw it coming.

The applications sitting underneath that stage

The second number lives one level down. A single student does not make one application; they usually have two or three open at once, each to a different institution, each with its own status: planned, submitted, conditional, offer, and a handful of closing states once it is answered for good. These live on an Applications screen of their own, every one still open across the whole office, ordered by whichever deadline is closest rather than by student, because a deadline is the one thing in this list that cannot be moved by anyone's goodwill.

That screen counts its own thing: applications whose own status is offer or conditional, which is "offers in hand" rather than "students at offer stage." It also flags two problems a stage count cannot see on its own. One is a deadline inside the next fortnight, which stays a deadline no matter how calm the rest of the file looks. The other is an application gone quiet, nothing heard from the institution in three weeks, which is usually a portal asking for a document nobody has checked recently rather than a rejection in disguise.

Why the two numbers are not the same number

A student reaches "Offer received" on their overall stage because somebody looking after their file decided they had. An individual application reaches "offer" because an institution answered. Nothing in the system ties the two together automatically, on purpose: the stage is a judgement about where a student's journey has got to, usually made once the picture across their open applications is clear enough to act on, and forcing it to flip the instant any single application gets an answer would make the stage count noisy rather than useful. A student with one offer and two applications still pending is arguably not finished deciding yet, and an office is allowed to hold them at "applying" until the choice is actually made.

That means both counts are real and neither one replaces the other. The stage count answers how many students, as whole people, the office is close to delivering. The applications count answers how many decisions are currently sitting on a family's kitchen table, and how many of the office's own deadlines cannot be allowed to pass quietly. An office that only watches the first number can be surprised by a missed deadline on an application the stage count never mentioned, because the student themselves had not been moved yet.

What this actually prevents

The failure this replaces is not dramatic. It is the Friday somebody tries to tell a partner institution how many offers the office is currently sitting on, and the true answer requires opening files one at a time because "offer" was never a column, only a word written in different people's notes in different ways. What a general CRM gets wrong about a student file is exactly this: a sales CRM tracks a deal that closes once, not a journey with a stage on it and a shelf of open applications underneath that stage, each with its own clock.

It is also the reason two branches counting stages differently cannot be compared at all, and the reason a quiet student and a quiet application look identical from the outside but need two different people to notice them. Treat "offer stage" as one number and you will eventually be wrong about something a family is waiting on. Treat it as the two numbers it actually is, and the question an owner asks in passing has an answer that was already sitting there before they asked it.