أداة بناء SOP: تحويل ملاحظات العملية الفوضوية إلى إجراء مرقّم مع حالات الحافة
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.
معظم وثائق الإجراءات تموت في المرحلة نفسها: يُطلب من شخص يعرف العملية جيدًا لدرجة أنه يستطيع تنفيذها دون تفكير أن يكتبها، وما يخرج يكون إما غامضًا جدًا بحيث لا يمكن اتباعه، أو يفتقر إلى الأحكام التقديرية التي جعلته متميزًا في أداء المهمة من البداية. صيغة التعليمات أدناه صُممت لاستخراج تلك الأحكام التقديرية تحديدًا من مدخلات غير منظمة — مثل نص محادثة، أو قائمة نقطية، أو مذكرة صوتية انسيابية — دون الحاجة إلى أن يقوم المصدر بتنظيم معرفته أولاً.
مثل كل صيغة تعليمات في IRCNF، تتبع هذه الصيغة هيكل "الدور + السياق + المهمة + القيود + تنسيق الإخراج". الخيار التصميمي المميز هنا هو فصل الخطوة 1 (استخراج التسلسل الرئيسي) عن الخطوة 2 (استخراج الحالات الاستثنائية) كتمريرين صريحين ومنفصلين بدلاً من تعليمة واحدة مدمجة.
لماذا نفصل الإجراء الرئيسي عن الحالات الاستثنائية
عندما تطلب من نموذج أن "يكتب إجراء تشغيلي معياري (SOP)" في جلسة واحدة، فإنه يميل إلى دمج الاستثناءات ضمن القائمة المرقمة الرئيسية على شكل هوامش بين قوسين، مما يجعل الوثيقة أصعب في المسح وأسهل في سوء الفهم تحت الضغط — أي بالضبط عندما يكون الشخص أكثر احتياجًا لاستشارتها. فرض الحالات الاستثنائية في قسم خاص بها، كل منها مرتبط بنقطة قرار محددة في الإجراء الرئيسي، يحافظ على قابلية قراءة المسار الأساسي مع الاحتفاظ بكل استثناء ذكره الخبير.
لماذا تُصاغ التعليمات لتطرح أسئلة بدلاً من التخمين
الملاحظات الأولية نادرًا ما تكون متسقة داخليًا — فقد يذكر مندوب مبيعات حدًا قدره 25 دولارًا في جملة، ثم يشير ضمنيًا إلى رقم مختلف لاحقًا عند وصف مثال. إذا تُرك النموذج دون قيود، فسيختار واحدًا بصمت ويكمل، مما ينتج إجراءً تشغيليًا معياريًا يبدو واثقًا لكنه خاطئ بطريقة لن يكتشفها أحد حتى يتم اتباعه فعليًا. قسم "أسئلة مفتوحة" الصريح في المخرجات موجود لكي تظهر التناقضات كقائمة مرجعية للشخص الذي سيقوم بإنهاء الوثيقة، بدلاً من أن يتم حلها بشكل غير مرئي بواسطة أفضل تخمين للنموذج.
لماذا كُتبت لأقل القراء خبرة
الشخص الذي يملي الملاحظات عادةً ما يكون الأكثر خبرة في الفريق، مما يعني أن نموذجه الذهني يتجاهل خطوات تبدو واضحة جدًا بحيث لا تستحق الذكر بصوت عالٍ. توجيه النموذج صراحةً للكتابة لأقل القُرّاء خبرة — وليس المصدر الخبير — يلتقط الخطوات التي لن يفكر المخضرم في كتابتها أبدًا لأنها أصبحت تلقائية لسنوات.
النتيجة هي وثيقة يمكنك تسليمها لموظف جديد في أول يوم له، وليست مسودة لا تزال بحاجة إلى جولة من التعديلات من شخص يعرف العملية بالفعل.