SOP Writing Prompt Templates

STANDARD OPERATING PROCEDURE
Process: New Customer Onboarding
Version: 1.0
Last Updated: [Date]
Owner: Customer Success Team

PURPOSE

This SOP ensures every new B2B customer is properly onboarded from contract signing through go-live. Proper onboarding reduces early churn, increases product adoption, and sets the customer relationship up for long-term success.

WHEN TO USE

Initiate this process within 24 hours of receiving a signed contract notification from Sales. The complete process should be finished before the customer's go-live date (typically 2-4 weeks from contract signing).

TOOLS REQUIRED

- Salesforce (CRM) - customer data and activity logging
- Product Admin Panel - account setup and user management
- Zoom - video calls
- Email (company account)
- Notion - onboarding checklist template

PROCEDURE

STEP 1: RECEIVE AND REVIEW HANDOFF (Day 0)

Time: 30 minutes

1.1 Check Salesforce for the new opportunity marked "Closed Won."

1.2 Review the handoff notes from Sales. Confirm you have:
 [ ] Primary contact name and email
 [ ] Number of users licensed
 [ ] Agreed go-live date
 [ ] Key use cases discussed during sales
 [ ] Any special requirements or concerns noted

1.3 If any information is missing, contact the Account Executive within 4 hours. Do not proceed without complete information.

1.4 Create onboarding record in Notion by copying the Onboarding Template.

Why this matters: Incomplete handoffs are the #1 cause of onboarding problems. Getting this right prevents issues downstream.

---

STEP 2: SEND WELCOME EMAIL (Day 0-1)

Time: 15 minutes

2.1 Use the Welcome Email Template (link) and customize:
 - Customer company name
 - Primary contact first name
 - Go-live date
 - Your calendar booking link

2.2 Include in the email:
 - Your introduction and role
 - What to expect during onboarding
 - Link to schedule kickoff call
 - Initial preparation they can do

2.3 Send within 24 hours of contract signing. Earlier is better - speed signals professionalism.

2.4 Log the email in Salesforce.

If no response in 48 hours: Send a follow-up email. If still no response after 72 hours, escalate to the AE to reach out through their relationship.

---

STEP 3: CONDUCT KICKOFF CALL (Day 1-5)

Time: 45-60 minutes

3.1 Before the call:
 - Review Sales notes again
 - Prepare screen share of product admin panel
 - Have Kickoff Call Agenda ready

3.2 Kickoff call agenda:
 - Introductions (5 min)
 - Confirm understanding of their goals and use cases (10 min)
 - Explain onboarding process and timeline (10 min)
 - Collect: list of users needing access (names, emails, roles)
 - Collect: their preferred training dates
 - Answer questions (10 min)
 - Confirm next steps and go-live date (5 min)

3.3 During the call, take notes on:
 - Any requirements not in Sales notes
 - Customer's technical comfort level
 - Who the day-to-day admin will be

3.4 Within 2 hours of call ending:
 - Send follow-up email summarizing key points and next steps
 - Update Salesforce with call notes
 - Update Notion checklist

---

STEP 4: SET UP ACCOUNT (Day 3-7)

Time: 30-60 minutes depending on complexity

4.1 Access Product Admin Panel.

4.2 Create new organization:
 - Company name (official legal name)
 - Subscription tier (from contract)
 - User limit (from contract)

4.3 Add users:
 - Enter each user's name and email
 - Assign appropriate roles (Admin, User, View-Only)
 - DO NOT send invitations yet

4.4 Configure company settings:
 - Set company timezone
 - Enable/disable features per contract terms
 - Set up any integrations discussed

4.5 Verify setup:
 - Log in as test user to confirm access
 - Check that user limits match contract

4.6 Send user invitations after confirming training date with customer.

Common error: Sending invitations before training is scheduled. Users log in, get confused, and form negative first impressions.

---

STEP 5: CONDUCT TRAINING SESSION(S) (Day 7-14)

Time: 60-90 minutes per session

5.1 Schedule training based on customer preference:
 - All users together (preferred for small teams)
 - Admins first, then users (preferred for larger teams)

5.2 Before training:
 - Confirm all invited users have activated accounts
 - Prepare training environment with sample data
 - Send calendar invite with Zoom link and preparation notes

