Medical Aesthetics WeCom AI Customer Service System

A medical aesthetics chain 2026.02 – present In production

This AI customer service system now handles inquiries at real stores every day: there's a hard human-review gate on anything going out, over 600 regression tests backing it up, and it steps aside on its own whenever a conversation needs a human.

The business problem

The lead-acquisition chain in medical aesthetics goes: ad spend → online inquiry → follow-up by customer service → in-store consultation → close. Customer service is the choke point of the whole chain, but the team faces a flood of repetitive questions (project pricing, case photos, address), and response speed and script quality directly drive store-visit rate. The business wanted to use AI, but nobody could turn "want to use it" into "actually usable."

The approach: AI + human tiers, not replacing humans

I broke the customer-service need down into a clear tiered structure:

  • Static knowledge (project descriptions, address, credentials) — AI answers directly
  • Dynamic data (pricing, promotions) — pulls from a structured data source, AI drafts the wording
  • Sending case photos, price lookups — automated actions, triggered by AI
  • Complex inquiries, high-intent leads — handed off to a human; AI steps aside instead of getting in the way
This is positioned as an "AI-assisted customer service workbench," not a "fully automated customer service." Medical aesthetics consultations involve medical judgment and closing scripts — the right role for AI is to free staff from repetitive work and help them make more money, not replace them.
Customer msg Triage Static knowledge → AI answers directly Dynamic data → pull source, AI drafts Fixed actions → auto-send cases / price Complex / high-intent → human, AI exits UI element positions come from cross-calibration by two vision models, not hard-coded coordinates
The point of tiering isn't to make AI do more — it's to draw a clear line for where it should stop. The last path is AI actively stepping aside.

The hardest technical battle: coordinate hell in UI automation

The system is built on desktop WeChat automation. WeChat has no open API, and hook-based approaches (injection, protocol-level hooks) all carry a ban risk, so we ruled those out. What's left is screen recognition + simulated input — which comes with a built-in nightmare: every WeChat UI update breaks all hard-coded coordinates, and screen resolutions differ across devices anyway.

I ended up abandoning hard-coded coordinates in favor of dual vision-model cross-calibration: two different vision models each identify UI element positions independently, the results cross-check each other, and the system retries or falls back when they disagree. This lets the system adapt automatically after WeChat updates or device changes, without needing someone to manually re-mark coordinates every time.

Production hardening

There's a whole layer of engineering between "the prototype runs" and "it's production-ready":

  • Process supervision + health checks, so unattended customer-service machines can self-recover
  • Message deduplication and conversation-state management, to avoid duplicate replies and crossed-wire conversations
  • Boundary rules for handing off to a human, to make sure AI doesn't overreach in sensitive conversations
  • 600+ regression tests (replays of real conversation logs, multi-turn dialogue scripts, negative-sample batteries) to keep rule iterations from breaking existing conversation behavior
  • A code-level human-review hard gate on outbound broadcast messages — nothing reaches a customer unreviewed
  • Multi-store device adaptation and deployment workflow

Results and reflection

The system is now running at real stores. The biggest lesson this project taught me: the hard part of putting AI into production is people and process, not just technology — staff incentives, script standards, follow-up cadence — every one of these matters more for success than which model you pick.

UI automation is inherently fragile and needs ongoing maintenance to keep up with changes. That's the real cost of this technical path, and I'm not going to pretend otherwise.