Resources • RAMS • PDF packs • sign-off
RAMS in Fire Door App: from scope to PDF pack
A practical guide to producing consistent RAMS (risk assessments and method statements) and issuing a client-ready PDF pack linked to the right work.
- RAMS
- PDF packs
- Versioning
- Sign-off
- Client pack
A repeatable RAM structure that stays linked to jobs, doors,
and outputs
A practical guide to producing consistent risk assessments and method statements — issued as a client-ready PDF pack from the same record as the scope and evidence.
Goal 01
Standard structure
Keep scope, hazards, and controls consistent across jobs — scope summary, hazards matched to the real site method, and sign-off with clear change control. Written for the crew, not the auditor.
Goal 02
Issue from the record
PDF packs should reference the same work and evidence trail — generated from the system record, not assembled manually in a separate tool. Every door ID and scope item in the pack traces back to the same job.
Goal 03
Approve before PDF
Draft first, review, approve — then download the PDF pack. The approval gate keeps unapproved content out of circulation and creates a clear moment when the RAM becomes the operative document for the crew.
Supervisors & project leads
Issue a pack crews can follow on site — scope, controls, and method in one consistent document, issued from the same job record.
Admins & compliance
Keep versioning and sign-off easy to audit later — draft vs approved status tracked, revision history clear, one archive location.
Anyone issuing PDFs
Keep RAMS packs linked to the same scope and outputs — so the PDF the client receives matches the job record and not a separately assembled version.
Create RAMS early enough to guide the work —
late enough that scope is clear
Three fixed points in the workflow. Too early and the scope isn't firm enough; too late and crews arrive on site without the controls they need.
Three points · after scope · before site
Point 01
After scope is agreed
Typically after quote approval or internal sign-off. Scope needs to be firm before writing the method — RAMS drafted before approval risk being immediately outdated when scope is revised.
Point 02
Before scheduling
So crews know what controls are required before they arrive on site. Issuing RAMS the morning of the job doesn't give teams time to prepare, procure PPE, or raise access queries.
Point 03
Before client handover
So RAMS sit inside the same pack as inspection outputs and evidence where needed. Clients who require a complete pack before work starts need RAMS issued alongside the scope and evidence, not after close-out.
Keep RAMS practical and readable
for the people doing the work
Three core sections — each with a specific job. Scope tells crews what and where. Hazards tells them what controls to follow. Sign-off tells everyone what's current.
Three sections · written for the crew
Section 01
Scope summary
Where, what, and what's excluded — plus any assumptions. A crew that doesn't know what's out of scope will improvise; a client who discovers excluded items aren't covered will dispute the invoice. State both clearly on page one.
Section 02
Hazards & controls
Controls that match your real site method — not generic copy-paste from a template library. If the controls don't reflect what the crew will actually do, the RAM is fiction. Write for the specific doors, building type, and access conditions.
Section 03
Sign-off & change control
Who approves, what triggers a revision, and how teams know what's current. Without a clear change control rule, every revision becomes a "which version did you send?" conversation when something goes wrong.
Common mistakes
Three patterns that produce RAMS no one follows
Written for auditors, not crews. Dense legal language that no one reads on site is the same as no RAMS at all. Use plain language at the level of the person doing the work.
Controls not matched to the actual method. Generic "wear PPE" controls copied from a template don't tell crews what PPE, when, or why. Match controls to the real site conditions and tasks.
No versioning. Multiple PDFs floating around with no dates or revision markers means crews can't tell which one is current — and "current" becomes whatever they happen to have saved.
Template · RAMS pack contents (minimum)
Four sections every RAMS pack should include
01
Scope
Scope summary
Site, building, areas covered — plus what is excluded and any assumptions about access or spec.
02
Method
Method summary
The actual site method — not boilerplate. How the work will be done, in what sequence, with what equipment.
03
Controls
Hazards & controls
The specific controls the crew will follow — matched to the hazards present on this site and this type of work.
04
Sign-off
Sign-off & revision
Who approved, the date, and the revision number. One entry per version so old packs can be distinguished from current.
PDF packs are most effective when every document
references the same job
Four rules that keep the pack consistent from the moment it's generated to the moment a crew opens it on site. The approval gate is the most important — it's what separates a working document from a draft.
Four rules · approval gate first
Rule 01
Approval gate
Review as a draft, then approve before downloading the PDF. The approval is the moment the RAM becomes the operative document — everything before that is a draft. Sending a draft as if it's approved removes the only quality gate in the process.
Rule 02
Single source record
Issue from the system so links and door IDs match the scope. A PDF assembled manually from a word processor alongside a separately assembled quote will drift — different door counts, different location names, different assumptions.
Rule 03
Pack expectation
Be explicit with clients on what's included and what's not. A client who expects inspection photos in the RAMS pack and doesn't find them will ask for a resend — or assume the pack is incomplete and withhold approval.
Rule 04
Evidence continuity
Keep before/after proof attached to the right door record. Close-out evidence filed separately from the RAM means the completion pack can't be assembled without hunting across tools at the end of the job.
Template · RAM pack contents (minimum)
What to include in a client-ready PDF pack
01
Scope
Scope summary
Site, building, areas, and exclusions — what the pack covers and what it doesn't.
02
Method
Method summary
The actual site method — not boilerplate. Enough detail for crews to know what they're doing and in what order.
03
Controls
Hazards & controls
Controls matched to the hazards present on this job — site-specific, not copied from a generic library.
04
Sign-off
Sign-off & date
Who approved, the revision number, and the date — so any copy of the pack can be traced to the correct version.
Versioning is an operational habit —
people need one clear "latest version" rule
Three triggers that always produce a new version, a naming convention that makes the current version unambiguous, and four pitfalls that cause pack drift across crews and clients.
Revision triggers
Three changes that always require a new version — not a "quick edit"
Scope change
If doors are added, removed, or deferred, revise the RAMS and re-issue the pack. The scope summary, method, and controls all need to match the actual job. A pack that says 17 doors when 21 will be done is wrong before work starts.
Method change
If the site method changes — different access approach, different sequence, different equipment — treat it as a new version, not a quick edit. The hazards and controls are tied to the method; change the method, change the controls.
Staffing change
Make sure new crews can find the current RAMS easily. A crew working from a saved copy on someone's phone who left the project is a version control problem disguised as a personnel change. One archive location solves this.
Template · revision naming
Good and bad filename patterns
Common pitfalls · pack drift
Distribution
PDFs sent by email and forgotten
Once a PDF is emailed, it exists on the recipient's device with no connection to whether a newer version has been issued. Crews working from an emailed copy six weeks old may be following outdated controls — with no way of knowing.
Fix: store centrally with a clear "current version" marker — so anyone can find the latest pack without asking.
Alignment
Scope and method mismatch
The RAM describes 17 doors; the quote was revised to 21. The method says one access route; the building manager confirmed a different one. Controls written for the wrong scope or method are unusable on site — and potentially dangerous.
Fix: scope and method changes always trigger a revision. Never patch the controls without updating the scope and method sections to match.
Naming
Missing revision markers
A file called "RAMS Pack Block A FINAL" looks identical to a file called "RAMS Pack Block A FINAL v2 (2)". Without a date and revision number in the filename, old packs masquerade as current ones — and no one knows which to follow.
Fix: always include date and revision: "RAMS Pack – Block A – 2026-01-28 – Rev 02". Add a short change note for anything beyond Rev 01.
Content
Generic risk controls
"Wear appropriate PPE" and "be aware of hazards" are not controls. They tell crews nothing specific about what to wear, when, or why. Generic controls get ignored because they couldn't have been written for this job — and the crew knows it.
Fix: write for the specific doors, building, and access conditions. "FFP2 mask when sanding · dust sheet covering flooring" is a control. "Use PPE" is not.
Quick answers on reuse, revisions, pack contents,
and platform scope
Four questions that come up when teams are formalising their RAMS workflow or moving from ad-hoc documents to a consistent, version-controlled process.
Reuse & revisions
Yes — many teams reuse structure and wording as a starting point, and that's fine. Reuse the structure; review the content per job. Scope, hazards, and controls all need to reflect the specific site, doors, and access conditions for each job.
The failure mode is treating reuse as a blind copy — issuing the same RAM for a high-rise residential block that was written for a ground-floor care home. The structure can be identical; the method and controls can't be. Treat reuse as a template, not a finished document.
Treat versioning as an operational habit: record what changed, re-issue the updated PDF pack, and make the "latest" version obvious — date and revision number in the filename, short change note for anything beyond Rev 01. Fire Door App tracks draft vs approved status so the current version is always distinguishable from previous ones.
The discipline is making re-issue feel routine rather than heavy. Every scope, method, or staffing change produces a new version — not a "quick patch" that creates an undated file floating alongside the previous one.
Pack contents & platform
Typically: scope summary (site, building, areas, exclusions), hazards and controls (site-specific, matched to the method), sign-off (approver, date, revision), and any supporting method documents required by your client or site policy.
What's in the pack should be agreed with the client before the first issue — not discovered during approval. "What is and isn't in this pack" is an expectation conversation, not a document design question. Be explicit in the cover note or pack summary.
No. Fire Door App supports workflows and evidence retention — the platform helps you create consistent RAM structures, manage draft vs approved status, and issue PDF packs linked to the right job record. It does not determine what hazards are present, what controls are adequate, or whether a RAM meets any specific legal or client requirement.
Your organisation remains responsible for competent-person decisions and compliance with client and legal requirements. The platform makes those decisions easier to document and version-control — not easier to skip.
Quick facts
RAMS & PDF packs at a glance
Three sections
Scope summary · Hazards & controls · Sign-off + change control
Approval gate
Draft → approve → PDF. The approval is when the RAM becomes the operative document
Revision triggers
Scope change · method change · staffing change — each always produces a new version
Naming
"RAMS Pack – Block A – 2026-01-28 – Rev 01" — date + revision + short change note
Reuse
Reuse structure — review scope, hazards, and controls per job. Template, not finished doc
Platform scope
FDA handles structure, versioning, and PDF output. Competent-person decisions remain yours
Get started
Issue a clean PDF pack from one job record
Keep scope, controls, and outputs joined up so site teams and clients are always looking at the current version.
Issue RAMS packs from one job record.
Draft, approve, then PDF — always the current version.
Keep scope, hazards, controls, and sign-off in one place so crews and clients see the same operative document, with revisions that are easy to trace.