Business data automation: real-time dashboard + WeCom reporting bot

A medical aesthetics chain 2026.06 – present In production

Data used to mean employees manually exporting tables every day and posting screenshots in group chats; now management just opens their phone. And metric definitions went from word-of-mouth to one single set hard-coded into the system.

The business problem

The company's business data was all locked away in dozens of query reports inside an internal management system — performance, cost, customers, follow-ups, each viewed separately. When management wanted to know "how are we doing today," the answer came from employees manually exporting tables every day, stitching together Excel sheets, and posting screenshots in WeChat groups — slow, and everyone ended up with slightly different numbers, because metric definitions were passed along by word of mouth.

The solution: a data pipeline from the internal system to the phone

  • Automated data pulls: the account connects directly to the internal system's API, without relying on a browser login session; pulls run single-threaded and rate-limited, respecting what the production system can actually handle
  • Metric-definition governance: every business rule for performance, cost, and commissions was dug out of veteran employees' heads, written into code, and checked line by line against the stores' manual spreadsheets
  • Real-time dashboard: viewable directly on a phone, with key-authenticated public access; toggles for period-over-period comparisons, department filters, trend forecasting; and a 1:1 replica of the Excel view, because the business team only trusts the way Excel looks
  • WeCom reporting bot: distributes report images to specific groups on a daily schedule (different roles see different reports); day-to-day, you can ask it questions in natural language and it looks up the data itself
Internal system Read-only, direct link Auto pull Rate-limited Metric governance Rules hard-coded Live dashboard View anytime Reporting bot Scheduled per group Exit gate: broadcast content must be a subset of an admin-approved task, or the code rejects it outright
A data pipeline from the internal system to the phone: pulls respect the source system's production load, metrics are unified before distribution, and the exit has a review gate.

The hardest fight wasn't the code — it was the metric definitions

On this project, 70% of the time went into one thing: making the automatically calculated numbers match exactly what the business considered correct. Does "performance" count refund orders? Should "cost" exclude inspection tickets? Which category does a certain type of document actually belong to? — every single rule had to be dug out of the real business, verified, and then hard-coded.

Here's a pitfall worth writing down: the self-verification trap. If the "reference table" I used to check my numbers shared the same source as my data pipeline, matching it perfectly proved nothing. So I set a rule for verification: the reference must come from an independent second source, and that source itself has to be verified before I even talk about reconciling numbers.

Hardening for production: every data exit needs a gate

The reporting bot sends data into business groups every day; sending to the wrong group or the wrong numbers is an incident. So every exit point got a hard gate at the code level:

  • Every broadcast must reference an "admin-approved" task, and the content sent must be a subset of what was approved — otherwise the code rejects it outright. It relies on the mechanism, not on people remembering to be careful
  • Session mapping and permission management: a whitelist decides exactly what each group and each person can receive
  • When a data pull fails, it degrades to a plain-language message ("internal system is unstable, please retry later") instead of dumping an error stack trace into the business group

Another lesson was respecting other people's production systems: I once used concurrent requests to pull from the internal API and crashed it. After that, every pull became single-threaded and rate-limited — speed matters less than stability, and that's just basic courtesy when you're building on someone else's foundation.

Results and reflections

Now this whole pipeline runs automatically every day: management checks the real-time dashboard on their phones, business groups receive the day's report images right on schedule, and anyone can just ask the bot whatever they want to know in natural language. The old daily routine of manually exporting tables and stitching Excel sheets has become a routine job for the system.

There's a reflection too: I built the thing first, and only went back afterward to research what users actually wanted to see. No matter how smooth a tool is, if it doesn't fit users' real habits, getting them to adopt it is like rowing against the current — on the next project, research needs to come before development.