Let’s be honest: most guest posting operations run on a mix of good intentions and one person’s memory. Somebody knows how pitches get tracked, somebody else knows which draft is the latest, and a third person remembers to check that a published article actually went live. It all works until one of them is out sick. This friendly checklist will help you spot which parts of your guest posting process are written down and which live only in someone’s head, and then turn the weak spots into a short guest posting runbook anyone on your team can follow.
There is no scoring and no pass mark. Read each section, answer the questions out loud, and write down whatever makes you wince. Those are your first runbooks.
Before you begin: the one rule
A runbook is a one-page, numbered routine for a job you do over and over. It names the trigger (what starts it), the owner (who is responsible), the steps, and what “done” looks like. If a job repeats more than twice, it deserves a page. That is the whole philosophy, so keep it in mind as you go through the list.
Checklist part one: finding and pitching
- Could a new teammate shortlist target sites without asking you? If the answer depends on “a feel for it,” write down the three or four things you actually check each time.
- Is the pitch process written? Who drafts it, who approves it, what goes in the message, how long you wait before following up. A short routine here prevents duplicate pitches to the same editor, which is awkward for everyone.
- Is there one shared place for pitch status? If it lives in a personal inbox, that is a single point of failure. Move it to a shared sheet and write the update steps next to it.
For the pitching side specifically, it helps to have a model of what a good approach contains. A walkthrough on pitching and writing for niche-focused publications is a nice reference to lift ideas from. Turn those ideas into your own numbered list and keep it beside the shared sheet.
Checklist part two: writing and structure
- Do your writers start from the same outline shape? If every article is built from scratch, quality swings with the writer’s day. Many teams keep a few agreed structures, such as how-to, comparison or list, and a note on when to use each. A piece on building articles faster from reusable content templates explains why that saves time.
- Is there a written review routine? Who reads the draft, what they check (accuracy, tone, links, formatting), and how feedback is returned.
- Can anyone find the latest version of any draft in under a minute? If not, a naming and storage routine is your very first runbook. It takes ten minutes to write and removes a daily annoyance.
Checklist part three: submission and publication
- Is submission a routine or a ritual? A routine says: format the piece, attach the author details, send it by the agreed route, log the date. A ritual says: ask Dev what we did last time.
- Does someone verify that the article went live and looks right? Write down who, when, and what they look at: title, formatting, links, author box.
- Is there a plan for corrections? Spot a typo a week later? The runbook should say who contacts the publisher and how.
Checklist part four: measuring and learning
- Is there a monthly look at results, with the same few questions each time? Such a review is easy to skip, which is precisely why it should be a short written routine with an owner.
- Do you note why a piece did or did not work? A line in the log is plenty, and it turns each piece into material for the next one. If you want a framework for judging the worth of a placement, the piece on the signals behind a worthwhile guest post gives you a vocabulary you can reuse inside your own routine.
Checklist part five: the handover test
- If you vanished for two weeks, who would do your job? Name them. If the name makes you nervous, send them your draft runbook now.
- Is every runbook in one findable place, with a front page that lists every routine, its owner and its last review date?
- Has someone other than the author tried each one? A runbook nobody else has followed is a guess. Ask a colleague to run it on a quiet day and note every question.
Turning your wince list into pages
By now you probably have three or four items flagged. Do not try to write everything this week. Choose the one that would hurt most if its owner could not come in tomorrow, and follow this simple recipe.
- Open a blank document and title it with a verb phrase, like “Log a new pitch.”
- Write the trigger, the owner and the cover person.
- List the steps as you actually do them, one short sentence each, starting with a verb.
- Add a line for “done means.”
- Hand it to a colleague and watch them use it without helping.
- Fix every spot where they paused.
- Store it in the shared folder and add it to the index.
That is a morning’s work for a first runbook and about twenty minutes for each one after.
A sample page: “Log a new pitch”
To show how small a good runbook can be, here is the page a team might write for the first item on the list. Trigger: a pitch email has just been sent. Owner: whoever sent it. Cover: the person named on the front page.
- Open the shared pitch sheet and add a new row at the top.
- Fill in the site name, the editor’s name, the working title, and today’s date.
- Paste a link to the pitch email, or the full text if the email lives in a private inbox.
- Set the status to “sent” and write the follow-up date, seven working days ahead.
- Check the sheet for the same site in the last six months. If you find a row, add a note and tell the person who owns that relationship.
Done means: one new row, a status, a follow-up date and no surprise duplicates. Notice there is no advice about what makes a pitch good; that is craft, and craft belongs in training, not in a procedure. The runbook only protects the bookkeeping around the craft, which is where things quietly go missing.
Once the first page exists, the rest feel easier. People stop asking whether something is worth writing and start asking which job to tackle next, which is the healthiest question a small team can ask itself.
Bridging the gap with other teams
If your writers like to see how other disciplines manage this, data teams are a good source. They keep short procedures for everything from rerunning a failed load to checking yesterday’s numbers, and TheDataOps.org is an accessible blog on that culture for engineers moving from DevOps toward dependable data work. You will not need the technical bits, but the habit of writing the routine down travels well.
Keep it alive
A runbook that is never touched goes stale quickly. Build the upkeep into the work itself. When a step turns out to be wrong, fix the page the same day. When a good trick turns up, add it. Once a quarter, glance at the index and retire anything you no longer do. Done this way, the documents stay small, honest and useful, and the whole thing costs you a few minutes a month.
Most importantly, tell the team why you are doing it. Nobody enjoys feeling replaceable, but everybody enjoys a week off without a flood of messages. Frame the pages as the thing that lets each person step away and come back to a calm inbox. Run through the checklist again in three months, and see how many of your wince items have quietly turned into green ticks.