Platform 1 · internal
Tutorials
Every page has a page tour and every process has a walkthrough. One narrator across the programme. Each tutorial plays over the live screen and highlights the part it is describing, with autoplay on by default.
Process walkthrough · 2:17 · /, /tutorials
What EPMS is, and the eight-stage spine
EPMS holds one record for a piece of work from request to closure. Work moves along eight named stages; the stage is separate from the status, and CRM-sourced fields are marked and read-only here.
Process walkthrough · 2:24 · /requests/new, /requests, /tutorials
Raise a request
Everything enters EPMS as a request. Pick the customer from the CRM, describe the problem rather than the solution, say what you need back and by when, then submit. The owning team is notified; the customer is not.
Process walkthrough · 2:17 · /requests/$id, /requests, /tutorials
Assess and qualify a request
Assessment has two steps, route then resources, each owned by a flat approval team. Record the reasoning as well as the outcome. Qualifying creates a project carrying the request's reference; sending it back to sales is a recorded outcome, not a deletion.
Process walkthrough · 2:02 · /requests/$id, /requests, /tutorials
Review the route as the Approval team
Route review is the first step and it belongs to the Approval team – Route, a flat team with no leader. Choose one of the four routes, send it back to sales, or ask for more information and name the follow-up owner.
Process walkthrough · 1:58 · /requests/$id, /requests, /tutorials
Review resources as the Approval team
Resource review is the second step. It belongs to the Tooling led and Solution led team, or to the Application Engineering team, according to the route that was decided. It sets the project lead, the people and the equipment.
Process walkthrough · 1:49 · /requests/$id, /tutorials
Decide the route inside the route review
The route is decided inside the route review, by the Approval team – Route, with the reason recorded alongside it. The platform suggests a route from the assessment; overriding the suggestion is normal — leaving it unexplained is not.
Process walkthrough · 2:00 · /projects/$id, /tutorials
Build the offer and manage S O W versions
The scope of work is data first: deliverable lines, versioned. The proposal is a version chain built from it, technical and commercial. The document is produced at agreement as the AS9100 artefact, and pre-sales effort is booked as it happens.
Process walkthrough · 2:23 · /projects/$id, /tutorials
The negotiation loop, and logging an event
Stage five is a loop: present, receive a response, revise, re-issue. Every customer intervention is logged as an event tied to the versions the customer was holding. Re-issuing makes a new version; it never overwrites. Actions raised here go to the action log, and the project plan stays in draft.
Process walkthrough · 1:54 · /projects/$id, /tutorials
Record an agreement
Stage six captures what the customer actually agreed to: the type, the reference, the dates, the value and any KPI triggers. Recording it locks the scope of work and produces the AS9100 document from the version that was agreed.
Process walkthrough · 2:01 · /projects/$id, /tutorials
Run delivery with the plan and the action log
Delivery runs on two surfaces: the plan, which holds gates and milestones against a baseline, and the action log, which holds the work in between. Actions are internal by default and overdue ones escalate. Move dates on the plan, not in your head.
Process walkthrough · 1:57 · /time, /projects/$id, /tutorials
Log time and costs
Book hours in the weekly grid against the project the work belonged to, including pre-sales. Costs land on the project's financial tab, where actuals are read against the budget as a tolerance band.
Process walkthrough · 1:59 · /projects/$id, /tutorials
Close a project and give feedback
Stage eight will not complete without feedback. Closing deactivates external users attached only to this project, locks the record, and notifies sales with an explicit note that nothing was written to the CRM.
Process walkthrough · 1:58 · /assignments, /resources, /tutorials
Plan and assign resources
Keep the registers right, then assign resources to projects for a date range and a percentage. Read the week grid for over-allocation before committing. The platform suggests; a person decides.
Page tour · 0:55 · /
The overview
The overview is the day's starting point: what is waiting on you, what is at risk, and where work sits on the spine. Open the record from here rather than working from the counts.
Page tour · 1:01 · /requests
The request register
Every request your team owns, in compact density, with waiting time shown in plain words. Approvals waiting on you are reachable from the same page. Work the oldest first.
Page tour · 0:56 · /requests/new
Raising a request
One screen, one submission. Fields drawn from the CRM are marked and read-only. Describe the problem rather than the solution, then submit the request.
Page tour · 0:48 · /requests/$id
The request assessment workspace
One request, its assessment, its two reviews and its full history. The route review unlocks the resource review, which sets the project lead and the resource.
Page tour · 0:53 · /projects
The project register
Every project, at every stage. Health is derived from schedule, actions and budget, and the reason is shown when you hover it. Saved views hold the filters you use daily.
Page tour · 1:14 · /projects/$id
The project record
One project, eight tabs, one gate rail. The rail is where the stage moves; the tabs hold the evidence. As-seen-by shows exactly what an external contact would see.
Page tour · 0:56 · /resources
The resource registers
People and equipment, each in its own register, with hub and business unit on every row. Bulk import accepts a spreadsheet paste and reports every rejected row. Competency mapping is a later layer.
Page tour · 0:50 · /assignments
Assignment and capacity
Who is working on what, by week, with over-allocation shown against a tolerance band. The platform suggests people; it never assigns them. Assignments are a plan, not a timesheet.
Page tour · 0:51 · /time
Time capture
A weekly grid, one row per project, built for speed. Book hours against the project, not the customer. Rates resolve behind the grid and are never shown here.
Page tour · 1:04 · /actions
The action log
Every action on every project in one list, longest overdue first. Read-only: actions are edited on their project, where the sharing decision is recorded.
Page tour · 0:58 · /documents
The document register
Every project document in one register, opening on internal only, with its project phase. Visibility is data, changed on the document's own project, never in bulk.
Page tour · 0:59 · /tutorials
The tutorial index
Every page tour and process walkthrough in one list, each with a transcript. One narrator throughout. Nothing autoplays.
Page tour · 0:56 · /_notifications
The notification preview
Every Teams card the platform sends, rendered with seeded data, with its audience and cadence shown. Fire any card at any record to see the result.
Scripts live in docs/tutorials. The remaining required tutorials are listed in MANIFEST.md and are written as each screen is built.