It Started With a Conversation: The Birth of My First AI Customer Service Demo

1. The Starting Point: Not a Startup — a “Trial Project”

Lately I’ve been working on some AI-related small projects, but there’s one thing I’m very clear about:

Without a real-world scenario, all AI is hollow.

So I didn’t start by writing systems, building frameworks, or designing architecture. I did something more important first:

👉 Find someone in a real business. Ask them what they actually do every day.

The opportunity happened to be right next to me — a friend I’ve known since childhood. His dad runs a company in the telecom customer service space.

I didn’t go in talking about “how amazing AI is.” I didn’t say “I want to start a business.” I just asked, very simply:

What’s the most painful part of customer service?

2. First-Hand Intel: What the Real Pain Points Are

The answer I got was more real than any idea I could have come up with on my own:

Customer service reps constantly face unreasonable demands, accusations, even verbal abuse
Many problems are beyond their authority, but customers demand an on-the-spot resolution
A single call can drag on for 1–2 hours
Massive volumes of repetitive issues (same scripts, same workflows)
During major sales events (Singles’ Day, 618), pressure peaks — mandatory overtime

The line that hit me hardest:

“Some customers demand you resolve it for them right there and then, but you simply don’t have the authority to do it.”

This actually exposes a key structural problem:

Frontline agents: under the most pressure
Authority: minimal
Decision-making: not in their hands

3. Breaking Down the Problem: 3 Opportunities I Saw

Based on this info, I didn’t rush to write code. I took one step first:

👉 Structure the problem

① Emotional Load

Customer service isn’t just “solving problems.” It’s also “absorbing emotions.”

Characteristics:

High intensity
Long duration
Hard to standardize

② Repetitive Issues

For example:

“My internet is slow, what do I do?”
“Why did my connection drop?”
“How do I file a complaint?”

👉 These are fundamentally standardizable.

③ Escalation Gap (Authority vs. Process Conflict)

The most valuable one:

Agent can’t handle it
Customer demands it be handled
Spiral into prolonged consumption of time

👉 This is essentially a “triage + escalation” problem.

4. My Approach: Not a System — Just One Capability

I didn’t choose to build a full customer service system from the start. I decided:

Build just one “AI-assisted capability” and validate whether it has value.

5. Demo Design (First Version)

Input

The agent inputs a customer complaint:

“Your network is absolute garbage, I want to file a complaint — it keeps disconnecting!”

AI Output

Emotion: Angry
Issue Type: Network Fault / Complaint
Risk Level: High
Escalation: Recommended

Suggested Response:
Hello, we're very sorry for the poor experience. We can help you run a line diagnostic right now and simultaneously submit a request for further handling.

Voice Capability (TTS)

Not just text:

👉 Can also auto-generate voice output:

“Hello, we’re very sorry for the poor experience…“

6. Technical Approach (MVP)

What I ultimately chose was a very simple architecture:

Frontend (Simple Page / Chatwoot)
        ↓
FastAPI (Backend)
        ↓
AI Model (DeepSeek / Similar API)
        ↓
TTS (Voice Generation)

One core principle:

Running > Perfect

7. Why I Didn’t Start With a Complex Framework

I initially looked at a lot of open-source projects, like:

Chatwoot (customer service system)
Rasa (conversational AI)

But in the end I decided:

❌ Don’t start from these ✅ Build a minimum viable demo first

The reason is simple:

System too big → easy to get stuck
Demo too slow → miss the window

8. Current Stage: Not a Product — Validation

What I’m building right now can’t be called a product yet. It’s just:

A “demonstrable capability fragment”

The goal isn’t to launch. It’s to validate:

Is this thing useful?
Will the other party be interested?
Is it worth continuing?

9. Key Insight (This Is the Most Important Part)

The biggest takeaway this time wasn’t technical. It was:

AI doesn’t matter. The scenario matters.

If I had started by writing code, I might have built:

A chatbot
An AI assistant
An agent system

But none of those would move anyone.

What’s genuinely valuable is:

A capability that solves a specific problem.

10. Next Steps

What I need to do next isn’t expand features. It’s:

Build out the demo
Let a real user (his dad) try it
Listen to the feedback

If the response is:

“This thing is kind of useful.”

Then the real work begins.

Closing

This isn’t the start of an “AI project.” It’s:

The first time I genuinely engaged with a real business problem.

More important than writing any code.

If you’re working on AI-related things too, my advice is: don’t write code yet. First, find a real person and ask one question: “What gives you the biggest headache?”

—Jiahao Ren, a CS student learning to start from the scenario