Status Model in Law Firm Intake: 2 Variants + SLAs (Copy/Paste)

Why Status Models Matter

Every inquiry that enters your firm exists in a state. New. Being reviewed. Waiting on client. Approved. Declined. Converted.

Without a defined status model, inquiries live in email threads and mental notes. Nobody knows what stage each inquiry is in. Things fall through cracks.

With a status model, every inquiry has a visible state. You know exactly where each one stands, who is responsible, and what happens next.

The Two Fundamental Approaches

Variant 1: Linear Status Model

Inquiries move through stages in sequence. Each stage has one exit path to the next stage (with the exception of rejection/withdrawal at any point).

New → In Review → Qualified → Consultation Scheduled → Converted/Declined

Best for:

• Simple intake processes
• Low volume (under 50/month)
• Single practice area
• Small teams (1-3 people handling intake)

Advantages:

• Easy to understand
• Simple to implement
• Clear accountability
• Easy to measure conversion

Limitations:

• Cannot handle branching logic
• No parallel processes
• Limited flexibility for complex cases

Variant 2: Branching Status Model

Inquiries can move through multiple paths depending on conditions. Stages can run in parallel.

New → Initial Review
        ↓
    ┌───┴───┐
    ↓       ↓
  Fast Track   Standard Track
    ↓           ↓
  Consult    Conflict Check → Qualified → Consult
    ↓           ↓
  Convert    Assign Attorney → Convert

Best for:

• Complex intake processes
• High volume (50+ per month)
• Multiple practice areas
• Larger teams with specialization

Advantages:

• Handles complexity
• Parallel processing possible
• Different tracks for different case types
• More accurate representation of reality

Limitations:

• Harder to understand
• More complex to implement
• Requires better tooling
• Can obscure accountability if poorly designed

Designing Your Status Model

Step 1: Map Current Reality

Before designing the ideal model, document what actually happens today.

Questions to answer:

• What is the first thing that happens when an inquiry arrives?
• Who looks at it first?
• What decisions are made and by whom?
• What information is gathered at each step?
• How does an inquiry become a client?
• How does an inquiry get rejected?
• What can cause delays?

Step 2: Define Status Requirements

Each status in your model should answer:

Entry criteria: What must be true for an inquiry to enter this status?

Exit criteria: What must happen to leave this status?

Owner: Who is responsible while inquiry is in this status?

SLA: How long should an inquiry stay in this status?

Actions: What work happens in this status?

Step 3: Choose Variant

Choose Linear if:

• Your process has fewer than 7 meaningful stages
• Most inquiries follow the same path
• You want maximum simplicity
• You are just starting with formalized intake

Choose Branching if:

• Different inquiry types need different handling
• You have parallel activities (e.g., conflict check while gathering info)
• Multiple team members handle different stages
• You need sophisticated routing

Step 4: Define Statuses

Minimum viable status set:

SLAs: The Enforcement Mechanism

Why SLAs Matter

Status without SLA is status without accountability. "In Review" for 6 weeks is not a status - it is a black hole.

SLAs create:

• Visibility into delays
• Accountability for owners
• Data for process improvement
• Client experience standards

Setting Appropriate SLAs

Consider:

• Client expectations (how fast do they expect response?)
• Competitive pressure (how fast do competitors respond?)
• Resource constraints (what can your team actually achieve?)
• Case complexity (simple vs. complex inquiries)

Starting point recommendations:

SLA Escalation

Define what happens when SLA is breached:

Level 1 (Warning): 75% of SLA elapsed

• Notification to owner
• Status highlighted in dashboard

Level 2 (Breach): 100% of SLA elapsed

• Notification to owner and supervisor
• Automatic escalation option
• Inquiry flagged as overdue

Level 3 (Critical): 150% of SLA elapsed

• Notification to management
• Required action documented
• Included in performance metrics

Automation Integration

Status-Triggered Automations

Each status transition can trigger automated actions:

New → In Review

• Send acknowledgment email to prospect
• Create task for reviewer
• Start SLA timer

Qualified → Consultation Scheduled

• Send calendar invite
• Send preparation materials
• Create reminder sequence

Post-Consultation → Declined

• Send polite decline email
• Add to "future contact" list (if appropriate)
• Update marketing attribution

Post-Consultation → Converted

• Create matter in practice management system
• Generate engagement letter
• Notify relevant team members
• Stop marketing sequences

Status-Based Routing

Automations can change status based on conditions:

Auto-qualification rules:

• If practice area = Employment AND inquiry type = Termination AND company size > 50 → Auto-qualify, route to Employment Group

Auto-rejection rules:

• If practice area not in [list of areas we handle] → Auto-decline with referral
• If geographic location outside service area → Auto-decline with explanation

Priority routing:

• If referred by existing client → Mark high priority, expedite SLA
• If revenue potential > threshold → Route to senior attorney

Measuring Status Model Performance

Key Metrics

Conversion funnel:

• New → Qualified rate
• Qualified → Consultation rate
• Consultation → Converted rate
• Overall: New → Converted rate

Time metrics:

• Average time in each status
• Total time: New → Converted
• SLA compliance rate by status

Volume metrics:

• Inquiries per status (current)
• Inquiries per status (over time)
• Throughput per team member

Dashboard Design

Essential views:

Current state: How many inquiries in each status right now?

Aging: Which inquiries are approaching or past SLA?

Funnel: Conversion rates between stages over selected period

Trends: Volume and conversion trends over time

Red Flags to Watch

Bottlenecks: Status with consistently high volume suggests capacity problem

Low conversion at specific stage: Indicates process or qualification issue

High variability in time-to-convert: Suggests inconsistent handling

SLA breaches concentrated with specific owner: Training or capacity issue

Common Status Model Mistakes

Mistake 1: Too Many Statuses

Every status added is complexity added. If you have 15 statuses and half are rarely used, simplify.

Test: Can you explain your entire status model in under 2 minutes?

Mistake 2: Unclear Ownership

"Someone needs to look at this" is not ownership. Every status needs exactly one responsible role or person.

Mistake 3: No Exit Criteria

Status without exit criteria becomes a waiting room. Define specifically what must happen to advance.

Mistake 4: Missing SLAs

"We review things quickly" is not an SLA. Define specific time expectations and measure against them.

Mistake 5: No Declined/Withdrawn Path

Not every inquiry becomes a client. Model the rejection path explicitly. Track why inquiries do not convert.

Mistake 6: Static Model

Your status model should evolve. Review quarterly. Add statuses that reflect actual work. Remove statuses that are never used.

Implementation Checklist

Week 1: Discovery

• Interview team members about current process
• Document actual status flow (not ideal, actual)
• Identify pain points and bottlenecks
• Count volume by stage

Week 2: Design

• Choose variant (linear or branching)
• Define statuses with entry/exit criteria
• Assign owners to each status
• Set SLAs for each status

Week 3: Build

• Configure statuses in your system
• Set up SLA tracking
• Create automation triggers
• Build dashboard

Week 4: Launch

• Train team on new model
• Run parallel with old process for 1 week
• Monitor for issues
• Gather feedback

Month 2: Optimize

• Review conversion metrics
• Identify bottlenecks
• Adjust SLAs based on data
• Refine automations

Next Step

Start simple:

1. Define 5-7 statuses that reflect your actual process
2. Assign an owner to each
3. Set initial SLAs (you can adjust later)
4. Track for 30 days
5. Optimize based on data

The goal is not a perfect model. The goal is visibility into where every inquiry stands.

Guide: Client Intake Automation

Related:
Routing Rules vs. AI Screening