Platform 1 · internal
Tutorials
Every page has a page tour and every process has a walkthrough. One narrator across the programme. Each tutorial ships a transcript, so you can read it instead of listening.
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:18 · /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:09 · /requests/$id, /requests, /tutorials
Assess and qualify a request
Assessment has two tracks, commercial then technical. Record the reasoning as well as the outcome. Qualifying creates a project carrying the request's reference; declining is a recorded outcome, not a deletion.
Process walkthrough · 1:55 · /requests/$id, /requests, /tutorials
Approve as commercial
Commercial approval is a pool decision and comes first: it unlocks the technical track. Approve, decline or return for information — all three are recorded outcomes with a reason.
Process walkthrough · 1:50 · /requests/$id, /requests, /tutorials
Approve as technical
Technical approval answers whether the hub can do the work, with what, and roughly at what effort. It only opens once commercial approval is given, and it feeds the route decision.
Process walkthrough · 1:48 · /projects/$id, /requests/$id, /tutorials
Make the route decision
Stage three sets how the work will run. The platform suggests a route from the assessment; a person decides it and records why. 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 · 2:00 · /assignments, /resources, /tutorials
Plan and assign resources
Keep the registers right, then assign people and equipment to projects for a date range and a percentage. Read the week grid for over-allocation before committing. The platform suggests; a person decides.
Process walkthrough · 2:05 · /projects/$id, /tutorials
Handle a restricted project
A restricted project is fully visible — plan, value, quotations, management detail — and only its technical files are excluded. Uploads are absent rather than disabled, every attempt is audited, and the technical files live on the secure Sandvik servers.
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 · 0:57 · /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:52 · /requests/$id
The request assessment workspace
One request, its two assessment tracks, its approvals and its full history. Commercial approval unlocks the technical track. Every state change is on the history tab.
Page tour · 1:08 · /approvals
The approvals queue
Every approval step waiting on a pool you stand in, longest wait first. Approvals go to pools, not people, and the trail records who acted. Steps waiting more than five days are flagged.
Page tour · 1:00 · /projects
The project register
Every project, at every stage, including restricted ones. 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 · 0:58 · /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:03 · /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:57 · /documents
The document register
Every project document in one register, opening on internal only. 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:54 · /_components
Component gallery
The gallery shows every EPMS component in every state. Review the empty, loading and error states as carefully as the default one — nothing here saves anything.
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. Restricted projects get a minimal card.
Page tour · 0:52 · /_integration
The integration log
Every exchange with the CRM and the data platform: direction, object, reference, outcome, attempts and error. Retries show pending before they show a result. Failures are shown, not hidden.
Scripts and transcripts live in docs/tutorials. The remaining required tutorials are listed in MANIFEST.md and are written as each screen is built.