# Process Design Framework

This reference file provides a structured framework for documenting core business processes. It guides users through defining three universal processes — customer onboarding, customer support, and fulfillment/delivery — with business-model-specific variations.

**Output path:** When the skill generates process documentation, write the result to `devforgeai/specs/business/operations/core-processes.md`.

## Table of Contents

1. [Business Model Types](#business-model-types)
2. [Core Processes](#core-processes)
3. [Process Templates](#process-templates)
4. [Five-Field Process Template](#five-field-process-template)
5. [Output Format](#output-format)
6. [Tool Stack Integration](#tool-stack-integration)
7. [Edge Cases](#edge-cases)
8. [Incremental Saves](#incremental-saves)
9. [Usage](#usage)

---

## Business Model Types {#business-model-types}

The framework supports four business model types. Each process template includes model-specific steps that are conditionally included based on the user's business model.

- **SaaS** — Software as a Service with subscription billing, trial-to-paid conversion, and digital service delivery
- **Marketplace** — Two-sided platform connecting sellers and buyers with commission-based revenue
- **Service** — Client engagement model with scoping, proposals, and deliverable-based fulfillment
- **Product** — Physical or digital products with inventory, order-to-ship, or instant delivery workflows

When no business model is specified, **default to the service model** as the fallback option. The service model provides the most flexible framework applicable across consulting, freelancing, and agency work.

---

## Core Processes {#core-processes}

The framework covers three universal business processes that apply across all business models:

1. **Customer Onboarding** — Converting prospects into active users/customers
2. **Customer Support** — Resolving issues and maintaining customer satisfaction
3. **Fulfillment/Delivery** — Delivering value to customers (orders, service delivery, access provisioning)

Each process has model-specific steps documented below.

### Model Variant Structure

All process variants follow a consistent five-field structure for easy navigation and parsing:

| Field | Description |
|-------|-------------|
| **Trigger** | The event that initiates this process variant |
| **Steps** | Numbered sequential actions (1, 2, 3...) |
| **Owner** | Role or person responsible for the outcome |
| **Success Criteria** | Measurable outcome indicating completion |
| **Flow Summary** | Auto-generated arrow format (Trigger → Step1 → Step2...) |

---

## Process Template: Customer Onboarding {#process-template-customer-onboarding}

### SaaS Model Variant

**Trigger:** User signs up for trial or paid subscription

**Steps:**
1. Send welcome email with account confirmation link
2. Guide user through initial setup wizard
3. Prompt for trial-to-paid conversion before trial expires
4. Track activation milestones (first core action, first value achieved)

**Owner:** Customer Success or Product Lead

**Success Criteria:** User completes setup wizard and performs first core action within 24 hours

**Flow Summary:** Signup → Welcome → Setup → Activation → Trial Conversion

---

### Marketplace Model Variant

**Trigger:** Seller registers or buyer joins marketplace

**Steps:**
1. Verify identity (seller) or preferences (buyer)
2. Complete profile setup with listing/buying preferences
3. Connect payment method for transactions
4. Match with first opportunity (listing to buyer or buyer to seller)

**Owner:** Operations Manager

**Success Criteria:** Both seller and buyer complete first transaction within 7 days

**Flow Summary:** Registration → Verification → Profile → Payment → First Match

---

### Service Model Variant

**Trigger:** Prospect requests consultation or service quote

**Steps:**
1. Schedule discovery call to understand needs
2. Prepare and send proposal with scope and pricing
3. Contract signing and deposit collection
4. Project kickoff with deliverable timeline

**Owner:** Business Owner or Account Manager

**Success Criteria:** Contract signed and kickoff call scheduled within 14 days of initial contact

**Flow Summary:** Discovery → Scoping → Proposal → Contract → Kickoff

---

### Product Model Variant (Physical)

**Trigger:** Customer places first order

**Steps:**
1. Send order confirmation with tracking information
2. Provide unboxing instructions or getting started guide
3. Request product review after delivery confirmation
4. Add to customer email nurture sequence for cross-sell

**Owner:** Fulfillment Manager

**Success Criteria:** Product delivered and customer confirms receipt within expected shipping window

**Flow Summary:** Order → Confirm → Ship → Deliver → Review

---

### Product Model Variant (Digital)

**Trigger:** Customer completes purchase

**Steps:**
1. Instant delivery of download link or access credentials
2. Send getting started email with usage tips
3. Provide tutorial content or onboarding video
4. Request review after 7 days

**Owner:** Automated System

**Success Criteria:** Customer accesses digital product within 1 hour of purchase

**Flow Summary:** Purchase → Instant Access → Onboarding → Usage → Review

---

## Process Template: Customer Support {#process-template-customer-support}

### Universal Steps (All Models)

**Trigger:** Customer submits support request or reports issue

**Steps:**
1. Acknowledge receipt of support request within response time target
2. Triage and categorize issue (critical, high, medium, low)
3. Route to appropriate specialist or escalate
4. Resolve issue or provide workaround
5. Confirm resolution with customer and close ticket

**Owner:** Support Lead or Customer Success Manager

**Success Criteria:** Issue resolved within SLA target based on severity level

**Flow Summary:** Request → Acknowledge → Triage → Route → Resolve → Close

---

## Process Template: Fulfillment/Delivery {#process-template-fulfillmentdelivery}

### SaaS Model Variant

**Trigger:** Subscription activated or new feature provisioned

**Steps:**
1. Provision account access and configure user permissions
2. Enable features based on subscription tier
3. Send onboarding email with getting started resources
4. Monitor usage and offer assistance for first value milestone

**Owner:** Technical Operations or Customer Success

**Success Criteria:** User accesses core feature within 4 hours of subscription

**Flow Summary:** Provision → Configure → Onboard → Monitor

---

### Marketplace Model Variant

**Trigger:** Buyer purchases from seller

**Steps:**
1. Confirm transaction and notify both parties
2. Hold payment in escrow until delivery confirmation
3. Facilitate delivery or digital transfer
4. Release payment to seller upon buyer confirmation
5. Collect and process platform commission

**Owner:** Platform Operations

**Success Criteria:** Buyer confirms receipt and seller receives payment within settlement window

**Flow Summary:** Purchase → Escrow → Deliver → Confirm → Release → Commission

---

### Service Model Variant

**Trigger:** Project kickoffs after contract signed

**Steps:**
1. Conduct kickoff meeting to align on deliverables
2. Execute project work according to timeline
3. Submit draft deliverable for client review
4. Incorporate feedback and finalize
5. Deliver final output and invoice

**Owner:** Service Delivery Lead

**Success Criteria:** Client accepts final deliverable and project moves to maintenance phase

**Flow Summary:** Kickoff → Execute → Draft → Revise → Finalize → Invoice

---

### Product Model Variant (Physical)

**Trigger:** Order received and payment confirmed

**Steps:**
1. Pick items from inventory and pack for shipping
2. Generate shipping label and arrange carrier pickup
3. Send tracking number to customer
4. Monitor delivery status
5. Handle returns or exchanges if needed

**Owner:** Fulfillment Coordinator

**Success Criteria:** Package shipped within 24 hours and delivered within shipping estimate

**Flow Summary:** Pick → Pack → Ship → Track → Deliver

---

### Product Model Variant (Digital)

**Trigger:** Payment processed successfully

**Steps:**
1. Generate one-time download link or access token
2. Send delivery email with link and instructions
3. Expire link after specified period (e.g., 30 days)
4. Replenish link if customer requests

**Owner:** Automated System

**Success Criteria:** Delivery email sent within 5 minutes and link works on first click

**Flow Summary:** Payment → Generate → Send → Access

---

## Five-Field Process Template {#five-field-process-template}

When defining a new process (either from the core processes above or a custom process), collect the following five fields **in sequence** from the user:

### Process Name

The descriptive name of the process. Use clear, action-oriented naming.

**Examples:** "Customer Onboarding", "Order Fulfillment", "Bug Triage"

---

### Trigger

The event or condition that initiates this process. When does this process start?

**Examples:** "User signs up for trial", "Customer submits support ticket", "Inventory falls below reorder point"

---

### Steps

The sequential actions that make up the process. Number each step. These steps will be **auto-generated into a flow summary line**.

**Format:** Use numbered list (1., 2., 3.) for clear sequence.

**Example:**
1. Send welcome email
2. Schedule kickoff call
3. Conduct discovery meeting
4. Deliver proposal

---

### Owner

The role or person responsible for this process. Who owns the outcome?

**Examples:** "Customer Success Manager", "Fulfillment Team", "Automated System"

---

### Success Criteria

The measurable outcome that indicates the process completed successfully. How do we know it worked?

**Examples:** "User completes setup within 24 hours", "Ticket resolved within SLA", "Product delivered within shipping window"

---

## Output Format {#output-format}

When process definitions are complete, write the output to `devforgeai/specs/business/operations/core-processes.md` using the following format:

### H2 Section for Each Process

Use H2 (##) headings for each process name:

```markdown
## Customer Onboarding

### Trigger
User signs up for trial or paid subscription

### Steps
1. Send welcome email with account confirmation link
2. Guide user through initial setup wizard
3. Track activation milestones

### Owner
Customer Success Manager

### Success Criteria
User completes setup wizard within 24 hours

**Flow Summary:** Signup → Welcome → Setup → Activation
```

### Flow Summary Line

The flow summary is **auto-generated** from the numbered steps. Extract key verbs from each step to create the summary in arrow format.

**Format:** `**Flow Summary:** Step1 → Step2 → Step3 → Step4`

---

### Add/Update Mode

If `devforgeai/specs/business/operations/core-processes.md` already exists, the framework operates in add/update mode:

- Read the existing file
- Append new process definitions to the end
- Update existing process definitions if the user specifies changes
- Preserve all existing content unless explicitly replaced

---

## Tool Stack Integration {#tool-stack-integration}

When a user defines a process step that involves a tool or system, the framework cross-references `devforgeai/specs/business/operations/tool-stack.md` (if it exists) to auto-suggest the user's selected tools.

### Tool Step Identification

Steps involving tools often include keywords like:
- "using [tool]"
- "via [system]"
- "with [platform]"
- "in [app]"

### Cross-Reference Behavior

**If tool-stack.md exists:**
- Read the file to find tools selected by the user
- Auto-suggest the relevant tool for steps in that category
- Example: If user selected "Linear for project management", suggest "Create task in Linear" for project-related steps

**If tool-stack.md is absent:**
- Proceed gracefully without tool suggestions
- Do not halt or error
- Mark the step for manual tool specification

### Advisory (Not Required)

Tool suggestions are **advisory only**, not required. The user may accept, modify, or reject the suggested tool. This is a BR-001 business rule — tool stack integration is optional guidance, not a mandate.

---

## Edge Cases {#edge-cases}

### Default to Service Model

The service model is the default fallback when no business model is specified (as stated in the [Business Model Types](#business-model-types) section above). This provides the most flexible framework applicable across consulting, freelancing, and agency work.

---

### Short Process Flagging

If a process is defined with only 1-2 steps, **flag for user review**. A process with minimal steps may indicate:
- Incomplete process definition
- Steps that should be broken down further
- An oversimplified workflow

**Prompt:** "This process has only [N] steps. Consider whether additional steps are needed for complete coverage. Add more steps or proceed?"

---

### Digital Product Fulfillment

For digital products (software, downloads, courses, templates), use the **Product Model Variant (Digital)** template defined in the [Fulfillment/Delivery](#process-template-fulfillmentdelivery) section above. Digital fulfillment characteristics:
- No physical shipping steps
- Immediate or automated delivery
- Download link or access credential generation
- Shorter success criteria windows (minutes/hours vs. days)

---

## Incremental Saves {#incremental-saves}

**BR-002:** Processes are saved incrementally to preserve work during session interruptions.

### Save Behavior

- Write to `devforgeai/specs/business/operations/core-processes.md` **after each process definition completes**
- Do NOT wait until all processes are defined to save
- Each process is immediately appended to the output file

### Session Interruption Handling

If a session is interrupted (crash, timeout, user exit):
- All completed processes are preserved in the output file
- When resuming, read the existing file to identify completed processes
- Offer to continue with remaining undefined processes
- Avoid duplicating already-defined processes

### Immediate Write Guarantee

The file write happens **after each process**, not only at the end. This ensures that even if only 1 of 3 processes is defined, that work is preserved and available immediately.

---

## Usage {#usage}

This framework is used by the operating-business skill when a user selects "Process Design" from the operations menu. The skill loads this reference file and guides the user through:

1. Business model selection
2. Process definition (onboarding, support, fulfillment)
3. Five-field template completion for each process
4. Tool stack integration (if available)
5. Output generation with incremental saves

**Reference:** `src/claude/skills/operating-business/SKILL.md` (Sub-Skill Menu, Option 3)
