O Construtor de SOP: Transforme Anotações de Processo Confusas em um Procedimento Numerado com Casos Extremos
Why this prompt matters
When the one person who knows a process leaves, undocumented judgment calls leave with them — and the team that inherits the process has to relearn every edge case the hard way, usually by getting it wrong in front of a customer first. Operations teams that rely on verbal handoffs instead of written SOPs see new hires take roughly three times longer to reach full competency, because trial-and-error replaces a reference document. Worse, inconsistent handling of the same edge case by different reps is one of the most common sources of repeat customer complaints, since customers who get two different answers to the same question from two different reps in the same company lose trust in the process itself, not just the individual rep.
What we use it for
You're the operations lead at a 40-person e-commerce company. Your best returns-processing rep — who trained every new hire informally over the shoulder for two years — just gave two weeks' notice. Before she leaves, you sit her down and record a rambling 45-minute voice memo where she talks through how she actually handles returns, including all the undocumented judgment calls: what she does when an item comes back damaged versus defective, how she handles returns shipped to the wrong address, when she approves a partial refund without requiring the item back at all. You paste the transcript into this prompt to turn two years of tribal knowledge into a document her replacement can follow from day one.
Prompt
Role: You are a senior operations manager and technical writer who specializes in converting ad hoc, undocumented processes into clear, auditable Standard Operating Procedures (SOPs). Context: Here are my rough notes on how this process actually works, in whatever form I have them (voice memo transcript, bullet points, stream-of-consciousness description): [PASTE YOUR ROUGH NOTES, VOICE MEMO TRANSCRIPT, OR MESSY DESCRIPTION OF THE PROCESS HERE] This process is performed by [ROLE OR TEAM, e.g., "customer support reps"] and needs to be followed consistently by people with varying experience levels, from [EXPERIENCE LEVEL, e.g., "first-week hires to 3-year veterans"]. Task: Convert these notes into a clear, numbered Standard Operating Procedure. As you do this: 1. Identify the main sequential steps of the process, in the order they actually happen. 2. Separately identify every edge case, exception, or "what if" scenario mentioned or implied in the notes — even ones only hinted at. 3. For each edge case, specify the exact decision point where it diverges from the main procedure and what should happen instead. 4. Flag any step where the notes are ambiguous or contradictory, and ask a clarifying question rather than guessing. Constraints: - Do not invent steps, tools, or policies that are not stated or clearly implied in the notes. - Keep each numbered step to one action — split compound steps into separate numbers. - Write for the least experienced person who will use this SOP, not the expert who dictated it. - Preserve any specific tool names, thresholds, or numbers mentioned exactly as given. - If the notes conflict with each other (e.g., two different refund limits mentioned), flag it explicitly instead of picking one silently. Output Format: ## [Process Name] — Standard Operating Procedure ### Main Procedure 1. [Step] 2. [Step] ... ### Edge Cases and Exceptions - **[Edge case name]**: At step [X], if [condition], then [action] instead of the standard step. ### Open Questions - [Any ambiguity or contradiction that needs clarification before this SOP is finalized]
Result
Returns Processing — Standard Operating Procedure
Main Procedure
- Log in to the returns portal and pull up the customer's order using the order number or email address.
- Verify the return request falls within the 30-day return window from the delivery date.
- Ask the customer to confirm the reason for return from the dropdown (damaged, wrong item, no longer needed, defective).
- Generate a prepaid return shipping label and email it to the customer.
- Mark the order status as "Return in Transit" in the system.
- Once the item is received at the warehouse, inspect it against the stated return reason.
- If the inspection matches the stated reason, process a full refund to the original payment method within 1 business day.
- Send the customer a refund confirmation email.
Edge Cases and Exceptions
- Damaged vs. defective distinction: At step 6, if the item shows shipping damage (crushed box, torn packaging) rather than a manufacturing defect, file a carrier damage claim instead of a standard restock — these go through a separate reimbursement process and should not be marked as customer-caused.
- Wrong address returns: If the prepaid label at step 4 gets returned to sender because the customer's address was entered incorrectly, do not automatically deny the return. Contact the customer once to get a corrected address and reissue the label before closing the case.
- Partial refund without return: For orders under $25, if the customer reports an item as damaged or defective with photo evidence, skip steps 4-6 entirely and process a full refund without requiring the item to be shipped back — the cost of return shipping and inspection exceeds the item's value.
- Refund threshold escalation: Any refund over $200 requires a second approval from a team lead before step 7, regardless of the return reason.
Open Questions
- The notes mention a "7-day grace period" for gift returns but don't specify whether this extends the 30-day window or runs concurrently with it — confirm with the rep before finalizing this SOP.
- It's unclear whether the $25 no-return-required threshold applies per item or per order when a customer returns multiple items in one shipment.
A maioria da documentação de processos morre no mesmo estágio: alguém que conhece o processo bem o suficiente para executá-lo no piloto automático é solicitado a escrevê-lo, e o que sai é muito vago para seguir ou carece das decisões de julgamento que os tornaram bons no trabalho em primeiro lugar. O prompt abaixo foi criado para extrair exatamente essas decisões de julgamento de entradas não estruturadas — uma transcrição, uma lista com marcadores, um memorando de voz fluxo de consciência — sem exigir que a fonte organize primeiro seu próprio conhecimento.
Como todo prompt no IRCNF, ele segue Papel + Contexto + Tarefa + Restrições + Formato de Saída. A escolha de design diferenciadora aqui é dividir a etapa 1 (extrair a sequência principal) da etapa 2 (extrair casos excepcionais) como duas passagens explícitas e separadas, em vez de uma instrução combinada.
Por que separar o procedimento principal dos casos excepcionais
Quando você pede a um modelo para "escrever um SOP" de uma só vez, ele tende a incorporar exceções na lista numerada principal como parênteses laterais, o que torna o documento mais difícil de escanear e mais fácil de ler equivocadamente sob pressão — exatamente quando alguém tem mais probabilidade de consultá-lo. Forçar os casos excepcionais para sua própria seção, cada um vinculado a um ponto de decisão específico no procedimento principal, mantém o caminho primário legível enquanto ainda preserva cada exceção mencionada pelo especialista.
Por que o prompt é instruído a fazer perguntas em vez de adivinhar
Anotações brutas raramente são internamente consistentes — um representante pode mencionar um limite de $25 em uma frase e implicar um número diferente depois ao descrever um exemplo. Sem restrições, um modelo escolherá silenciosamente um e seguirá em frente, o que produz um SOP de aparência confiante que está errado de uma forma que ninguém perceberá até que já esteja sendo seguido. A seção explícita "Perguntas em Aberto" existe para que contradições venham à tona como uma lista de verificação para a pessoa que finaliza o documento, em vez de serem resolvidas invisivelmente pelo palpite do modelo.
Por que é escrito para o leitor menos experiente
A pessoa que dita as anotações geralmente é a mais experiente da equipe, o que significa que seu modelo mental pula etapas que parecem óbvias demais para serem ditas em voz alta. Instruir explicitamente o modelo a escrever para o leitor menos experiente — não para a fonte especialista — captura as etapas que um veterano nunca pensaria em escrever porque são automáticas há anos.
O resultado é um documento que você pode entregar a um novo contratado no primeiro dia, não um rascunho que ainda precisa de uma rodada de edições de alguém que já conhece o processo.