Case study · GradNextSteps
Structuring high-stakes guidance around a single shared record
How adviser preparation time was reduced by replacing scattered spreadsheets and email with a staged decision workflow and a single student record.
- Client
- GradNextSteps
- Industry
- Education and career guidance
- Published
- Last updated
Executive summary
In brief
Advisers were spending the majority of each session reconstructing a student's situation from spreadsheets, documents and email threads. The work defined the decision process as explicit stages, moved each student's context into one record, and generated a pre-session briefing from the material already on file. Advisers see who is blocked and why without asking; institutions get progress visibility without a reporting request. AI produces the briefing, but every statement links back to its source so the adviser can verify rather than trust.
Business context
The situation before the work
Guidance quality depended on adviser experience and on how much preparation time each could afford. As student numbers grew, preparation was the first thing compressed, which reduced session quality precisely as demand increased.
Problem statement
What specifically had to change
The process had no shared definition. Two advisers described the same student's position differently, no one could see aggregate progress without manual collation, and preparation work was repeated at every session because context was not retained anywhere durable.
Approach
How the work was sequenced
Order mattered more than speed. Each step produced a decision, a prototype or a release.
- 01
Define stages with the advisers, not for them
Stage names and entry conditions were agreed with practising advisers first. Naming determines behaviour, and imposed vocabulary is quietly ignored.
- 02
Make the student record the single context
Goals, documents, prior sessions and decisions live on one record. Nothing about a student needed to be reassembled from elsewhere.
- 03
Generate briefings, require verification
A pre-session briefing is drafted from material on file, with each statement linked to the document or entry it came from.
- 04
Surface blockers ahead of everything else
The adviser dashboard leads with students who are stalled and the reason, rather than with totals.
Architecture decisions
Decisions and their rationale
Recorded with reasoning, so a future team can tell whether the original constraint still applies.
- Model the process as an explicit stage machine
- Reporting, blockers and service levels all derive from stage state; free-form status cannot support them.
- Three separated roles with distinct data reach
- Students, advisers and institution administrators need genuinely different views; a single permissioned view would have leaked context in both directions.
- Documents isolated from application data with signed expiring access
- Student documents are sensitive and should not be reachable through the application's normal read paths.
- Server-rendered public content, authenticated app behind it
- Guidance content needs to be discoverable in search; student data must not be.
Technology choices
What was chosen, and why
- PostgreSQL with row-level access policies
- Three roles with different reach over the same records is exactly what row-level policies exist for.
- Stage transitions recorded as events
- Progress reporting and blocker detection both read from the event log rather than from mutable status fields.
- Hosted language models for briefing generation
- Summarisation quality mattered more than model ownership, and the boundary keeps provider choice reversible.
Challenges
What went wrong first
Included because the response is usually more instructive than the plan.
- Early briefings were read as recommendations
- Presentation changed to a source-linked context summary with recommendation language removed entirely, and adviser framing made explicit in the interface.
- Advisers resisted additional data entry
- Entry was folded into the actions they already performed, so the record is a by-product of the session rather than a task after it.
- Institutions wanted reporting that risked exposing student detail
- Aggregate views built over stage events only, with identifiable detail excluded from institutional reporting.
Outcome
What changed
- Adviser sessions begin with context already assembled rather than reconstructed.
- Stalled students and the reason are visible without a reporting request.
- Progress definitions are shared, so two advisers describe the same position identically.
- In development; adviser preparation time and stage completion rate are the tracked measures.
Key learnings
What carries forward
- Advisers adopt systems that remove preparation work and resist systems that add reporting.
- Stage vocabulary must come from practitioners or it will be bypassed.
- AI summaries earn trust only when every statement can be opened at its source.
- Recording transitions as events makes later reporting requirements cheap to satisfy.
The best products begin with the right questions.
Send the business context and the constraint you are working against. I will reply with a direct read on the approach I would take, and whether I am the right person for it.