Why a written policy matters more when you hire directly
When someone joins a company with an office, most working rules arrive by osmosis. They see when colleagues start, how fast people answer messages, what gets escalated and what gets quietly handled. A remote hire gets none of that ambient information, and a remote hire working for a small business or a single founder gets even less, because there is no HR handbook, no employee portal, and often no second employee to copy. Everything either gets written down or gets guessed at, and guessed-at expectations are where good working relationships go to die.
The pattern is familiar to anyone who has hired remotely without a policy. Nothing goes visibly wrong for weeks. Then a message sits unanswered for an afternoon and you wonder if that is normal; a public holiday you did not know about arrives unannounced; you discover the client files live in a personal Google account. None of these is a crisis, and none of them is really the assistant's fault, because nobody ever said what the rule was. Each one costs a small awkward conversation that a single page of writing would have prevented.
When you hire through an agency, the agency's processes paper over some of this. When you hire directly, with no middleman, writing the rules is your job, and it is genuinely a small job: the policy this tool produces fits on a page or two and takes about ten minutes to customise. The return on those ten minutes is a working relationship where both sides know what good looks like, disagreements are about the written rule rather than about memory, and your assistant never has to choose between interrupting you and guessing.
What a good remote work policy actually covers
The heart of the document is hours and availability, because more remote friction traces back to mismatched availability expectations than to any other cause. State the working hours, name the time zone, and if your zones differ, say exactly which hours must overlap with yours. Then set the response expectation explicitly. A first response within an hour or two during working hours is a reasonable ask for most assistant roles; what matters is that the number is written down, and that both sides understand a first response can be a quick acknowledgment rather than a finished answer. Silence, not slowness, is what erodes trust across a distance.
Communication comes next: which channel is for what, and what regular written updates look like. The daily end-of-day note is the single highest-value habit in remote work, three lines covering what was finished, what is in progress, and what is blocked. It replaces the visibility an office gives for free, and it surfaces problems while they are still cheap. A policy that establishes the update habit from day one spares you from ever having to ask the question that no manager enjoys asking, which is what did you actually do this week.
Then come the sections that feel bureaucratic right up until the day they matter: security, equipment, time tracking, and leave. Security does not need to be elaborate, it needs to be habitual: passwords through a password manager, two-factor authentication on, work kept in company accounts. Equipment and workspace expectations make reliability explicit, including backup internet and power. Time tracking states how hours are recorded so pay conversations stay boring. And the leave section quietly prevents the most common surprise in cross-border work: nobody agreeing in advance whose public holidays apply.
Setting hours across a time zone gap
Time zones are where remote work policies most often stay vague, and vagueness helps nobody. If your assistant is in South Africa, the arithmetic is friendlier than most employers expect. The country runs on South African Standard Time, UTC+2, and does not observe daylight saving, so whatever overlap you agree in January still holds in July. For UK employers the gap is one or two hours depending on British Summer Time; for most of Europe it is zero or one. A South African assistant working ordinary local business hours is effectively a same-day colleague for the whole European working day.
For North American employers the honest answer is partial overlap, and the policy is where you make that overlap dependable. New York is six or seven hours behind SAST depending on the season, so the South African afternoon meets the East Coast morning. A practical pattern is to fix a window rather than a full mirrored day: require, say, three or four hours of overlap with your morning, and let your assistant work the rest of their hours on their own schedule. You get real-time collaboration when you need it, plus the quiet superpower of asynchronous work: tasks handed over at your end of day are finished before you wake. Check your own city's numbers with the time zone overlap calculator.
Whatever you choose, write both halves down: the hours and the flexibility. A policy that says only 9 to 5 invites silent drift; a policy that says which hours are fixed, which are flexible, and how schedule changes are agreed gives your assistant room to live their life without leaving you guessing. Pair it with the holidays decision, using the South Africa public holiday planner to see exactly which dates a South African calendar involves, and the two most common time-related surprises in cross-border hiring both disappear.
Security and workspace rules that respect everyone
Employers sometimes hesitate to put security rules in writing because it feels like an accusation. It is the opposite. A written security section protects your assistant as much as it protects you: when credentials live in a password manager and work lives in company accounts, no one can later wonder whether something went missing on their watch. The essentials are short. Shared passwords go through a password manager, never through chat. Two-factor authentication is on wherever it exists. Work products live in accounts the company controls, so continuity survives any change in the relationship. Devices lock when unattended. Client information is confidential, full stop.
Workspace expectations deserve the same plain treatment. For any remote role, the connection is the commute, and it is fair to ask for a reliable primary connection plus a backup, usually a mobile hotspot. In South Africa there is a local specific worth understanding rather than fearing: scheduled power cuts, known locally as load-shedding, have been a recurring feature of the grid for years, and the professional remote workforce has adapted accordingly. Experienced South African assistants routinely maintain a UPS or inverter and a mobile data backup precisely so an outage does not touch client work. Asking about the setup is normal; a candidate with a confident answer is showing you professionalism, not overhead.
Notice what belongs in this section and what does not. Rules about how work is protected belong here. Surveillance does not: screenshot monitors and keystroke loggers signal distrust at the exact moment you are trying to build the opposite, and they measure activity rather than output. The policy this tool generates leans deliberately toward output and visibility, the daily update, the tracked hours, the quality of the work, because that is what actually tells you whether a remote engagement is succeeding.
Policy, contract, or SOP? Where each rule belongs
Three documents govern a well-run remote engagement, and confusion between them is why many teams have none of the three. The contract is the legal layer: pay, scope, confidentiality, intellectual property, termination notice. It changes rarely, and changing it properly requires both signatures. If you have not written that layer yet, the contract generator builds a plain-language agreement, and the offer letter generator covers the warmer document that precedes it.
The remote work policy is the operating layer: how the working day runs. Hours, channels, updates, security habits, leave logistics. It should be easy to update, because how you work changes as trust grows; a response-time rule that made sense in month one often relaxes by month six, and the policy should follow reality rather than fossilise. And standard operating procedures are the task layer: step-by-step instructions for individual processes, built with the SOP generator. The policy says update me daily; the SOP says how to publish the newsletter.
The rule of thumb: if breaking it should have legal consequences, it belongs in the contract; if it describes how you collaborate, it belongs in the policy; if it describes how a task is done, it belongs in an SOP. Keep the layers consistent, and when they overlap, the contract wins. Teams that hold all three documents spend their meetings on the work itself, which is the entire point of writing things down.
Rolling it out and keeping it alive
A policy shared as a link with no conversation is a policy nobody read. The better rollout costs fifteen minutes: walk through the document together during onboarding, invite pushback, and adjust anything that does not survive contact with reality. An assistant who helped shape the overlap window will defend it; an assistant who received it as an edict will quietly resent it. This is also the moment the acknowledgment block earns its place, not as legal theatre but as a shared marker that both sides have actually engaged with the rules. Slot the walkthrough into week one of the onboarding plan.
Then let the policy breathe. Reread it at each performance review, which the performance review generator will prompt you to schedule anyway, and ask one question: does this page still describe how we actually work? Update what has drifted, date the new version, and share it. A policy that evolves with the relationship keeps its authority; a policy frozen in month one becomes a document everyone politely ignores, which is worse than no policy at all because it teaches that the written rules are not the real ones.
And if the engagement ever ends, the policy pays one final dividend: the security section you wrote on day one, company accounts, password manager, two-factor authentication, is exactly what makes a clean handover possible. The offboarding checklist generator closes that loop. Good endings are built at the beginning, in writing.
Remote work policy FAQs
What should a remote work policy include?
A useful remote work policy covers seven things: working hours and the overlap you need with your own day; how quickly messages get a first response; which communication channels are used for what, and what written updates look like; security basics such as password managers, two-factor authentication, and keeping work in company accounts; equipment and workspace expectations, including backup internet and power; how hours are tracked and reported; and how planned leave, public holidays, and sick days are handled. The generator on this page builds exactly that structure, with every section editable and optional sections you can toggle off.
Do I really need a remote work policy for one virtual assistant?
Yes, and the smaller the team, the more the written version earns its keep. With one assistant there is no company culture to absorb expectations from: everything either gets written down or gets discovered through friction. A one-page policy answers the questions that otherwise surface as awkward moments in week three, such as when leave should be requested, which holidays apply, and whether a quiet afternoon message deserves an instant reply. It takes ten minutes to produce with this tool and saves the same conversation from happening five times.
What is the difference between a remote work policy and a contract?
The contract is the binding legal agreement: pay, scope, confidentiality, intellectual property, notice. The remote work policy is the operating manual for the working relationship: hours, channels, updates, security habits, leave logistics. Contracts change rarely and with signatures; a policy is a living document you can update when how you work changes. Keep the two consistent, and when they overlap, the contract wins. If you have not put the binding terms in writing yet, use the virtual assistant contract generator alongside this tool.
How should I set working hours for a South African virtual assistant?
Start from the time zone reality: South Africa runs on SAST, UTC+2, with no daylight saving time, so the gap with your city is stable all year. UK and European employers share most or all of the working day, so standard South African business hours usually work as they are. US East Coast employers overlap with the South African afternoon, so a common pattern is to require a fixed overlap window, for example three or four hours with your morning, and let the rest of the schedule flex. Write the agreed hours and the overlap into the policy so both sides can plan around them.
Is this remote work policy generator free, and is anything stored?
Completely free, no signup, no watermark, and nothing you type is stored or sent anywhere; the whole tool runs in your browser. Fill in your company details, set hours and response expectations, toggle the sections you want, and copy the finished policy into your own document. Edit it however you like: it is a starting point that gets the structure right, not a form you must follow.
Why does the policy mention backup power and internet?
Because for remote work anywhere, connectivity is the workspace, and a policy that ignores it is incomplete. In South Africa specifically, scheduled power cuts known as load-shedding have made backup power a normal part of a professional remote setup: many experienced remote workers keep a UPS or inverter and a mobile hotspot precisely so an outage does not interrupt client work. Asking about backup arrangements is a standard, reasonable expectation to set in writing, and candidates with a solid setup are usually glad to be asked, because it lets them demonstrate professionalism.