Guides
Part of How employee guidelines earn trust when three sentences carry most of the weight
Employee guidelines examples: nine scenarios told with the reason attached, not just rules
Employee guidelines examples: nine scenarios written the way a guidelines document should carry them, with the answer, the reason, and where each one gets hard.
A guidelines document made of principles teaches nothing. The same document made of scenarios is read, remembered, and argued with, which is the whole point.
These are nine scenarios in the form to aim for. Adapt the answers to your own organization: the answers below are illustrative, and the ones that touch employment or data obligations differ by jurisdiction and need local review.
What to take away
- Write the scenario, the answer, and the reason. The reason is what generalizes to the case you did not write down.
- Include at least three where the answer is that it depends, with what it depends on.
- The scenarios people actually need are boringa repost, a recruitment message, an angry customer.
Nine scenarios
A customer complains publicly and tags the company. Answer: do not reply as an individual, even to correct something obviously wrong. Route it to whoever owns the account. Reason: a personal reply becomes the organization's position in every screenshot afterwards, and the person replying carries a dispute they cannot resolve.
Nine scenarios: answer and reason
Customer complains publicly: route it, do not reply
Public technical question: general info only
Posting about a project: only after public
Someone asks you a technical question about your product in a public forum. Answer: general and public information, yes. Anything about roadmap, incidents, internal reasoning or another customer, no. Reason: helpfulness is the intent and the failure mode is disclosure by increment, where three harmless answers combine into one that is not.
You want to post about a project you worked on. Answer: only after it is public, and only the part that is public. Reason: announcement timing is usually somebody's job and frequently involves parties outside the organization.
A recruiter contacts you and you want to say the team is hiring. Answer: link to the posting, say you work there. Reason: the disclosure is what keeps a recommendation from reading as manufactured, and the posting is the version that is accurate.
A colleague posts something you think is a mistake. Answer: tell them privately, and tell whoever owns the account if it is an organization one. Reason: a public correction between colleagues is worse than the original in almost every case.
Something has gone wrong and people are asking. Answer: say nothing, including that you cannot say anything about specifics. Point at the official channel if there is one. Reason: during an incident the facts change hourly, and an early individual account becomes the version people cite.
You disagree with a decision at work. Answer: it depends. Internally, use the route that exists. Publicly, this is where it turns on your contract and on the law where you are employed, and those differ enough that the guidelines should point at a person rather than give an answer. Reason: some categories of speech about working conditions carry protections in some places and not others, and a document that flatly prohibits it may be describing something it cannot enforce.
A journalist messages you. Answer: do not respond substantively, and pass it to whoever handles that. This should be a route, not a prohibition. Reason: a polite redirection takes ten seconds and an off-the-cuff answer takes months to unwind.
You are posting from a personal account that names your employer. Answer: it depends on what you are posting, and the connection is visible whether or not you intend it. A short line saying views are your own helps and does not settle anything. Reason: readers attribute anyway, and the guidance that actually works is about content rather than disclaimers.
What makes a scenario usable
| Property | Why |
|---|---|
| It is one someone has actually faced | Invented edge cases teach the wrong instincts |
| It has a stated answer | "Use judgment" means the drafter could not decide |
| It has a reason | The reason is what covers the next, different case |
| It names the route | An answer with no route is a prohibition |
| It admits uncertainty where it exists | A document that is certain about everything is not believed about anything |
The third and fifth rows are the ones organizations skip. A document without reasons produces employees who follow it literally and stop at the first case it does not cover. A document that pretends everything is settled loses credibility at the first genuinely hard question.
What makes a scenario usable
- Someone has actually faced it
- It has a stated answer
- It has a reason
- It names the route
- It admits uncertainty where it exists
Where these get hard
Three areas need local input rather than a general answer.
Where local input is needed
Area
- Speech about pay, safety, treatment
- Varies by system
- Monitoring and personal data
- Notice-dependent
- Personal accounts
- Boundary is jurisdiction-specific
Why it is local
- Speech about pay, safety, treatment
- Counsel question
- Monitoring and personal data
- Varies by jurisdiction
- Personal accounts
- Most local question
Speech about pay, safety, or treatment at work varies by system. One country's labor and employment bodies publish extensive material on what employers may and may not do in response to workers raising concerns.
That includes guidance on retaliation and related issues and, on safety, an account of employer responsibilities. Those describe one system, and what applies where you employ people is a question for counsel there.
Monitoring and personal data. What an employer may collect about employee activity, and what it must tell them, varies and is frequently notice-dependent.
Personal accounts. Where the boundary of the employment relationship sits, outside work, is one of the most jurisdiction-specific questions in this area. The general drafting problems it creates are covered in what goes wrong with workplace rules.
Turning scenarios into a document
Nine is plenty. A guidelines document with forty scenarios is a reference nobody reads; one with nine is something a new starter can get through in ten minutes, which is the only reading that reliably happens.
Turning scenarios into a document
- Keep nine scenarios, not forty
- Group by moment, not topic
- Separate governance questions
- Link to related policy documents
Group them by the moment, not by topic: about to post, someone contacted me, something went wrong. People look things up by situation, not category.
A scenario about material posted in a space you run is a different problem, closer to deciding what is permitted in a community you moderate. The rest of the document, and why it is not a policy, is set out in guidelines and what they are for.
When accounts belong to the organization, not a person, ownership, handover and access are separate questions. A guidelines document should not answer them.
Those belong in a governance document. What the underlying agreement permits appears in the terms the service holds you to.
Common questions
Should the scenarios be in the same document as the rules?
Yes, and preferably before them. People read the first two pages, and scenarios in the first two pages get read while a definitions section does not.
How often should these be refreshed?
When a new one happens. Add the real case, de-identified, rather than waiting for an annual review. A document that visibly reflects things that happened here is read differently from one that does not.
Who should write them?
Someone who does the job being described, with review by whoever owns the risk. Scenarios written only by a legal or communications function are consistently about the wrong situations.
What if a scenario's honest answer is that we do not know?
Write that, with who to ask. An honest gap sends people to a person. A confident wrong answer sends them nowhere.
