Book a demo Start free trial

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.

Start 7‑day free trial See quotes, RAMS & builder

7‑day trial. No card required. Cancel anytime.

  • RAMs
  • PDF packs
  • Versioning
  • Sign-off

Last updated:

Jump to: When to create What to include Issuing PDFs Versioning Related
RAMs builder
Fire Door App RAMs builder screen for creating a method statement pack. Click to enlarge

Guide summary

The goal: a repeatable RAM structure that stays linked to jobs, doors, and outputs.

Standard structure Keep scope, hazards, and controls consistent across jobs.
Issue from the record PDF packs should reference the same work and evidence trail.
Approve before PDF Draft first, approve, then download the PDF pack.

Who this is for (and when to use it)

Use this when you need a repeatable RAMs pack that stays aligned to scope, site method, and sign-off.

  • Supervisors and project leads: issue a pack crews can follow on site.
  • Admins/compliance teams: keep versioning and sign-off easy to audit later.
  • Anyone issuing PDFs: keep RAMs packs linked to the same scope and outputs.

When to create RAMs in the workflow

RAMs are most useful when they’re created early enough to guide site work, but late enough that scope is clear.

  • After scope is agreed: typically after quote approval or internal sign-off.
  • Before scheduling: so crews know what controls are required.
  • Before client handover: so RAMs sit inside the same pack as outputs and evidence where needed.

What to include (scope, hazards, controls, sign-off)

Keep RAMs practical and readable for the people doing the work.

Section

Scope summary

Where, what, and what’s excluded — plus any assumptions.

Section

Hazards & controls

Controls that match your real site method (not generic copy).

Section

Sign-off + change control

Who approves, what triggers a revision, and how teams know what’s current.

Common mistakes
  • RAMs written for “auditors” instead of the site crew.
  • Controls not matched to the actual site method.
  • No versioning — multiple PDFs floating around.

Issuing PDFs (and keeping the pack consistent)

PDF packs are most effective when every document references the same job and the same door-level scope.

  • Approval gate: review RAMs as a draft, then approve before downloading the PDF.
  • Single source record: issue from the system so links and door IDs match.
  • Pack expectation: be explicit with clients on what’s included and what’s not.
  • Evidence continuity: keep before/after proof attached to the right door record.
Template: RAM pack contents (minimum)
  • Scope summary: site/building/areas, plus exclusions.
  • Method summary: the actual site method (not generic boilerplate).
  • Hazards & controls: the controls the crew will follow.
  • Sign-off: who approved, and revision/date.

Version control expectations

Versioning is an operational habit: people need a clear “latest version” rule.

  1. When you change scope: revise RAMs and re-issue the pack.
  2. When the method changes: treat it as a new version, not a “quick edit”.
  3. When staffing changes: make sure new crews can find the current RAMs easily.
Template: revision naming
  • Include date: e.g. “RAMs Pack – Block A – 2026‑01‑20”.
  • Include revision: e.g. “Rev 01 / Rev 02” with a short change note.
  • Single archive location: one place everyone uses to find “current”.

Common pitfalls (pack drift)

The RAMs pack only helps if the crew and the client are both looking at the same “current” version.

  • PDFs sent by email and forgotten: store centrally so the current version is obvious.
  • Scope and method mismatch: keep RAMs aligned to the actual job scope and door list.
  • Missing revision markers: add dates/revisions so old packs can’t masquerade as current.
  • Generic risk controls: write for the actual site method, not for a template library.

Common questions

Quick answers on RAM structure, reuse, and revisions.

Can we reuse RAMs?

Yes, many teams reuse structure and wording, but you should review scope, hazards, and controls per job. Treat reuse as a starting point, not a blind copy.

How do we handle revisions?

Treat versioning as a habit: record what changed, re-issue the updated PDF pack, and make the “latest” version obvious (date/revision in the filename). Fire Door App tracks draft vs approved RAMs.

What should a “RAMs PDF pack” include?

Typically: scope summary, hazards/controls, sign-off, and any supporting method documents required by your client or site policy.

Does Fire Door App provide legal compliance?

No. Fire Door App supports workflows and evidence retention; your organisation remains responsible for competent-person decisions and compliance with client and legal requirements.

Related guides

Keep documents and evidence joined up across the job lifecycle.

Audit trail checklist

Identity, evidence, sign-off, and exports that stay linked to doors.

Read the guide →

Reports & exports

What to send to clients or auditors, and when to use PDF vs CSV.

Read the guide →

How to use the app

End-to-end workflows across inspections, remedials, documents, and client access.

Read the guide →

Next step

Issue a clean PDF pack from one job record.

Keep scope, controls, and outputs joined up — so site teams and clients know what is current.

7‑day trial. No card required. Cancel anytime.

Start 7‑day free trial More resources