Priya had run the enquiry desk at a cardiac hospital for eleven years, and nobody noticed how much of the job lived only in her head until she caught a bad flu and was out for a week. The phone kept ringing. The new coordinator covering for her did her honest best, but callers were asked the same questions twice, two families were promised callbacks that never happened, and a travelling patient’s scan reports sat unopened in a shared inbox. A good front-office runbook would have prevented all of it, and writing one is a quiet, practical project any heart surgery department can finish in a few afternoons.
This post is a checklist and audit in story form: what to write down, in what order, and how to test whether your desk could survive a sudden absence. It is strictly about administrative routines. Nothing here is medical guidance, and the runbook you build should never contain it; clinical questions always go to the clinical team.
Why the enquiry desk is the first runbook to write
Enquiries are the most repeated task in a hospital front office. They arrive by phone, email, web form and walk-in, and they follow a pattern: someone wants to know how to reach a department, what paperwork to bring, or how an appointment request works. Because the pattern repeats, it is ideal for a written procedure. Because it is handled by whoever happens to be at the desk, it is also where inconsistency does the most damage to a family’s first impression.
The rule of thumb Priya’s team adopted afterwards was simple: if you have done a task more than twice, or if a fix worked once and you do not want to rediscover it, it deserves a page. That rule is borrowed from operations teams in technology. Data teams who run pipelines call the pages runbooks, and the habit is well described on TheDataOps.org, whose articles trace how engineering teams grow from DevOps habits into steady data operations. A hospital desk has nothing to do with pipelines, yet the principle transfers neatly.
The checklist: what goes into an enquiry runbook
Sit with the person who knows the desk best and ask them to talk through a normal morning. Capture it under these headings.
- Channels and who watches them. List every inbox, phone line and web form, with the times each is checked and the named backup for each.
- The first-contact script. A short opening, the details to note (name, preferred contact method, language, the department asked about) and what not to ask. No diagnoses, no reports read out loud.
- Routing table. A one-page grid of question type against owner: scheduling, billing, records, international coordination, clinical team.
- Response promises. The time you tell callers to expect a reply, written once, so every person says the same thing.
- Logging. Where each enquiry is recorded, which fields are mandatory and how an item is marked closed.
- Escalation. Who decides when something is unusual, upset or urgent, with a phone number that is actually answered.
- Hand-over note. A template for end of shift: open items, promised callbacks, anything waiting on another department.
Write it in the language of the desk, not the policy manual
The most common failure of a runbook is that it reads like a policy. Policies describe intent; runbooks describe actions. Each step should begin with a verb and be short enough to follow with a phone cradled on one shoulder. Compare “Enquiries shall be acknowledged promptly” with “Reply to every web enquiry the same working day, even if the reply is only ‘we have it and will update you by Thursday’.” The second can be followed by a stranger on their first morning.
Priya’s draft was two pages for the whole desk, plus one extra page for the scenario people feared most: a family member calling in distress. That page did not try to handle the emotion with a script. It said who to transfer to, what to say while transferring, and how to log the call afterwards. Knowing the next move is itself calming for the person at the desk.
Audit it: the stranger test
A runbook is only finished when someone who has never worked the desk can use it. Run the test like this.
- Pick a colleague from another department and give them the document with no coaching.
- Hand them five realistic enquiries, written on cards: a request for the appointment procedure, a billing question, a relative asking where to send documents, a caller whose language is not the desk’s usual one, and a vague message with no clear request.
- Watch where they hesitate. Every pause points to a missing step or an unclear word.
- Fix the page the same day, while the confusion is fresh.
Repeat the test twice a year or after any change in staffing, phone systems or reporting lines. A runbook that is not touched becomes fiction within a season.
Keep the clinical line bright
Heart surgery enquiries tend to be emotional, and families often want a front-office person to confirm something about a condition or a result. A good runbook protects both the family and the staff by stating plainly that the desk does not interpret reports or recommend treatment. It then gives staff a kind, ready phrase for handing over to the clinical team, and a record of when that hand-over happened. If your site already publishes background reading, you can point families to it as general information; for example, an overview of how remote follow-up visits fit into care after an operation explains the idea without anyone at the desk needing to improvise.
Cover the people who travel to you
Patients coming from other cities or countries add questions about documents, timing and who they will meet on arrival. Give that group its own short section: the documents the desk can legitimately ask to be sent ahead, the person who confirms scheduling, and a standard acknowledgement email. Linking to your existing explainer on planning specialised heart surgery care through a remote consultation gives overseas families something to read while they wait, and it means the desk is not retelling the same background by phone every time.
Where the runbook lives
Location matters as much as content. Print one copy for the desk, store one in a shared drive everyone can open, and name an owner whose job includes a quarterly review. Date every page. When someone finds a better way to handle a situation, they edit the page the same week instead of telling a friend. That is how the knowledge stays with the department and not with a single person.
When Priya returned, she did not feel replaced; she felt relieved. The desk had a document that answered the questions she used to get on her days off. Her expertise was now in a form the whole department could use, and she spent the following month improving it, which was a far better use of eleven years of knowledge than being the only person who could answer the phone.