5.3 Training session structure:
 - Core workflows (based on their use cases) - 40 min
 - Q&A and hands-on practice - 20 min
 - Admin-specific features (if applicable) - 15 min
 - Resources for ongoing learning - 5 min

5.4 During training, note:
 - Questions that indicate confusion
 - Features that generate excitement
 - Users who seem disengaged

5.5 Within 24 hours:
 - Send training follow-up email with recording link and resources
 - Log completion in Salesforce
 - Update Notion checklist

If user attendance is low: Reschedule a makeup session. Do not proceed to go-live with untrained users - this predicts churn.

---

STEP 6: GO-LIVE CHECK-IN (Day 14-21)

Time: 30 minutes

6.1 Schedule check-in call for 2-3 days after their go-live date.

6.2 Before the call, verify in product analytics:
 - Are users logging in?
 - Are they using core features?
 - Any obvious problems?

6.3 Check-in agenda:
 - How is it going? (open-ended)
 - Any blockers or confusion?
 - Review usage data together (if appropriate)
 - Confirm they know how to get help
 - Schedule ongoing check-in cadence

6.4 Complete the CSM Confidence Assessment:
 Score 1-5: Can this customer succeed independently?
 If score is below 4, document specific concerns and create action plan.

6.5 Update Salesforce: Mark onboarding complete. Add confidence score and notes.

---

SUCCESS CRITERIA

Onboarding is complete when:
[ ] All contracted users have activated accounts
[ ] At least 80% of users attended training
[ ] Customer can perform core workflows without assistance
[ ] CSM confidence score is 4 or higher
[ ] Go-live check-in is complete
[ ] Customer knows how to get ongoing support

---

TROUBLESHOOTING

Customer is unresponsive to scheduling:
- After 48 hours: Follow-up email
- After 72 hours: Escalate to AE
- After 1 week: Escalate to CS Manager

Users are not activating accounts:
- Check spam folders with customer admin
- Resend invitations
- Offer to walk admin through user management

Customer wants to skip training:
- Explain the correlation between training and success
- Offer abbreviated session (30 min)
- If they insist, document in notes and monitor closely post-go-live

Go-live date is delayed by customer:
- Document reason
- Confirm new date
- Adjust check-in schedule accordingly

---

VERSION HISTORY

| Version | Date | Changes | Author |
|---------|------|---------|--------|
| 1.0 | [Date] | Initial version | [Name] |

STANDARD OPERATING PROCEDURE
Process: Customer Refund Request Handling
Version: 1.0
Owner: Customer Support Team

PURPOSE

This SOP guides support agents through evaluating and processing customer refund requests consistently and fairly. It includes decision criteria for standard cases and escalation paths for exceptions.

SCOPE

Applies to all refund requests received through email, chat, or phone for orders placed through our online store.

DECISION FLOWCHART OVERVIEW

```
Refund Request Received
 |
 v
Is it within 30 days of delivery?
 | |
 YES NO --> Is there an exception reason? 
 | | |
 v YES NO --> Deny with explanation
Is item eligible? |
 | | v
 YES NO Escalate to supervisor
 | | |
 v v v
Standard Partial Supervisor decides
refund refund/ (full, partial, credit,
 credit or deny)
```

PROCEDURE

STEP 1: GATHER INFORMATION

1.1 Collect from the customer:
 - Order number
 - Reason for refund request
 - Item condition (if return involved)

1.2 Look up in system:
 - Order date and delivery date
 - Items purchased and prices
 - Customer's order history
 - Any previous refund requests

---

STEP 2: DETERMINE IF REQUEST IS WITHIN POLICY

Check each criterion:

[ ] Time window: Is request within 30 days of delivery date?
 - Delivery date is in order system under "Delivered On"
 - If no delivery confirmation, use ship date + 7 days

[ ] Item eligibility: Is the item category eligible for refund?
 - Eligible: Most items in original condition
 - NOT eligible: Final sale items, personalized items, opened software, intimate apparel

[ ] Condition: Is the item in acceptable condition for return?
 - Acceptable: Unused, with tags, in original packaging
 - Not acceptable: Used, washed, damaged by customer

