How to write a network-wide WhatsApp operating policy: branch rules, exceptions and evidence
A practical WhatsApp policy template for branch networks, covering local rules, media, visibility, escalation, approved exceptions and implementation evidence.
Write one approved network baseline, attach branch-specific hours and access schedules, and connect every requirement to an owner, a test and an approval. Permit local variation only where the baseline allows it; record any other departure as a time-limited policy exception. This turns a WhatsApp operating policy into something branches can apply and the network can review.
The templates below are policy-design tools, not a catalogue of Jely settings. Some rules need staff procedures or another approved channel; others may be technically enforceable in the chosen setup. Verify that distinction before relying on a control.
The franchise and branch networks guide explains local execution with central standards. This guide addresses the next question: how to write those standards, approve deviations and prove each requirement has been implemented.
Define the scope and decision owners
State which legal entities, franchisees, branches, channels, participants and workflows the policy covers. Identify exclusions and where formal outcomes belong. Connecting a conversation does not automatically justify sharing it across separate entities. Obtain the organisation's own legal, privacy and compliance advice where relevant to access, retention, franchise arrangements and local requirements.
Name a policy owner who maintains the document, an authorised approver who accepts the policy, branch owners who apply it, and specialists who review sensitive decisions. Record the version, effective date, review date and approval reference. Access to a tool is not authority to change policy.
WhatsApp and Jely are communication and coordination tools, not the authoritative system of record. Identify the approved case, job, incident or other business record separately. Message receipt is not proof that someone owns an action or that it is resolved.
Separate network requirements from permitted variations
Give each rule a stable identifier. Write the minimum requirement, the allowed local choice and who approves that choice. A permitted variation stays inside the baseline; a departure requires the exception process. The following starting points must be adapted and approved, not adopted as universal rules.
| Requirement | Mandatory network baseline | Permitted branch variation |
|---|---|---|
| R-OWN: ownership | Every active workflow has an accountable owner and backup. | Local role names and cover rota, recorded in the annex. |
| R-HRS: availability | Publish monitored hours and the destination of waiting work. | Local schedules and holidays, with approved cover arrangements. |
| R-MED: media | Classify permitted, restricted and prohibited content; define handling. | Stricter local restrictions or an approved alternative channel. |
| R-VIS: visibility | Access follows an approved task, role and branch scope. | Named local users inside the approved permission boundary. |
| R-ESC: escalation | Define acknowledgement, fallback and outcome-record ownership. | Local contacts and organisation-approved response intervals. |
| R-REC: records | Required formal outcomes enter the approved system. | Local record destination where authorised by the organisation. |
Add the rule owner, approver and evidence reference to each completed requirement. Do not let a local spreadsheet silently replace the approved baseline.
Attach a branch-hours and coverage annex
Office hours are a service boundary, not a promise of continuous monitoring. Maintain one annex entry per branch and workflow, including differences between routine and on-call channels.
| Field | What to record |
|---|---|
| Branch and channel | Branch identifier, approved conversation purpose and covered participants. |
| Schedule and time zone | Monitored days, opening and closing times, time zone and seasonal changes. |
| Holiday or closure | Temporary schedule, effective period and person approving the change. |
| Waiting-work destination | Named next-window owner or staffed cover route; never an unspecified queue. |
| Primary and backup | Responsible roles, contact route and acknowledgement arrangements. |
| Participant wording | Actual monitored hours, expected next step and separate urgent-contact instructions. |
| Change ownership | Who updates the schedule, participant wording and relevant configuration, then verifies them. |
Test a message arriving just before closure, during a holiday and across branch cover. The participant-facing wording must match the staffed arrangement. Where relevant, the home-care out-of-hours guide illustrates acknowledged handovers; its care-specific procedures are not universal network rules.
Distinguish media policy from technical enforcement
A statement that staff should not send something is not evidence that the system blocks it. Classify content as well as file type: an ordinary image can contain personal information, while a document may be suitable for an approved workflow.
| Content | Organisational rule | Technical control to verify | If received unexpectedly |
|---|---|---|---|
| Routine job photo | Permit only necessary, approved operational evidence. | Check actual access and attachment behaviour; do not assume filtering. | Check destination and minimise onward sharing. |
| Identity or sensitive document | Use the designated secure record/channel where policy requires. | Verify available restrictions or use an alternative channel. | Limit access and follow the approved information-handling process. |
| Voice note or video | Allow only where purpose, review and record transfer are defined. | Test supported formats and review access; summaries may miss context. | Assign a trained reviewer and record material outcomes. |
| Restricted material | Do not request or redistribute through this workflow. | Verify any claimed blocking; a written rule alone is not a block. | Use the named incident/escalation route; avoid informal forwarding. |
Do not assume file filters, download restrictions, export controls or deletion of recipient copies are available. If a necessary restriction cannot be enforced, change the workflow, access boundary or channel. Document manual procedures honestly; do not label them technically enforced.
Specify visibility by role and information type
Head office may need exception summaries without routine access to every transcript. Treat full conversations, attachments and exports as separate decisions. Summaries can still contain sensitive information and need their own scope.
| Role | Summary | Full conversation | Attachments | Export |
|---|---|---|---|---|
| Branch owner / backup | Assigned branch workflow | Assigned conversations | Necessary approved content | Only separately authorised |
| Regional coordinator | Approved exception scope | Approved task only | Approved task only | Not by default |
| Network reporting team | Approved minimised reporting | Not by default | Not by default | Approved reporting dataset only |
| Authorised reviewer | Defined review scope | Approved review scope | Necessary review evidence | Separate purpose and approval |
| Technical administrator | No routine business access assumed | Only approved support need | Only approved support need | No routine export authority assumed |
This is an example policy, not verified product permission settings. Record who grants, reviews and removes each entitlement. Test with representative accounts: if summary-only access cannot be separated from full access, the intended boundary has not been proved. Choose another arrangement rather than relying on a role label.
Specify export purpose, destination, authorised recipient and retention arrangements separately. Transcripts can support review, but they are not guaranteed compliance or an immutable archive. Approved formal records remain authoritative.
Write escalation ownership, not just notification rules
Define T-ack as the organisation-approved acknowledgement interval and T-fallback as its fallback trigger for that workflow. Set them according to risk, staffed availability and approved procedures; there is no universal service level in this template.
| Trigger | Primary accountable role | Acknowledgement and fallback | Required outcome |
|---|---|---|---|
| Routine action unacknowledged | Branch workflow owner | Accept ownership within approved T-ack; alert named backup at T-fallback. | Record next action, owner and participant response. |
| Restricted content received | Designated information-handling lead | Use the approved incident route and its own timing; obtain acknowledgement. | Record decision and handling in the approved incident system. |
| Cross-branch ownership dispute | Named regional decision owner | Acknowledge the transfer; retain current ownership until accepted. | Record accepted owner and update affected teams. |
| Welfare or urgent concern | Relevant authorised lead or staffed urgent route | Follow established urgent procedures, not an ordinary queued-message timer. | Record escalation, decision and outcome in the appropriate formal record. |
Delivery, read receipts and automated alerts do not establish accepted ownership. Define what happens if both named roles are unavailable. Publish the separate emergency route; do not present WhatsApp as an emergency service.
Approve, expire and revoke policy exceptions
An operational exception is unresolved work. A policy exception is permission to depart from an approved rule. Keep them distinct. A branch cannot approve its own departure merely because a workaround is convenient.
| Field | Required entry |
|---|---|
| Identifier and rule | Exception ID, affected requirement and policy version. |
| Scope | Branch, workflow, people, information and exact departure permitted. |
| Reason | Why the baseline cannot currently be followed; alternatives considered. |
| Risk review | Relevant privacy, operational and governance risks; specialist advice where needed. |
| Compensating controls | Interim safeguards, responsible owner and verification method. |
| Approver | Authorised decision-maker, decision date and approval reference. |
| Expiry and review | End date or event, review owner and renewal decision; no automatic extension. |
| Revocation | Conditions for early withdrawal, who stops the exception and how access/work is transferred. |
An exception does not waive applicable obligations. Seek the organisation's own advice where relevant. On expiry, restore the baseline or obtain a new reviewed decision; remove temporary access and record completion.
Build evidence for each requirement
Use one evidence entry per requirement and branch, with an identified policy version. A connected number, a training attendance list or a successful test message does not establish that all controls work.
| State | What it demonstrates |
|---|---|
| Documented | The approved rule, local choice, owner and acceptance criteria are written. |
| Configured | Relevant available settings or manual arrangements have been applied and recorded. |
| Tested | A defined scenario produced a recorded actual result against the expected result, including failures. |
| Approved | The authorised reviewer accepted the evidence and resolved or explicitly governed outstanding issues. |
For a procedural rule, identify the manual arrangement instead of inventing a software setting. Mark inapplicable technical steps with a reason; do not call a control configured simply because the policy describes it.
| Field | Evidence to retain in an approved location |
|---|---|
| Identity | Requirement ID, branch, workflow, policy version and accountable owner. |
| Documented / configured | Rule reference, approved local variation, actual configuration or manual procedure, and dated evidence reference. |
| Expected / actual | Test scenario, expected result, actual result, tester and test date. |
| Evidence and limitations | Minimised supporting evidence, authorised access, failure conditions and untested assumptions. |
| Outstanding work | Issue, responsible owner, next action and approved review date. |
| Approval | Separate status for each state, reviewer, decision, date and any approved exception reference. |
Test after-hours routing, restricted media handling, unauthorised visibility, missing acknowledgements and exception expiry. Use fictional or appropriately approved test data and avoid unnecessary transcript copies. Failed controls stay visible in the register. The multi-branch home-care rollout guide shows how readiness gates can sequence expansion; this evidence pack supplies the requirement-level proof behind those decisions.
Control versions and review triggers
Keep one approved master policy with a change log, effective date and named approver. Link each branch annex, exception and evidence entry to its version. Distinguish editorial clarification from a changed requirement that needs branch action and retesting.
Review when staffing, hours, branch ownership, access, channels, media handling, record destinations or relevant advice changes, and after incidents or failed tests. Identify affected branches, withdraw superseded instructions and obtain acknowledgement of the new responsibilities. Keep superseded policy and approval references under the organisation's own retention rules.
A fictional two-branch example
The following branches, hours and identifiers are entirely fictional. They demonstrate how to complete the templates, not a customer deployment, measured outcome or verified product configuration.
| Decision | Harbour | Meadow |
|---|---|---|
| Monitored hours | Weekdays 08:30–16:30, Europe/London. | Weekdays 10:00–18:00, Europe/London. |
| Outside hours | Named next-window branch owner; no routine overnight monitoring. | Named next-window branch owner; no routine overnight monitoring. |
| Media variation | Approved non-personal job photos only in the specified workflow. | Stricter local rule: request documents through the approved alternative channel. |
| Central visibility | Minimised exception summaries; full context only by approved task. | Same baseline; temporary cover access requires a separate decision. |
Meadow requests exception E-01 during its owner's leave. Its scope is a named regional coordinator reviewing Meadow's operational queue, not unrestricted network transcript access. The reason is absence cover; the risk review considers unnecessary disclosure. Proposed compensating controls are a scoped access list and a named reviewer. The authorised approver must decide before access is granted.
E-01 expires when the approved cover period ends and is revoked earlier if the purpose ends or the approved scope cannot be maintained. The backup owns open work after revocation. The register records the decision, removal check and any required formal-record update.
For R-HRS, each branch would test a message outside its own schedule and verify the destination and participant wording. For R-VIS, a representative regional account would be tested against the approved scope. Record expected and actual results separately. At the start of this example, the rules are documented; configuration, tests and approval remain pending. If wider access is exposed, the visibility test fails: revise the arrangement rather than treating the policy statement as proof.
This is the useful distinction: the baseline stays consistent, the hours and stricter media rule are permitted variations, and temporary cover is a separately governed exception.
Make the policy usable, then prove it
A network policy should let a branch identify its rule, owner, permitted variation, exception and evidence without reconstructing decisions from chat. Review requirements rather than message volume, and keep unresolved controls visible until an authorised decision is made.
Jely can help service teams coordinate WhatsApp conversations with shared visibility, routing and oversight while participants use familiar tools. Those capabilities can support an approved operating model; they do not replace the organisation's policy decisions, legal or compliance advice, safeguarding judgement or authoritative records.
Book a demo