The writing is worth more than the document
Most sole administrators I know have never taken two consecutive weeks off without a laptop in the bag. They book the days, answer the message from the airport, and call that a holiday. The fix starts with a document nobody enjoys writing, and the document is the smaller half of what you get.
A handover runbook describes how your platform keeps running for a fixed period without you. Two weeks is the right length to plan for, because one week hides everything monthly. Write it for a real named person who has agreed to cover, not for a hypothetical competent stranger. The same instinct that makes you write code other people can maintain applies.
The value shows up while you write. Every time you reach a step you cannot describe without saying it depends, you have found something the platform does not control. Every time the honest answer is that only you can do it, you have found the real result. Keep a second list of those, because that is the one your manager needs.
Start with everything the calendar already knows
The recurring work is the easiest part, because it is already scheduled somewhere. Open the job scheduler, the integration run history and your own calendar, then write down everything that fires between the day you leave and the day you return. In Workday that means payroll interface runs, scheduled report deliveries and whatever sends data to finance at period end. In ServiceNow it means scheduled jobs, discovery schedules and the instance scan that lands every Sunday night.
For each one, write what a normal run looks like and where to see it. Not the theory, the actual navigation path and the actual record count range. The weekly worker sync moves between forty and ninety records on a normal Tuesday. If your stand-in sees four thousand, something upstream changed and they should stop rather than rerun it.
Then mark which of those runs need a human at all. Most of them do not. The ones that do are the short list your stand-in will spend two weeks on, and everything else can be left alone with a note saying exactly that.
The requests that arrive every week
Pull the last three months of tickets assigned to you and sort them by category. The tail is long and the head is short. In most small teams four or five request types cover the large majority of what arrives, and those are the only ones worth a written procedure.
Write each procedure the way the person will experience it, from the ticket landing in the queue to the sentence they send back. Access requests deserve the most care, because they arrive most often and are easiest to get wrong under time pressure. The discipline in access request governance for ServiceNow carries over. A stand-in granting a broad role because it was quicker is how security group sprawl in Workday begins.
Include the refusal language too. A good share of what arrives in a small platform queue should be answered with a polite no or a redirect, and a stand-in who cannot tell which share is which will either approve all of it or none of it.
The alarms that are normal and the quiet things that are not
Every platform produces noise the regular administrator has learned to ignore. The nightly integration that fails on the first attempt and succeeds on the retry. The error count that spikes every Sunday because the maintenance window restarts a connector. The queue that swells during a mass load and drains by lunchtime. Name each one and describe what normal looks like.
The other list matters more and takes longer to assemble. A single failed row in a payroll extract is not noise. A certificate expiry notice with three weeks left stops being a future problem when you are away for two of them. A queue growing slowly and steadily is worse than one that spikes. End each description with the instruction to escalate rather than watch.
Two sentences of context beat a monitoring threshold. A number tells somebody a figure moved and nothing about whether it matters, and a stand-in with no history will either phone you on holiday or ignore it entirely. If something does break, the first thirty minutes of a platform incident should already be written down where they can find it.
Who to call and what they will ask you for
Vendor support is where handovers fail quietly. Your stand-in gets to the point of raising a case and discovers they cannot, because the support portal holds a fixed list of authorised contacts and their name is missing. Check that list before you go and add them.
Write down the tenant or instance names exactly the way support will ask for them, the contract number, and the severity definitions your agreement actually uses rather than the ones you assume. People raising a first case pick the wrong severity in both directions. Say who internally may authorise a P1, because that call carries a cost your stand-in should not be committing to alone.
Add the internal contacts too. The payroll manager who will know whether a number looks wrong. The integration owner on the finance side. The person who can approve an emergency change when the change approval board cannot convene in time. Names and phone numbers, never distribution lists.
The list of what nobody should attempt
The most useful page in the document is the one saying what to leave alone. An unclear boundary is what turns a small issue into a large one, because a capable person under pressure will try to help, and helping inside a platform they do not know well is how a one hour problem becomes a three day recovery.
Be blunt and be specific. Do not run the payroll integration manually. Do not modify a security group or change a business process definition. Do not accept a scheduled upgrade date. Do not restore or clone anything. For each of those, say what to do instead, which is almost always to log it, tell the requester it will be handled on my return, and move on.
Queuing has to be stated as the correct answer, because a stand-in who parks something urgent-sounding will assume they let everybody down. Tell them in writing that a two week delay on a configuration change costs very little and an unplanned restore costs a great deal. Give that permission in advance and they will use it.
Have someone else run it while you watch
A runbook nobody has executed is a guess. The test is simple and slightly uncomfortable. Two weeks before you go, hand the document over and have your stand-in perform one routine task from it, start to finish, while you sit there and say nothing. They drive.
I did this before a fortnight away from a mid-sized manufacturer where I was the only person who touched the Workday to ServiceNow worker sync. The service desk lead covering for me got four steps into the reprocess procedure and stopped, because the job ran under an integration account whose credentials lived in my personal password store and nowhere else. My runbook said to rerun it. It never mentioned that exactly one human could authenticate to do so.
That took a morning to fix and had been sitting there for two years. The same dry run turned up a report the finance close depended on that only I knew how to regenerate, and a monitoring alert routed to my mailbox instead of a shared one. Writing alone would not have surfaced either of them.
Do the dry run, fix what it finds, then go away and leave the laptop. If the document survives without a phone call, keep it current after every release. If it does not, the notes your stand-in made about where it broke down are the most honest maintenance backlog you will get for a platform one person has been wearing four hats to hold up.
