Orchard Rock Training

Orchard Rock Training — App Plan & Specification

A working brief for the build. Plain-English on purpose, so everyone — Orchard Rock and the build partner — is picturing the same thing.

Last updated: 01/07/2026

1. The big picture

One app, three doors (portals) onto the same shared information:

Client portal — what our customers (care providers) see
Trainer portal — what our trainers see
Office portal — what our team sees (this already largely exists as our current Dashboard)

It's not three separate apps. There's one central set of data and each portal shows the slice relevant to that person. Enter something once and it's used everywhere — a trainer fills in a register, the office uses it to produce certificates, the client sees the result.

The golden rule: the app never makes a booking on its own. Clients send requests; the app does the legwork (who's free, who's qualified, who fits); a human in the office always places the booking. This protects our biggest USP — the personal relationship with clients.

2. How the data is stored & kept in sync

One central database in the cloud is the single source of truth (trainers, bookings, registers, certificates). Nobody keeps their own copy.
Every person has their own secure login. The app only shows what their role allows — a trainer sees just their own work; the office sees everything.
Live sync: when someone opens the app it pulls their data live; when they change something it saves straight back to the centre, so everyone always sees the latest.

Works offline, syncs later (key requirement)

Trainers regularly deliver in care homes with poor or no signal. The app must work fully offline — open the booking, fill in the register, capture delegate signatures, enter scores, clock in and out — all stored on the tablet. The moment the tablet gets signal again, it automatically syncs everything up to the central database. The trainer should never lose work or be blocked by a dead connection.

3. Where everything lives (the connections)

Central database — the app's own home for records (bookings, trainers, registers, certificates, availability, clocking).
SharePoint — for resources (course materials). The app connects to SharePoint but only to the folders we choose, using Microsoft's "Sites.Selected" access. By default it can see nothing; an admin grants it access to one location only.
It connects to the live, updated Course Material library only. The Course Creation (drafts), archive and other folders stay invisible to the app.
Cleanest option: a dedicated "Orchard Rock App" SharePoint site holding only the live packs, so the boundary is crystal clear.
No personal/delegate data is to be kept in that folder — training materials only — so there's no GDPR exposure.
Trainers get read-only access through their login; update a file once and every trainer has the latest version.
Accounts & payments — kept the way they work now. The app does not plug into an accounts system. Invoicing and payment are handled by the office exactly as they are today. The only link is the certificate rule: when the office marks a course as paid, the app releases that course's certificates on the client portal. (Connecting an accounts package to automate this could be looked at later, but it is not assumed.)
monday.com — current source of truth / admin. Our boards (Trainers, Booking Checks, Content Management) hold today's data. To view or amend trainers, we use the Trainers board (the portal shows trainers marked "Current"). Decision for the build: keep monday.com as the live data home, or migrate into the app's own database over time.

4. The booking-request flow

Client submits a request (Client portal) — subject, preferred dates, location, number of delegates, notes. A request, not a booking.
It lands in the Office queue.
The app does the legwork — matching driven by real history. Instead of guessing from a job title or home town, the app looks at the bookings database (last 2 years) and surfaces trainers by what they have actually delivered and where they have actually travelled: - Qualified = the trainer has delivered that course (or its subject) before. This is the truth about who can teach what — far more accurate than a job-title label. - Closest = ranked by the venue postcode. Trainers who have delivered in that postcode area before come first (with a count, e.g. "worked here ×5"); everyone else is ordered by real travel distance from the postcodes they've worked in — so a Cardiff job surfaces the trainers who cover South Wales, never a Scottish trainer at the top. - All qualified, available trainers are shown (not capped), in-area first then nearest-by-history.
A human places the booking — picks the trainer, confirms with the client. Nothing auto-confirms.
The trainer is sent the booking to accept or decline. A placed booking arrives in the trainer's portal as pending their confirmation. They can Accept or Decline any booking we give them. Decline notifies the office so we can reassign. Once accepted, it locks — it can't be declined or changed in the app.
It appears in the trainer's schedule.
The trainer delivers and fills the digital register (works offline).
The register's scores feed certificate production.
Certificates are released to the client once the office marks payment as received.
The renewal clock starts — expiry tracked, reminders triggered.

5. Trainer portal — full specification (prototype built)

Each trainer has their own private login and sees only their own bookings and details. (The prototype uses a name dropdown for testing; the real version is individual logins.)

My Bookings