IF ALL CRITERIA MET: Proceed to Step 4 (Process Standard Refund)

IF ANY CRITERIA NOT MET: Proceed to Step 3 (Evaluate for Exception)

---

STEP 3: EVALUATE FOR EXCEPTION

Not all out-of-policy requests should be denied. Evaluate these factors:

FACTORS THAT SUPPORT EXCEPTION:
- Customer is a high-value customer (5+ orders or $500+ lifetime value)
- Item is defective or not as described (our fault)
- Request is only slightly outside window (within 7 days of limit)
- Customer has no previous refund requests
- Extenuating circumstances (hospitalization, family emergency with documentation)

FACTORS AGAINST EXCEPTION:
- Multiple previous refund requests (check history)
- Request significantly outside window (>45 days)
- Customer has pattern of exception requests
- Item is clearly used or damaged by customer
- Item is final sale (these should rarely have exceptions)

DECISION AUTHORITY:

Agents MAY approve exceptions when:
- Only 1-2 factors against
- Order value under $100
- Customer has no previous exceptions in past 12 months

Agents MUST escalate to supervisor when:
- Order value over $100
- Customer has had previous exception approved
- Agent is unsure
- Customer is threatening or hostile

To escalate: Create ticket in supervisor queue with all gathered information and your recommendation.

---

STEP 4: DETERMINE REFUND TYPE AND PROCESS

STANDARD REFUND (within policy, item returned)
- Process: Full refund to original payment method
- Timeline: Within 3-5 business days of item receipt
- Action: Generate return label, initiate refund upon item receipt

PARTIAL REFUND (item not returned or damaged)
- When: Customer cannot return item (lost, donated, etc.) or item is damaged
- Amount: Typically 50% of item price, adjusted by supervisor if needed
- Action: Process directly, no return required

STORE CREDIT (out of policy exception)
- When: Approved exception but company wants to retain value
- Amount: Full item price as store credit
- Expiration: 12 months
- Action: Issue credit to customer account, email confirmation

DENIAL (not within policy, no exception approved)
- When: Request does not meet criteria and no exception factors apply
- Action: Send denial response using template (link), explain policy, offer alternatives if applicable

---

STEP 5: COMMUNICATE WITH CUSTOMER

For approvals:
- Confirm the refund type and amount
- Explain timeline for processing
- Provide return instructions if applicable
- Thank them for their patience

For denials:
- Explain why the request does not qualify
- Cite specific policy (timeframe, condition, etc.)
- Offer alternatives (store credit, exchange) if applicable
- Provide escalation path (they can ask for supervisor review)

Use response templates in the knowledge base. Personalize the opening and closing.

---

STEP 6: DOCUMENT AND CLOSE

6.1 Log in CRM:
 - Request received date
 - Decision made
 - Reason for decision
 - Exception approved (yes/no)
 - Refund amount

6.2 If refund processed, verify in payment system that transaction is complete.

6.3 Mark ticket resolved.

---

QUICK REFERENCE: DECISION SUMMARY

| Situation | Decision | Authority |
|-----------|----------|------------|
| Within 30 days, item eligible, good condition | Full refund | Agent |
| Within 30 days, item not returned | Partial refund or credit | Agent |
| 31-37 days, good customer history | Exception likely | Agent |
| 31-37 days, poor customer history | Deny or escalate | Agent/Supervisor |
| Over 37 days | Deny or escalate | Supervisor |
| Defective item (any timeframe) | Full refund | Agent |
| Final sale item | Deny (rare exceptions) | Supervisor |

---

ESCALATION CONTACTS

- Supervisor queue: [link]
- Urgent issues during business hours: [supervisor name/contact]
- After hours emergencies: [manager contact]

---

VERSION HISTORY

| Version | Date | Changes | Author |
|---------|------|---------|--------|
| 1.0 | [Date] | Initial version | [Name] |

STANDARD OPERATING PROCEDURE
Process: Production Outage Response
Severity: CRITICAL
Owner: Engineering/Operations Team

WHEN TO USE THIS SOP

Activate this procedure when:
- Monitoring alerts indicate site/application is down or severely degraded
- Multiple customers report inability to access the service
- Internal testing confirms service is unavailable
- Any automated health check fails for more than 5 minutes

