How Lyft Uses Claude for Customer Support

1. The customer support challenge in ride-sharing

Lyft operates at a scale that makes traditional customer support economics collapse. Millions of rides complete — and sometimes don’t complete — every single day. Each one is a potential support ticket. A driver doesn’t arrive. A rider is charged twice. A phone slides off the back seat of a Toyota Camry somewhere in the Mission District. A login stops working. Multiply those failure modes by millions of daily rides and you get a support volume that no human team can absorb without structurally changing how the work gets done.

The old model — every ticket joins a human queue — breaks under that volume. Wait times grow. The queue becomes a bottleneck for riders who have a simple question and a bottleneck for riders who have a genuinely complex problem. Agents handling their fiftieth lost-item report of the shift are burning their capacity on pattern-matching that a well-designed system could handle automatically. The agents who most want to help with difficult cases — safety incidents, multi-issue disputes, high-emotion situations — are occupied with routine volume instead. Everyone suffers: riders, agents, and the business.

Lyft’s bet with Claude is that you can restructure this economics without sacrificing the quality of the human touch. The argument is not “replace human agents with AI.” It is something more precise: have AI handle the cases that don’t need a human, and free human agents to do the work that only humans can do well. The productivity gain on the AI side pays for richer, more careful human attention on the hard cases.

2. What counts as “routine” in ride-sharing support

The word “routine” is doing a lot of work here, so it is worth being precise. A routine support case is one that follows a predictable pattern with a clear resolution path that doesn’t require human judgment. In ride-sharing, this covers a surprisingly large fraction of total ticket volume.

Charge disputes under a given dollar threshold are a canonical example. If a rider is charged for a ride they believe they didn’t take, or charged an amount that doesn’t match what they expected, and the disputed amount is below a business-defined threshold, the resolution path is well-defined: look up the ride, check GPS logs, verify the charge, apply the refund or explain the charge. No judgment call is required. The same is true for standard lost-item reports — the pattern is: rider reports lost item, driver is contacted, outcome is communicated, follow-up is scheduled if needed. For “my driver didn’t show” refund requests, the ride data either supports the claim or it doesn’t. App login issues have a fixed troubleshooting tree.

What makes a case non-routine is worth noting too. Safety incidents — any situation where a rider felt unsafe or threatened — are never routine. High-value customers who represent significant lifetime revenue warrant additional care. Tickets that contain multiple issues tangled together require judgment about priority and sequencing that AI handles poorly. And any time a customer explicitly asks to speak with a person, the right answer is to honor that request immediately. The AI system that insists on trying to resolve when a human has been requested damages trust badly enough to negate the efficiency gains.

3. The routing architecture: how Claude processes a support ticket

Lyft’s AI assistant uses Claude as the intelligence layer inside a structured pipeline. When a support ticket arrives, it doesn’t go directly to an agent queue or directly to Claude — it enters a multi-stage process designed to get the right outcome with the minimum friction.

The first stage is intake and classification. Claude reads the ticket text, identifies the issue type (charge dispute, lost item, login problem, and so on), and assigns a confidence level to the classification. High-confidence classifications of routine issue types proceed to the next stage automatically. Low-confidence classifications, or classifications that fall into a non-routine category, route immediately to a human agent with a pre-populated context summary.

The second stage is context retrieval. For a classified ticket, Claude queries the relevant customer data: ride history for the incident date, payment records, previous support interactions, account standing. This retrieval is automated and structured — Claude isn’t browsing; it’s querying specific data based on the issue type it identified. A charge dispute retrieval looks different from a lost-item retrieval.

The third stage is resolution or routing. With the ticket classified and context retrieved, Claude either resolves the issue directly (applying a refund, updating account status, sending a follow-up message to the driver) or prepares a handoff package for a human agent. The handoff package is the part that experienced support designers care most about: it’s a structured summary of the issue, the customer history, what the AI tried and why it escalated, and what the human agent should focus on. The human doesn’t start from scratch — they start from a complete picture.

4. Maintaining empathy at scale

This is the design challenge that most technical teams underestimate. A rider who waited 20 minutes in the rain for a driver who never arrived is not experiencing a charge dispute — they are experiencing frustration, possibly anger, and a breach of trust. The operational resolution (issue a refund) is table stakes. What matters for the relationship is whether the interaction acknowledges the experience before jumping to the resolution.

Designing Claude to lead with empathy requires intentional prompting. The system prompt needs to explicitly specify that the AI should acknowledge the emotional context of the complaint — not in a formulaic “we’re sorry for the inconvenience” way that riders recognize as a template, but in a way that reflects the specific situation. A rider who reports being left stranded gets a different acknowledgment than a rider who received an unexpected charge. The specificity of the acknowledgment is what distinguishes genuine care from scripted deflection.

The practical prompt engineering principle here is sequencing: acknowledge first, then resolve. Before Claude explains the refund or asks for additional information, it should reflect back what happened in a way that makes the rider feel heard. This is not a soft goal. Research on customer satisfaction consistently finds that feeling heard is a stronger predictor of satisfaction than outcome — riders who receive a full refund but feel dismissed are less satisfied than riders who receive a partial refund but feel genuinely acknowledged.

5. Escalation logic: the critical design decision

The escalation criteria — when does AI hand off to a human — are the most consequential design decision in the entire system. Get this wrong in either direction and the system fails. Too aggressive: AI tries to handle cases it can’t handle well, riders feel dismissed, trust erodes. Too conservative: AI escalates everything, defeating the purpose of the investment.

