Anyone who follows Indian legal news knows the rhythm: orders are pronounced, notifications appear in the gazette, bills move through committees, and by the next morning a reader expects a clear account of what changed. Behind every dependable daily digest there is a routine. When that routine lives only in one editor’s habits, the digest wobbles the day that editor is unwell, travelling or simply moves to another assignment. Here is how a legal news desk runbook gets built, one stage at a time so that the daily work can be repeated by any trained member of the team.

The aim is modest and practical. A runbook is not a policy manual. It is a short, numbered procedure for one recurring task, written plainly enough that a stand-in new to the job can follow it on a busy day. This is not legal advice. It is simply a way of organising editorial and administrative work around legal developments.

Step 1: List the tasks you repeat more than twice

Begin with a plain inventory. Sit with the people who run the desk and ask a single question: which jobs did we do this month that we also did last month? On a legal news desk the list usually looks something like this:

• Morning scan of court cause lists, judgments uploaded overnight and official notifications.
• Selecting and ranking the developments that deserve a place in the daily summary.
• Verifying a quoted provision, section number or date against the primary document.
• Publishing the digest and updating earlier items when a ruling is stayed or a notification is withdrawn.
• Handling a correction request from a reader or an advocate.
• Handing the desk over at the end of a shift or before leave.

Resist the urge to cover every duty in the first week. Pick the three tasks that would hurt most if the usual person vanished tomorrow. Those become your first runbooks.

Step 2: Watch the task being done, then write what you saw

The person who knows the task best is the worst person to write it down from memory, because experts skip steps they no longer notice. Instead, ask them to perform the task while a colleague takes notes. Record every action, including the small ones: which tab is opened first, which official website is trusted for which type of document, what makes an item “too thin to publish”.

Then rewrite the notes as numbered steps, each beginning with a verb. “Open the day’s judgments list on the court website” is a step. “Be careful with judgments” is not. If a step contains the word “usually”, ask what happens in the unusual case and write that down too.

Step 3: Give every runbook the same shape

A consistent layout means a stranger can find what they need in seconds. A good legal desk runbook has six short parts:

1. Purpose. One sentence on why the task exists, such as “publish a reliable summary of the previous day’s developments before mid-morning”.
2. When it runs. The time, the trigger and who normally owns it.
3. What you need. Logins, folders, templates and the list of trusted primary sources.
4. The steps. Numbered, in order, with the expected result of each.
5. If something looks wrong. The decision points: what to do when a document will not open, when two sources disagree, when a ruling seems to contradict a recent one.
6. Who to tell. The person to inform and the way to reach them, including a backup.

Keep each runbook to one page. If it grows longer, split it. A procedure that nobody can read in a couple of minutes will not be opened during a busy shift.

Step 4: Write the verification step like a recipe

Accuracy is the heart of a legal news desk, and it is also the first thing to be lost when a task is handed over casually. Turn your verification habits into explicit instructions. For example:

1. Locate the primary document, whether the judgment text, the gazette notification or the bill as introduced.
2. Check the date of pronouncement or publication against the date in your draft.
3. Confirm the name of the bench or issuing authority.
4. Check that any section or article number you quote appears in the document in the form you wrote it.
5. If a reported outcome differs from the document, trust the document and note the difference in the draft for the editor.
6. Mark the item as checked by initialling the draft before it moves on.

Writing this out may feel obvious to a veteran, but it is precisely the kind of routine that a new colleague, a stand-in or a tired editor at the end of a long day will thank you for.

Step 5: Show what a finished output looks like

Alongside the steps, attach a sample. For a daily summary desk, the sample could be a recent edition, such as the June 19 round-up of legal developments, annotated to show how items are ordered, how long each entry runs and where the source is cited. A reader of the runbook then has a target, not just a procedure. If your desk keeps a fixed format across editions, as in the edition from the twelfth of the same month, point out which parts never change and which flex with the news of the day.

Samples also settle small arguments about style. When the runbook shows how a headline is phrased, the next person does not have to guess.

Step 6: Test the runbook with someone who has never done the task

This is the step most teams skip, and the one that makes the document real. Pick a colleague from another desk, hand them the page and ask them to produce the output while you stay silent. Every time they pause, ask a question or guess, you have found a gap. Fix the page, not the person.

Repeat until a newcomer can complete the task without calling anyone. Note the date of the successful test at the bottom of the runbook; it tells future readers how fresh the instructions are.

Step 7: Store the runbooks where people actually look

A brilliant runbook in a forgotten folder protects nobody. Keep all of them in one shared place that everyone on the desk can open from a phone. Name each file after the task, not the author, so “Daily digest: morning scan” rather than “Anita’s notes”. Link to the folder from the desk’s chat channel description and from the handover template.

Assign an owner for each page. The owner is not the only person who may do the task; the owner is simply responsible for keeping the page current.

Step 8: Update the runbook after every surprise

The best moment to improve a runbook is right after it failed you. If a court website changed its layout, if a new type of notification appeared, if a correction request went unanswered for two days, fold the lesson into the page the same afternoon. Add one line to a short change note at the bottom: what changed, when, and why.

A legal desk lives with moving ground. Statutes are amended, portals are redesigned, formats shift. A runbook that is never touched becomes confidently wrong, which is worse than no runbook at all.

Step 9: Use the runbook for handovers and leave

Once the pages exist, they change how the team handles absence. Before leave, the departing editor does not write a long anxious email; they point to the runbooks and add only the live context: which stories are pending, which follow-ups are due and which sources have been slow this week. The stand-in follows the page and escalates only when a decision point demands it.

Over time, this reduces the quiet dependency on one person, and it also makes the desk more pleasant to work in. Nobody dreads their day off, and nobody feels trapped as the only person who knows how things work.

Borrowing the idea from engineering teams

The runbook habit is not new, and it did not start in newsrooms. Operations engineers have long written step-by-step procedures for restarting services and recovering from failures. For a look at that culture from the data side, TheDataOps.org carries articles for teams trying to keep their pipelines steady without last-minute heroics, and its habit of writing the routine down transfers neatly to editorial work.

A starter template you can copy today

If you want to begin this week, copy the following skeleton into a shared document and fill it in for the first task on your list:

• Task name: a short label such as “Morning scan”.
• Purpose: one sentence.
• Owner and backup: two names.
• Runs: daily, at a stated hour.
• Inputs: sources, logins and templates.
• Steps: numbered, each starting with a verb.
• Checks: the verification list.
• If stuck: who to call.
• Last tested: date and tester.

Fill in one runbook this week, test it on a colleague next week and add the next task the week after. In a month the desk will have a small library of procedures, and the next absence will be a non-event. That is what a good runbook delivers: work that stays accurate and on schedule regardless of who happens to be at the keyboard.