This is a time-critical procedure. Speed matters. Follow steps in order but do not wait for perfection.

---

ROLES DURING INCIDENT

Incident Commander (IC): First senior engineer to respond. Owns decisions and coordination.
Communications Lead: Handles all internal and external communications.
Technical Lead: Leads diagnosis and fix. May be same as IC for small teams.

If you are first to respond, you are the IC until someone more senior takes over.

---

PHASE 1: IMMEDIATE RESPONSE (First 15 minutes)

Priority: Stop the bleeding, communicate, gather information.

1. ACKNOWLEDGE THE ALERT
 - Respond in #incidents Slack channel: "Investigating [alert description]"
 - This prevents duplicate responses and starts the clock
 - Time: 1 minute

2. VERIFY THE OUTAGE
 - Check from multiple sources:
 [ ] Status monitoring dashboard
 [ ] Try accessing the site yourself
 [ ] Check customer-facing error messages
 - Determine scope: Full outage? Partial? Which features?
 - Time: 2-3 minutes

3. START INCIDENT CHANNEL
 - Create dedicated Slack channel: #incident-YYYY-MM-DD-brief-description
 - Post initial assessment: What is broken, what is not, who is working on it
 - Time: 2 minutes

4. NOTIFY KEY STAKEHOLDERS
 - Page on-call engineer if not already responding: [PagerDuty link]
 - Notify engineering manager: [contact]
 - Notify customer success (they will manage customer communication): [contact]
 - Time: 2 minutes

5. UPDATE STATUS PAGE
 - Go to [status page admin link]
 - Post: "Investigating - We are aware of issues affecting [description]. We are investigating and will provide updates."
 - Time: 2 minutes

6. BEGIN INITIAL DIAGNOSIS
 - Check recent deployments: Was anything released in the last 24 hours?
 - Check infrastructure: Are servers responding? Database connected?
 - Check third-party services: Are our vendors up? (Check their status pages)
 - Time: 5 minutes

---

PHASE 2: DIAGNOSIS AND FIX (15-60 minutes)

Priority: Find root cause, implement fix, minimize customer impact.

DIAGNOSIS CHECKLIST:

[ ] Recent code deployment
 - If yes and timing matches: Consider immediate rollback (see Rollback Procedure)
 - Rollback is often faster than debugging

[ ] Infrastructure issue
 - Check cloud provider status: [AWS status link], [other providers]
 - Check server health in monitoring dashboard
 - Check database connections and performance

[ ] Third-party service issue
 - Payment processor: [status link]
 - Email service: [status link]
 - CDN: [status link]

[ ] Traffic spike or attack
 - Check traffic levels in monitoring
 - If abnormal, engage CDN/security tools

DECISION POINT: ROLLBACK VS. FIX FORWARD

ROLLBACK if:
- Recent deployment is likely cause
- Fix is not immediately obvious
- Outage has exceeded 15 minutes

FIX FORWARD if:
- Root cause is identified and fix is simple
- Rollback would cause data issues
- Issue is not related to recent deployment

ROLLBACK PROCEDURE:
1. Go to deployment dashboard: [link]
2. Select previous stable version
3. Click "Deploy" - confirm when prompted
4. Typical rollback time: 5-10 minutes
5. Verify site is accessible after rollback completes

COMMUNICATION DURING THIS PHASE:
- Update #incident channel every 15 minutes minimum
- Update status page every 30 minutes or when status changes
- Format: What we know, what we are doing, expected next update time

---

PHASE 3: VERIFICATION AND RECOVERY (After fix deployed)

Priority: Confirm fix worked, stabilize, stand down.

1. VERIFY FIX
 - Test site access from multiple locations/devices
 - Check monitoring dashboards for normal metrics
 - Wait 10 minutes for stability before declaring resolved
 - Time: 10-15 minutes

2. UPDATE STATUS PAGE
 - Change to: "Resolved - The issue affecting [description] has been resolved. Service has returned to normal."
 - Include brief explanation of what happened (keep customer-appropriate)

3. NOTIFY STAKEHOLDERS
 - Message in #incident channel: "Incident resolved. Service restored at [time]."
 - Notify customer success to send all-clear to affected customers
 - Notify leadership with brief summary

