Resources • client portal • access • handover
Client Portal rollout checklist
A practical rollout checklist for client access: who gets access, what clients can see, how notifications should work, and how to set expectations for handover packs.
- Client Portal
- Access
- Notifications
- Handover
- Billing
Clients see the right evidence, at the right time,
with clear expectations
A practical rollout checklist for client access — who gets access, what clients can see, how notifications should work, and how to set expectations so the portal lands well from day one.
Goal 01
Decide access rules
Named people, roles, and a clear sharing policy — before the first invite goes out. Access rules agreed upfront prevent the "who should be seeing this?" question appearing mid-project when it's harder to fix without awkward conversations.
Goal 02
Publish packs
Reports and outputs from the same underlying door records — not manually assembled and emailed separately. When the portal shows the same data the team is working from, version mismatches and "which PDF is current?" disappear.
Goal 03
Set expectations
What is included, what is not, and when updates land. Clients who understand what the portal is for — and what it isn't — don't chase emails to ask why something isn't there, or use it as a messaging channel it wasn't designed for.
Operations leads
Set access rules and comms expectations before the rollout — who gets access, what they can see, and what the update cadence looks like. Agreed upfront so the team isn't making policy decisions mid-client-call.
Client-facing teams
Give reviewers visibility without emailing PDFs to everyone. The portal replaces the "here's the report attached" email cycle — but only if clients know what to expect and where to look.
Accounts & admin
Keep billing touchpoints controlled if invoicing is enabled — invoices, payment links, and status all visible from the same client view, without separate billing email threads running in parallel.
A clean portal is easier to adopt
than dumping everything at once
Three layers that make up the client view — start with inspections and reports, add remedial progress once the evidence trail is consistent, then enable billing touchpoints only when the process supports it.
Three layers · start lean · add when ready
Layer 01
Inspections & reports
The client-ready output pack, tied to door records — reports issued per visit, with the evidence and findings that the client needs to understand the current state of their doors.
Layer 02
Remedial progress
What is open, what is complete, and the evidence trail — so clients can track progress without emailing to ask for an update. The portal updates as evidence is uploaded, not on a separate schedule.
Layer 03
Quotes & invoices (if enabled)
A single place to view totals, status, and downloads — if billing is enabled in your workspace. Clients can see what is due and what has been paid without a separate billing email thread running in parallel.
Start with layer 1 only. Publish one inspection pack for one client, confirm it lands well, then expand access incrementally — not all three layers to all clients on day one.
Decide what you will email
vs what the portal is expected to show
Three decisions to make before the rollout — then a repeatable rollout email template so clients know exactly what to expect from day one.
Decision 01
Define trigger events
Agree which events generate a notification — not "everything". Notification overload makes clients tune out; too few and they don't know when to look.
→ Inspection report issued
→ Quote sent for approval
→ Remedials complete
→ Invoice issued
Decision 02
Decide recipients
Avoid sending everything to everyone. Agree which named portal users receive which trigger events — the FM lead may need all notifications; other users may only need invoice alerts.
→ FM lead: all events
→ Finance: invoice only
→ Site manager: reports only
Decision 03
Set update cadence
Be explicit: per-event updates or a regular digest. Neither is wrong — but leaving it undefined means clients either expect more updates than you send, or get buried in emails from day one.
→ Per-event: immediate on trigger
→ Weekly digest: Mon 08:00
→ Pick one · be explicit
Template · rollout email copy
One message · sent before the first invite — sets expectations from day one
Subject line
Your fire door inspection reports are now available in the Client Portal
What's new
You can now view inspection reports and remedial progress for your properties in the Fire Door App Client Portal. Reports are issued after each inspection visit; remedial status updates as evidence is uploaded.
What to look for
Reports are issued per visit. You'll receive a notification when a new report is published. Remedial tasks show open/in-progress/complete status with before-and-after evidence attached.
What not to expect
The portal is not a live messaging channel. For queries, questions, or urgent issues please contact your account team by email or phone — not via the portal.
Who gets access
Named users only — we'll send individual invites to the contacts you provide. Please reply with the names and email addresses of anyone who should have access. Shared mailboxes cannot be used for portal accounts.
Response expectations
We reply during Mon–Fri 09:00–17:00. Urgent issues should be flagged by phone. The portal itself is available 24/7 for viewing reports and status.
Access control is a policy decision
as much as a technical one
Three rules that keep portal access auditable and manageable — then four policy decisions to agree before the first invite, so leavers and edge cases don't catch you out mid-rollout.
Three rules · named · permissioned · secured
Rule 01
Named accounts — not shared mailboxes
Prefer individual user accounts over shared inboxes. A shared mailbox means you can't tell who viewed the report, can't revoke access for a single leaver, and can't send targeted notifications to the right person.
Rule 02
Assign permissions by role
Decide who receives invoices and inspections, and who is allowed to manage portal users for the client. Different roles need different access — the site manager and the finance director aren't looking for the same things.
Rule 03
Encourage or require 2FA
Portal users have access to inspection evidence, remedial status, and (if enabled) billing information. Decide whether clients must use 2FA before the rollout — this is a policy decision, not just a technical setting.
Access policy checklist · agree before first invite
Four decisions that prevent access problems mid-rollout
01
Leavers
Who removes access?
Decide who is responsible for revoking portal access when client staff leave — and how quickly. A leaver still seeing reports six months later is an access control failure.
02
Invites
Who can add users?
Decide whether the client can invite their own colleagues to the portal, or whether all invites go through your team. Both are valid — but the rule should be agreed and documented.
03
Minimum roles
View only vs approve
Decide the minimum access level — who can view only, who can approve or raise issues, and whether billing access is always separate from report access.
04
2FA expectation
Required or encouraged?
Whether clients must use 2FA is a policy decision. Decide before the rollout and communicate it in the invite email — not as a surprise after they've already logged in.
Keep handover consistent
same door IDs, same evidence links, clear current status
Three handover pack steps, four rollout pitfalls that catch teams out, and quick answers on the most common portal access and expectations questions.
Handover pack workflow · three steps
What you send, and when — from the same underlying door records
Inspection pack
Report plus key evidence for the visit — the client-ready output tied to the door records from that inspection. Issued per visit, not assembled manually.
Remedials update
Accepted scope, progress, and close-out proof — so the client can see what is open, what is in progress, and what has been completed with evidence attached.
Exports
PDF and CSV outputs from the same underlying record — for audit or handover. Generated from the live door history, not rebuilt from screenshots or assembled in a separate document.
Common pitfalls · four patterns that catch rollouts out
Stakeholders
Too many stakeholders on day one
Rolling out to every client contact simultaneously means different expectations land with different people at once — and every misunderstanding creates a support conversation. Problems compound when there's no baseline to fix from.
Fix: start with a small pilot group — one client, two named users — and expand once you've confirmed expectations land correctly.
Official record
Unclear "what's official"
If you don't define whether the portal replaces PDFs or complements them, clients will ask — usually after receiving both and finding they don't match. "Portal is the live view; PDFs are the issued record" needs to be stated once, clearly.
Fix: include a one-line definition in the rollout email: "The portal is the live view; issued PDF reports are the formal output."
Mailboxes
Shared mailboxes
Shared mailboxes mean you can't tell who viewed what, can't remove one person's access when they leave, and can't enforce 2FA per user. When the client changes staff, you're left revoking an entire mailbox rather than one account.
Fix: require named individual accounts before sending invites. State this in the rollout email and don't issue access to shared inboxes.
Link forwarding
Link forwarding
Assume links can and will be forwarded. If access isn't controlled at the account level, a forwarded invite or report link can give unintended access to people outside the named list — which is why named accounts matter from the start.
Fix: use named account invites rather than open links. Communicate in the rollout email that access is account-based and links should not be forwarded.
Common questions · quick answers
Portal access is managed by your organisation. You decide whether the client can invite their own colleagues or whether all invites come through your team — the rule should be agreed and documented before the first invite goes out, not decided reactively when a client asks.
Either approach works. The important thing is keeping access tied to named individuals rather than shared inboxes, so leavers processes remain clean.
Use a clear policy: which properties or projects are shared, what outputs are published (reports only vs reports and remedials vs billing as well), and which named client users have access to each layer.
The practical approach: start by publishing only what you'd currently send by email anyway. The portal doesn't change what you share — it just replaces the email attachment.
Start with one building and one client: publish one inspection pack and one remedial update, then confirm expectations before expanding. A controlled pilot surfaces any issues — mismatched expectations, unclear "what's official", access questions — before they affect every client simultaneously.
Once the first client is comfortable and the process is smooth, rolling out to additional clients is fast because the template is already set.
No. The portal supports evidence sharing and workflow visibility — it makes it easier for clients and dutyholders to access the records that support compliance decisions. But compliance obligations and decisions remain with the relevant dutyholders and competent persons.
If clients ask whether the portal means they're compliant, the honest answer is: the portal makes evidence accessible and traceable, but compliance is determined by the quality and completeness of the underlying inspections and remedials — not by the tool used to share them.
Quick facts
Portal rollout at a glance
Access
Named accounts only · no shared mailboxes · policy agreed first
Layers
Inspections first · add remedials · then billing if enabled
Handover pack
Inspection pack · remedials update · exports — all from live record
2FA
Policy decision · required or encouraged · set before first invite
Rollout approach
Pilot one client first · confirm expectations · then scale
Get started
Roll it out on one client first
Publish one inspection pack, one remedials update, and confirm expectations before scaling to all clients.
Roll it out on one client first.
One inspection pack, one remedials update, clear expectations.
Publish one inspection pack, one remedials update, and confirm expectations before scaling to all clients.