Turning a Messy, Undocumented Process Into a Real SOP With Gemini
Every operations team has at least one process that lives entirely in someone's head. It works, the person who runs it could do it in their sleep, and nobody has ever written it down because there was never a good moment to stop and document it. Then that person goes on leave, or leaves the company, and the process either breaks or gets reconstructed badly by someone guessing at steps that used to be obvious.
If you're the person holding that knowledge, the hard part was never writing. It's that you know the process too well to explain it well. You skip steps you do automatically, you don't mention the exceptions because you handle them without thinking, and you assume context a new hire doesn't have. Gemini is genuinely good at the opposite problem: it doesn't know any of it, so it asks the questions a documentation template never would.
If you haven't used Gemini for structured writing work before, the Complete Beginner's Guide to Gemini covers the basics this workflow builds on.
Why "just write the SOP" doesn't work
Asking Gemini to "write an SOP for our customer refund process" produces a generic, plausible-looking document with sections in the right places and content that's almost entirely invented, because Gemini has no idea what your refund process actually is. The output looks finished, which is exactly the problem: a wrong-but-polished SOP is more dangerous than no SOP at all, because someone will trust it.
The better approach flips the direction of the conversation. Instead of asking Gemini to produce the document, have it interview you, and build the document from your answers.
The interview-first workflow
- 1
Ask Gemini to interview you, not write for you
Open with a prompt that sets up the process, not the output. Something like: "I need to document our customer refund process as an SOP. I know the process well but I've never written it down. Interview me step by step, asking one question at a time, until you have enough detail to draft a real SOP. Start by asking me what triggers the process."
- 2
Answer in plain language, including the exceptions
When Gemini asks a follow-up, answer the way you'd explain it to a new coworker standing next to you, including the "oh, except when..." cases. Those exceptions are usually the most valuable content in the whole document, and they're exactly what gets lost when someone tries to write an SOP from memory in one sitting.
- 3
Let it draft a section at a time, and correct it immediately
Once you've covered one logical chunk of the process (say, the intake step), ask Gemini to draft just that section before moving to the next one. Reading a small draft while the details are fresh in your head makes it much easier to catch a missed exception than reviewing the whole document at the end.
- 4
Do a final pass for a reader who knows nothing
Once every section is drafted, ask Gemini to reread the whole document as if it were a brand-new hire's first day, and flag anywhere a term, system name, or assumption isn't explained. This catches the "obvious to you" gaps that are invisible once you're this close to the content.
A real example: turning refund handling into an SOP
Say the actual process, undocumented, looks like this in your head: a customer emails asking for a refund, you check if it's within 30 days, you check if the product was used or unused, you process it differently depending on which payment method they used, and there's an unwritten rule that anything over $500 needs a manager's sign-off first.
The interview might go like this. You'd open with the prompt above, and Gemini's first question would be something like "What's the very first thing that happens when a refund request comes in, before you've made any judgment calls?" You answer plainly: "A customer emails support, or fills out the contact form. Support checks the order date first." Gemini follows up: "What happens if the order is outside the 30-day window? Is it an automatic decline, or is there judgment involved?" That's exactly the kind of branching case a generic AI-written SOP would have missed or flattened into "requests outside the window are declined," when the real answer might be "usually declined, but a manager can approve an exception for a loyal customer."
By the end of that exchange, you have a documented exception path that existed only in your head five minutes earlier. That's the actual value of the interview approach: not faster formatting, but surfacing exactly the tribal knowledge a template-first approach would have silently skipped.
From scattered notes to a finished excerpt
To see the whole arc in one place, here's what the raw input actually looks like before any of this happens, next to what comes out the other end.
The input is genuinely messy, the kind of thing you'd type into a note app in five minutes, not a document:
Raw input: what the process owner actually knows, unstructured
refund requests come in by email or the contact form. first check order date, 30 days is the cutoff but Priya sometimes approves an exception for a loyal customer if it's like a few days over. then check if the item was used or still sealed, unused ships back for full refund, used ones only half back unless its defective. payment method matters too, card refunds go through Stripe same day, PayPal ones take like 2-3 days to actually clear. anything over $500 needs a manager sign off before we touch it, learned that one the hard way. done when the customer gets the confirmation email, not just when the money moves.
That gets fed through the interview prompt from the first step above, one exchange at a time, until Gemini has asked about every branch (the exception, the used-versus-unused split, the payment method difference, the dollar threshold). The output of that interview, once drafted and reviewed, is a structured document. Here's a representative excerpt of the finished result:
Google Docs
Excerpt of the finished SOP document, illustrated, not a real screenshot
Customer Refund Process, Step 3: Determine Refund Eligibility
| Step | Action | Responsible Party | What Could Go Wrong |
|---|---|---|---|
| Step 3a | Confirm order date is within 30 days of purchase | Support agent | Order date is missed or misread from the order system, agent applies the wrong cutoff |
| Step 3b | If outside 30 days, check for loyalty exception before declining | Support agent, escalate to team lead | Exception gets granted informally without being logged, so the same customer asks again later expecting the same treatment |
| Step 3c | Check item condition: unused (full refund) vs. used and undamaged (half refund) vs. used and defective (full refund) | Support agent | Item condition is taken from the customer's own description instead of verified, leading to an incorrect refund amount |
| Step 3d | If refund total exceeds $500, route to manager for sign-off before processing | Support agent, manager | Agent processes the refund before sign-off arrives because the customer is on the phone and pressure to resolve it immediately |
Notice what made it into the finished excerpt that the raw notes only implied: each row has a named responsible party instead of "someone handles it," and each row has an explicit failure mode instead of just an instruction. Neither of those existed in the original messy notes as a separate column, they were buried inside phrases like "learned that one the hard way." Pulling them out into their own column is what turns a memory dump into a document someone else can actually follow without already knowing where the landmines are.
Tip
If the process involves a dollar threshold, an approval step, or a "usually, but not always" rule, say so explicitly during the interview even if it feels like a minor detail. Those conditional rules are the parts a new hire gets wrong first, and they're the easiest parts to leave out of a document written from a template instead of a real interview.
What a finished SOP needs that a first draft usually misses
A clear trigger: exactly what starts the process, stated concretely
Every decision point named as a branch, not folded into the "normal" path
Who has authority to approve an exception, and at what threshold
What tools or systems are involved, named specifically, not "the system"
What "done" looks like, so a new hire knows when to stop
Why this actually solves the tribal knowledge problem
Tribal knowledge doesn't get lost because nobody writes anything down. Plenty of teams have a wiki page or an old onboarding doc that technically covers the process. It gets lost because what actually gets written down is the happy path, the version of the process that works when nothing unusual happens, while the parts that only live in one person's head are precisely the exceptions, the thresholds, and the "who's actually allowed to override this" details that never seemed worth writing down because the person doing the work resolved them automatically, without noticing they were making a judgment call at all.
A document resists that decay for a specific, structural reason: it forces every branch to be named as its own row or step instead of folded silently into the "normal" path, and it forces a responsible party to be named for each one instead of left as "the system handles it" or left unstated entirely. Once the loyalty exception in Step 3b above is its own row with its own owner, it can't quietly disappear the way it would if it were one clause buried in a paragraph about the 30-day policy. The "what could go wrong" column does the same job for failure modes: it turns "learned that one the hard way" from an oral history only the original person carries into a written warning anyone reading the document inherits on day one, whether or not they ever meet the person who learned it.
That's the actual difference between a document that happens to describe a process and one that's resistant to the person who knows it leaving. The first kind survives until someone hits the edge case that wasn't written down. The second kind was built specifically by interrogating where those edge cases are, which is exactly what the interview approach above is doing, one question at a time.
Where this still needs a human
Gemini can organize your knowledge into a clean, well-structured document, but it can't verify that the process it wrote down is the one your team should actually be running. Once the draft exists, have someone who didn't write it, ideally someone relatively new, try to follow it literally and flag anywhere they'd have gotten stuck. That's the same "fresh eyes" test that catches gaps in any documentation, and it matters more here because the SOP was built from one person's account of a process, with no second source to catch a misremembered step.
Common mistake
Treating the first full draft as done. The interview approach catches far more detail than writing from a blank page, but it still reflects only what you thought to mention. Have at least one other person who's touched the process review it before it becomes the official version.
Once the SOP exists as a document, it's also a natural fit for later use as a Knowledge file inside a Gem built around that specific process, so future questions about edge cases get answered from the document itself rather than reconstructed from memory each time.
Official sources
Checked on September 21, 2026. Features, plans and names change often, so the vendor's own pages are the final word.