The trainer's own courses, split Upcoming / Completed / All.
Each booking shows subject, client, care home/site, area, venue, full session times, status.
Today's bookings are made obvious with a banner so the trainer immediately sees what they're delivering that day.
Accept / Decline. A newly placed booking shows as awaiting confirmation with Accept and Decline buttons. Decline notifies the office to reassign; once accepted it locks and can't be declined or changed in the app.
Address and Equipment buttons sit on each booking card (Address opens directions; Equipment lists what to bring, drawn from the equipment log).
Virtual sessions are clearly badged, and the booking holds the joining (Zoom) link for the trainer to open — added by the office.
Completed bookings show a "Completed Pack" marker; upcoming/today cards stay clean (no register-status clutter).
Tap a booking for full detail and to open its register and clocking.

My Availability

A calendar the trainer keeps up to date: available (green), unavailable (red, they set it), booked (navy, locked).
Booked days are locked — a trainer cannot mark themselves unavailable on a day where a booking already stands. (This is why there's no "availability clash" to chase in the office; it simply can't happen.)
This feeds the office's "who's free" matching in the booking flow.

My Certificates

The trainer's own qualifications with renewal dates and flags (valid / due soon / expired), and a warning badge when something needs attention.
A document store (file holder) for each qualification — upload/replace the actual certificate.
A wider Certificate library listing all their training certificates.
Nursing PIN only shows for nurse roles — mandatory-only trainers don't see it.

Resources

Course materials per subject (PowerPoint, Handout, Questions, plus Competency Form, Risk Assessment, Health Declaration, Summary where they exist) — pulled from SharePoint.
Scoped to the trainer: they only see subjects in their field and/or tied to their upcoming bookings, not the whole library. (A "view all" option exists as a fallback.) Subjects for upcoming bookings are highlighted.
Clear warning: these materials are Orchard Rock property; using them outside Orchard Rock breaches the trainer's contract and NDA.

6. The booking as a hub — paperwork, clocking, notes

Opening a booking gives the trainer everything for that day in one place, in sections: Clocking, Paperwork, and Trainer notes. All of this paperwork is attached to the booking and is the same record across all three portals (trainer fills it, office uses it, client sees the relevant parts).

Paperwork holds:

Register & scores. Attached to the booking and starts blank — we don't get delegate lists in advance. On the day the trainer adds each delegate by full legal name (with a warning that spelling mistakes incur a penalty fee for certificate amendments) and home/workplace. A scored section at end of day captures each delegate's % (75%+ passes). Scores flow into certificate production (eventually removing the separate cert database), and the % prints on the certificate. (Signing the register was removed.)
Competencies. For courses with a practical competency (e.g. Catheterisation, BLS, Fire Marshal, Venepuncture, Moving & Handling…) it shows as a grid — delegates down the left, competency items across the top, like the paper form. Each cell is three-state: tap once = achieved (✓), twice = exempt/couldn't do, e.g. injury or pregnancy (✗), a third tap clears it. Items written "(min N)" (e.g. Scenario Numbers Used (min 2)) show number-entry boxes instead of a tick. There's a competency notes box underneath for recording reasons for any exemptions. The office can add/edit the competencies per subject.
Health declaration. For physical courses (moving & handling, MVA/PMVA, safe holds, first aid/BLS/EFAW, hoist, etc.) each delegate must complete and sign a health declaration. Attaches to the delegate like consent, and is required to clock out on those courses.
Photo / video consent. Per delegate — consent (with a signature) or decline. Optional — does not block clock-out.
Knowledge test (end-of-day questions), digital. Every course's question paper is digitised. Delegates scan a QR code to answer on their own phone (so the tablet isn't passed around 15 times), with a printable paper version as a back-up that can still be marked in. Multiple-choice answers are auto-marked; written answers the trainer marks. The result drops straight onto the register as the delegate's score. When scores are in, a small coloured knowledge-gaps bar shows which questions the class struggled with (green/amber/red), and highlights any question more than 2–3 delegates got wrong, so the trainer knows what to recap.
Risk assessment. A training-room risk assessment matching the paper form (14 checks, hazards/controls, signed). Locked until the trainer clocks in — it can't be filled before the day starts.
Delegate feedback. Confidential feedback collected from delegates (star ratings, whether papers were marked, suggested improvements). The trainer never sees the answers — only the office does. Each delegate enters a valid email used only to confirm the feedback is genuinely theirs (not the trainer's own) — it is not stored and is used only for identity and to email them a copy of the course handout on submit. Feedback locks once submitted (no re-do), and the time each piece of feedback comes in is logged. Multi-session days collect a separate set of feedback per session. Feedback is required before the trainer can submit the pack and clock out — but only the final session's feedback gates clock-out; an earlier session's feedback being in does not unlock it.

Submit Pack & clock out. At the end of the day the trainer taps "Submit Pack to office & clock out." If anything is outstanding it lists exactly what's missing (naming any delegate who hasn't done feedback) rather than failing silently. If everything's complete it clocks them out with a friendly send-off ("safe travels", or "pleasant evening" for a virtual). Clock-out is blocked until every delegate is scored, all competencies are complete (✓ or exempt), every delegate has signed the health declaration on physical courses, the risk assessment is done, and feedback is in. Photo/video consent is optional. An office override exists for the rare case where someone leaves without submitting. (Plus the late-in → office flag and early-out → office flag.)