4. CLOSE INCIDENT CHANNEL
 - Pin summary message with: Start time, end time, impact, root cause, fix applied
 - Archive channel (do not delete - needed for post-mortem)

---

PHASE 4: POST-MORTEM (Within 48 hours)

Priority: Learn and prevent recurrence.

1. Schedule post-mortem meeting
 - Include: IC, technical responders, affected stakeholders
 - Typical duration: 30-60 minutes

2. Prepare post-mortem document using template: [link]
 - Timeline of events
 - Root cause analysis (5 Whys)
 - What went well
 - What could be improved
 - Action items with owners and due dates

3. Share findings
 - Post summary in #engineering
 - Add action items to project tracker
 - Update this SOP if process improvements identified

---

ESSENTIAL CONTACTS

| Role | Name | Contact | When to Use |
|------|------|---------|-------------|
| On-call engineer | [Rotation] | [PagerDuty] | First response |
| Engineering Manager | [Name] | [Phone/Slack] | All incidents |
| VP Engineering | [Name] | [Phone] | Severe/extended outages |
| Customer Success | [Name] | [Slack] | Customer communication |
| AWS Support | N/A | [Support portal] | AWS issues |
| [Vendor] Support | N/A | [Contact] | [Vendor] issues |

---

QUICK REFERENCE: FIRST 5 MINUTES

1. Acknowledge in #incidents
2. Verify outage is real
3. Create #incident channel
4. Page on-call if needed
5. Update status page
6. Start diagnosis

When in doubt: Communicate, escalate, and rollback.

---

VERSION HISTORY

| Version | Date | Changes | Author |
|---------|------|---------|--------|
| 1.0 | [Date] | Initial version | [Name] |

STANDARD OPERATING PROCEDURE
Process: New Support Agent Training Program
Duration: 2 weeks
Owner: Support Team Lead

PURPOSE

This SOP ensures all new support agents receive consistent, full training before handling customer inquiries independently. Proper training reduces errors, improves customer satisfaction, and shortens time to productivity.

PREREQUISITES

Before starting this program, new hires must have:
[ ] Completed HR onboarding (first day paperwork, systems access)
[ ] Received login credentials for: Support platform, Knowledge base, Internal chat
[ ] Reviewed the Employee Handbook
[ ] Been introduced to their mentor (assigned by Team Lead)

LEARNING OBJECTIVES

By the end of training, the agent will be able to:
1. Handle all support tools confidently
2. Handle common inquiry types (password resets, billing questions, how-to questions) independently
3. Identify when to escalate and escalate correctly
4. Meet quality standards (response time, customer satisfaction, accuracy)
5. Find answers in the knowledge base efficiently

---

WEEK 1: FOUNDATION

DAY 1: ORIENTATION AND TOOLS

Morning (9:00-12:00)
- Welcome and team introductions (30 min)
- Support team overview: mission, metrics, typical day (30 min)
- Tour of support tools: ticketing system, knowledge base, internal resources (90 min)

Afternoon (1:00-5:00)
- Hands-on: Create practice tickets, handle knowledge base (2 hours)
- Product overview: What we sell, who our customers are (1 hour)
- Homework assignment: Read top 20 KB articles, come with questions

Trainer checklist:
[ ] Systems access verified
[ ] Practice environment set up
[ ] Mentor introduction scheduled for Day 2

DAY 2: PRODUCT DEEP DIVE

Morning (9:00-12:00)
- Product demo: Core features and common use cases (90 min)
- Q&A on homework reading (30 min)
- Mentor meeting: Relationship building, expectations (30 min)

Afternoon (1:00-5:00)
- Hands-on: Use the product as a customer would (2 hours)
- Common issues walkthrough: Top 10 support requests and how to handle them (2 hours)

Trainer checklist:
[ ] Trainee has working product login
[ ] Top 10 issues document provided

DAY 3: INQUIRY HANDLING BASICS

Morning (9:00-12:00)
- Communication standards: Tone, templates, personalization (1 hour)
- Ticket lifecycle: Receive, respond, resolve, close (1 hour)
- Practice: Write responses to sample inquiries (1 hour)