Lyft’s likely escalation logic follows several principles. First, confidence threshold: if Claude’s classification confidence is below a threshold, escalate. It is better to waste a human agent’s time on a case that was actually routine than to have AI bungle a case that needed a human. Second, issue type: safety incidents, accessibility concerns, and any complaint that includes words signaling extreme distress route to a human immediately, regardless of classification confidence. Third, customer value: high-value customers or customers with a history of significant issues receive human attention. Fourth, explicit request: any time the rider asks for a human, the system transfers immediately. Fifth, AI failure detection: if Claude’s first response doesn’t resolve the issue and the rider expresses continued dissatisfaction, the case escalates.

The handoff design matters as much as the decision to escalate. When a human agent receives an escalated ticket, they should see: the original ticket text, the issue classification and confidence score, the customer history Claude retrieved, what resolution Claude attempted (if any) and the rider’s response to it, and a one-paragraph summary of what the human agent should focus on. This handoff package turns an escalated ticket from a cold start into a warm start — the human agent can focus their expertise on the parts that actually needed it.

6. The business case for AI-assisted support

The business argument for AI-assisted support runs across four dimensions, and Lyft’s implementation illustrates each of them. Speed is the most obvious: routine issues that previously waited in a human queue are now resolved in seconds. For a rider who just wants to know why they were charged $3.50 more than expected, seconds versus twenty minutes is the difference between friction and a good experience.

Cost is the second dimension. Human support scales linearly with volume — ten times the tickets requires roughly ten times the agents. AI support scales much more favorably. The cost per ticket for routine AI-resolved cases is a fraction of the cost per ticket for human-resolved cases, and the ratio of AI-to-human tickets is increasingly favorable as the classification system improves. This isn’t about laying off agents — the volume growth in ride-sharing would outpace even aggressive headcount growth. AI absorbs the volume growth; human headcount focuses on quality.

The third dimension is quality consistency. Human agents have good days and bad days. They fatigue. They handle their fiftieth lost-item report differently than their first. AI doesn’t. For the routine cases where the resolution path is clear and the main variable is execution quality, AI consistently applies the same process. This isn’t better than a great human agent at their best — it’s better than a fatigued human agent at the end of a long shift.

The fourth dimension is agent experience, which is underrated. Being an AI-assisted support agent at Lyft is a qualitatively different job than being a traditional support agent. Instead of handling hundreds of routine tickets per shift, human agents handle the cases that actually require judgment, empathy, and expertise. The work is harder and more varied. Turnover in support roles is historically high because the work is monotonous — AI assistance directly attacks that problem by removing the monotonous volume and leaving the meaningful work.

SUPPORT_SYSTEM_PROMPT = """
You are a customer support assistant for a ride-sharing service.

When handling a support request:
1. FIRST, acknowledge the rider's experience in 1-2 sentences specific to their situation.
   Do not use generic phrases like "we're sorry for the inconvenience."
   Reference what actually happened: "Being left waiting in the rain for 20 minutes
   is genuinely frustrating, and I want to make this right."

2. THEN, explain what you're going to do or what happened.

3. Apply the relevant resolution (refund, driver contact, account update).

4. If you cannot confidently resolve the issue, or if the issue involves safety,
   say: "I'm connecting you with a support specialist who can help with this directly."

Always be direct. Do not pad responses with filler. Be specific about the situation.
"""

import anthropic

client = anthropic.Anthropic()

def classify_ticket(ticket_text: str) -> dict:
    response = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=200,
        system="""Classify this support ticket into one category and confidence level.

Categories: charge_dispute, lost_item, driver_no_show, login_issue, safety_incident, other

Return JSON only: {"category": "...", "confidence": 0.0-1.0, "escalate": true/false}

Always set escalate=true for: safety_incident, confidence < 0.7, or "other" category.""",
        messages=[{"role": "user", "content": ticket_text}]
    )
    import json
    return json.loads(response.content[0].text)

def retrieve_customer_context(customer_id: str, category: str) -> dict:
    mock_customers = {
        "rider_123": {
            "name": "Alex",
            "account_standing": "good",
            "rides_last_30_days": 12,
            "recent_charge": 24.50,
            "previous_support_tickets": 1,
        }
    }
    return mock_customers.get(customer_id, {})

def handle_ticket(ticket_text: str, customer_id: str) -> dict:
    classification = classify_ticket(ticket_text)
    context = retrieve_customer_context(customer_id, classification["category"])

    if classification["escalate"]:
        summary = generate_handoff_summary(ticket_text, classification, context)
        return {"action": "escalate", "human_summary": summary}

    resolution = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=400,
        system=SUPPORT_SYSTEM_PROMPT,
        messages=[{
            "role": "user",
            "content": f"Ticket: {ticket_text}\n\nCustomer context: {context}"
        }]
    )
    return {"action": "resolve", "response": resolution.content[0].text}

def generate_handoff_summary(ticket: str, classification: dict, context: dict) -> str:
    summary = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=200,
        system="Write a brief handoff summary for a human support agent. Include: issue type, customer standing, what the AI attempted, and what to focus on.",
        messages=[{
            "role": "user",
            "content": f"Ticket: {ticket}\nClassification: {classification}\nContext: {context}"
        }]
    )
    return summary.content[0].text