On the client portal, certificates are locked until the office marks payment as received.

7. Clocking rules

Trainers clock in and out on the booking (works offline). Clocking-in happens when they open the day; the clocked-in time shows on the booking's side panel. There's no separate "clock in" button to forget.
Clock in after 9:00am → prompt: "Did you let the office know in advance?" If No, the trainer adds a brief note and it flags to the Office portal's Clocking Flags page to follow up.
Clock out before 4:00pm → prompt: "Have you informed the office of your early finish?" If No, it flags to the Office portal's Clocking Flags page for the office to follow up.
These flags go to the office only — never to the client.

8. Client portal (prototype built)

One login per client (e.g. Advinia, Harbour, HC-One, Akari, Hallmark…), pulled from our real client list. No admin names pre-loaded — extra users are added when a client first signs in and sets a password. A client sees all of their homes/sites.
Request Training — free-text course box (the client writes what they need in their own words; the app recognises the course and routes the details to the office). Never a direct booking — the office always confirms.
Our Courses — our full course range with summaries, each deep-linking to that course's page on orchardrocktraining.co.uk (drives traffic to the website), plus a "Request this course" shortcut. The link is built from the course name to match the site's /courses/<name>/ pattern.
My Bookings — their bookings across all homes (requested / confirmed / completed). Trainer name is hidden from clients.
Certificates — grouped by course (date + home). Payment is per course/invoice: a whole course locks or releases together. Released courses offer Download all as one PDF or individual downloads (the same approach as the office Dashboard); unpaid courses show "Awaiting payment".
Training Matrix — staff × subjects per home, colour-coded (in date / expiring / expired / not trained), exportable to CSV — their CQC/compliance evidence; also drives our renewal prompts. Covers expiring and overdue training directly, so there is no separate Renewals screen on the client portal.
Contact Us — a clear human point of contact kept front and centre.

9. Office portal (existing Dashboard + additions)

Keeps everything the current Dashboard does (certificate generation, booking reminders, trainer pay reports, course bullets), with the sidebar tidied — Certificate generation, Certificate Details and Course Bullets grouped together under Certificates — plus the connective tissue:

Booking Requests queue from clients, each with Find trainer & place. Matching is driven by the bookings database: qualified-by-delivery and closest-by-travel-history (see §4), shown in-area first then nearest, with a map link to each trainer's base when deciding who to assign.
Place & assign — confirms the booking and sends it to the trainer to accept or decline.
All Bookings — every booking across all trainers/clients, searchable and filterable (incl. Today). Open one to see its full paperwork pack, progress checklist and certificates.
Change trainer (reassign). Any booking that hasn't been delivered yet has a Change trainer button — it lists the other qualified, available trainers ranked by distance from their base, so if a nearer trainer frees up the office can move the job to them in one click. The client is unaffected and the new trainer is notified to accept.
Paperwork packs — the full pack per session (scored register, competencies, marked question papers, risk assessment, health declarations) downloadable as one PDF named by booking reference (e.g. ADVI-1607 - Pack), with the option to save a copy to SharePoint.
Alerts — trainer certificates only (expired or due within 90 days). These clear automatically when a renewed certificate is uploaded and synced; the office can also work them with a status: New → Trainer emailed → Resolved (emailing drops it to the bottom and it re-flags "Follow-up due" after 3 days).
Clocking Flags (own page, separate from Alerts) — late clock-ins and early finishes that weren't pre-notified, with the trainer's note, and the same New → Emailed → Resolved chase workflow.
Course Content — a tracker for every course's materials and when each was last reviewed, on a 12-month review cycle. Shows what materials exist per course, a next-review date, and status (overdue / due within 60 days / in date / flagged for update); overdue and flagged courses sort to the top. The office can Mark reviewed (resets the clock) or Flag for update. Built from the Content Management board.
Trainer Availability — read-only view of any trainer's diary.