Afternoon (1:00-5:00)
- Shadow mentor handling live tickets (3 hours)
- Debrief: Discuss observations, ask questions (1 hour)

Trainer checklist:
[ ] Sample inquiry packet provided
[ ] Shadowing schedule confirmed with mentor

DAY 4: ESCALATION AND EDGE CASES

Morning (9:00-12:00)
- When and how to escalate: Decision criteria, process (1 hour)
- Handling difficult customers: De-escalation techniques (1 hour)
- Practice: Role-play difficult scenarios (1 hour)

Afternoon (1:00-5:00)
- Shadow mentor: Focus on observing escalations and complex cases (2 hours)
- Knowledge base navigation challenge: Find answers to 10 questions (2 hours)

Trainer checklist:
[ ] Escalation flowchart provided
[ ] Role-play scenarios prepared

DAY 5: WEEK 1 ASSESSMENT

Morning (9:00-12:00)
- Product knowledge quiz (1 hour) - must score 80%+
- Tool proficiency check: Complete standard tasks while trainer observes (1 hour)
- Review quiz results and address gaps (1 hour)

Afternoon (1:00-5:00)
- Mock ticket handling: Handle 5 simulated tickets independently (2 hours)
- Feedback session: Review mock ticket performance (1 hour)
- Week 2 preview and questions (1 hour)

Trainer checklist:
[ ] Quiz graded same day
[ ] Mock tickets prepared
[ ] Week 1 progress documented

WEEK 1 EXIT CRITERIA:
- Quiz score 80% or above
- Mock tickets rated satisfactory by trainer
- No major gaps identified

If criteria not met: Extend Week 1 activities, provide additional support, reassess on Day 7.

---

WEEK 2: SUPERVISED PRACTICE

DAY 6-7: ASSISTED LIVE HANDLING

- Trainee handles live tickets with mentor sitting alongside
- Mentor reviews every response before sending
- Target: 10-15 tickets per day
- End of each day: 30-minute debrief with mentor

Trainer checklist:
[ ] Trainee queue set up (easy tickets only)
[ ] Mentor availability confirmed

DAY 8-9: MONITORED INDEPENDENT HANDLING

- Trainee handles live tickets independently
- Mentor reviews all closed tickets same-day
- Target: 15-20 tickets per day
- Immediate feedback on any errors

Trainer checklist:
[ ] Queue expanded to include medium-complexity tickets
[ ] Daily review process confirmed with mentor

DAY 10: FINAL ASSESSMENT

Morning (9:00-12:00)
- Handle tickets normally (trainee does not know this is assessment)
- Trainer reviews all tickets from morning session

Afternoon (1:00-5:00)
- Assessment review: Go through tickets, provide feedback (1 hour)
- Final quiz: Advanced scenarios (1 hour)
- Graduation meeting: Confirm readiness or extend training (30 min)
- If passing: Add to full rotation, remove training queue restrictions

GRADUATION CRITERIA:
[ ] Week 2 ticket quality meets team standards (>90% accuracy)
[ ] No critical errors (wrong information, inappropriate tone)
[ ] Response time within guidelines
[ ] Final quiz score 85%+
[ ] Mentor recommendation

IF CRITERIA NOT MET:
- Extend training 3-5 days
- Focus on specific gap areas
- Reassess with manager involvement
- If not ready after extension, escalate to HR for performance discussion

---

POST-TRAINING SUPPORT

Weeks 3-4:
- Mentor check-ins: 15 minutes daily
- Trainer check-in: 30 minutes twice per week
- Quality review: Team Lead reviews sample tickets weekly

Weeks 5-8:
- Mentor check-ins: 15 minutes twice per week
- Quality review continues

After 8 weeks: Transition to standard performance management.

---

TRAINING MATERIALS CHECKLIST

Before training begins, confirm:
[ ] Training environment access
[ ] Practice ticket queue created
[ ] All handouts printed/shared
[ ] Quiz and assessment materials ready
[ ] Mentor briefed and scheduled
[ ] Knowledge base access verified

Materials location: [shared drive link]

---

VERSION HISTORY

| Version | Date | Changes | Author |
|---------|------|---------|--------|
| 1.0 | [Date] | Initial version | [Name] |