Driving school pupil management software should create one continuous record from accepted enquiry to passed learner. The school needs contact, allocation and commercial history; the instructor needs teaching context; the pupil needs a clear, deliberately reduced view of lessons, progress, messages and hours remaining.
When those three views are separate databases, staff reconcile them by hand. When they are the same unrestricted database, private school information leaks into the wrong role. The goal is one source of truth with different projections.
What belongs on the school record
A useful pupil record can connect:
•
- identity and contact details needed for tuition;
•
- enquiry source, status and assignment history;
•
- upcoming and completed lessons;
•
- prepaid hours and payment ledger entries;
•
- DVSA-aligned progress and test outcomes;
•
- pupil terms version and acceptance evidence;
•
- school-pupil messages and notification preferences;
•
- retention review date and any legal hold.
Avoid turning the notes field into a dumping ground. Sensitive safeguarding, medical, identity or complaint material needs the school's proper process and restricted case/document controls.
Instructor view: enough to teach, no more
An assigned instructor needs the pupil's lesson schedule, useful contact details, shared progress, teaching notes and payment context permitted by the school. They do not automatically need other instructors' pupils, the central enquiry pool, internal complaints or school-wide revenue.
When a pupil is reassigned, access should move with the assignment and leave an audit reason. Old access should not depend on the instructor remembering to remove a downloaded contact.
Pupil view: transparent but not editable everywhere
The pupil portal should answer four common questions:
1.
When and where is my next lesson?
2.
What have we covered and what needs more work?
3.
How many prepaid hours remain?
4.
How do I message or request a change?
Letting the learner see progress can improve the conversation with instructors and parents, but the scale must be explained. The DVSA learning record is a way to track development; it is not a promise of a test pass.
Pupils should request diary changes rather than directly overwriting a school-managed calendar. Internal notes, staff case details and other pupils must never be part of the portal payload.
Balances need an append-only ledger
A single editable “hours left” field is easy to corrupt. Prefer transactions: purchase, lesson deduction, adjustment and refund, each with a timestamp and reason. Lesson completion should deduct once even if a mobile request is retried.
Payment success should come from a verified provider event, not the browser redirect alone. The ledger can then show the school what happened without storing card details.
Terms evidence must survive edits
If the school changes its pupil terms, earlier acceptance must still point to the exact wording presented at the time. Store an immutable version and content hash, plus when and how acceptance was recorded. Publishing new terms creates a new version; it must not rewrite history.
Retention completes the lifecycle
Passed and inactive pupils should receive a review date based on school policy. An authorised manager decides whether the information is still needed. A legal hold blocks disposal while a documented claim or complaint requires preservation.
The ICO's guidance emphasises accountability and appropriate controller/processor arrangements. Software can provide controls and evidence, but the school still decides its lawful purposes and retention needs.
Sources checked
•
- DVSA lesson-by-lesson progress record
•
- ICO controller and processor guidance
•
- GoRoadie Pro pupil-app information
Sources were checked on 15 September 2026.