When a trainer declines a placed booking, it drops back into Booking Requests as high priority (flagged "trainer declined", sorted to the top, with the declining trainer excluded from the re-match). - Registers inbox — registers coming back (incl. synced-from-offline), feeding certificate production.

10. Business rules at a glance

No auto-booking — requests only; a human places every booking.
Trainer matching is data-driven — qualified = has delivered the course before (bookings DB, last 2 yrs); closest = ranked by where they've actually travelled (postcode history), in-area first.
Placed bookings must be accepted by the trainer. Decline → office reassigns; accepted → locked, can't be declined or changed.
Trainers can't mark themselves unavailable on a booked day (so availability clashes can't occur).
Trainer list is managed on the monday.com Trainers board ("Current" = appears in the app).
Registers start blank; delegates self-add on the day.
Full legal name required; spelling errors = amendment penalty fee.
End-of-day questions are digital (QR + paper back-up), auto-marked, and feed the register score.
Scores captured on the register → produce certificates.
Feedback is confidential to the office (trainer never sees it), locked once submitted, requires a valid non-trainer email (identity only, not stored) and emails the delegate the course handout; feedback is required to clock out.
Certificates released to clients only when paid.
Clock-in after 9am / clock-out before 4pm (not pre-notified) → office Clocking Flags page (office only, never the client).
Office alerts and clocking flags carry a status workflow (New → Emailed → Resolved, re-flag after 3 days).
PIN shown for nurse roles only.
Resources scoped to the trainer's field/upcoming bookings; NDA/contract warning shown.
App works offline and syncs when signal returns.
Resource files via SharePoint, chosen folders only, no personal data in them.

11. Open decisions for the build partner

Data home — keep monday.com as the live source, or migrate to the app's own database.
Authentication — how logins/roles are set up across the three portals.
Payments — for now this stays a manual office step (mark a course as paid), matching how it is done today, which then releases certificates. Whether to automate it via an accounts/payment system later is an open question — not assumed.
Offline sync details — how the tablet stores and reconciles data (the trainer's device is authoritative for their own register).
SharePoint setup — dedicated app site vs granting access to the existing live library; admin to grant "Sites.Selected".
"Best suited" rules — the prototype ranks on delivery history + travel history + availability (see §4). To confirm for the build: should we also factor client history/relationship, trainer rating, or cost/fee bands, and how to handle a brand-new trainer with little history yet?
Delegate logins — do client delegates ever log in, or does the client contact manage everything?
Feedback identity email — confirm the approach of a non-stored email purely to verify the delegate (and send the handout), vs a tokenised link, when the real app is built.

12. Build status

Trainer portal — clickable prototype built and tested: login, bookings (with today banner, Address/Equipment, virtual + joining links), accept/decline of placed bookings, availability (booked days locked), certificates (renewal flags, file holders, library), resources (scoped + NDA warning), blank registers, digital knowledge test (QR + paper, auto-marked) with knowledge-gaps bar, competency grids, signed health declarations, room risk assessment (locked until clock-in), confidential delegate feedback (email identity, handout emailed, locked after submit), and "Submit Pack & clock out" with the late/early flags. Built on real data from the monday.com boards and the bookings database.
Client portal — clickable prototype built and tested: one login per client (22 real clients), free-text training requests, request-a-change on a booking, Our Courses catalogue with website deep-links, My Bookings (trainer hidden), Certificates grouped by course and locked until paid (download all as PDF or individual), and exportable Training Matrix. Bookings are real; delegates/certificates/matrix are realistic demo data until trainers submit digital registers and the office confirms payments.
Office portal — built on the current Dashboard with the new sections: Booking Requests with history-based matching (qualified-by-delivery + closest-by-travel-history, in-area first), Place & assign (confirms and sends to the trainer to accept/decline), All Bookings with the full paperwork pack per session (one PDF per booking, optional save to SharePoint), Change trainer (reassign) ranked by distance from base, Alerts for trainer certificates (New → Trainer emailed → Resolved), Clocking Flags for late-in/early-out, and a Course Content review tracker plus read-only Trainer Availability — all layered onto the existing certificate generation, booking reminders, trainer pay reports and course bullets.

Known issues (as of 01/07/2026 build)

Client portal Renewals removed from scope. An earlier build included a separate Renewals screen on the client portal; this has been removed, as the Training Matrix already surfaces expiring, due, and expired training and a duplicate screen was not needed.
Office portal Renewals screen not yet linked. The office portal has a built Renewals screen (expiring/expired training with one-click rebooking reminders), but it is not yet linked from the navigation menu. This requires a menu item to be added.
Fixed: the client portal's Request Training screen previously showed "[object Object]" instead of the home name for any client with exactly one site.