24/5 multilingual support: inquiries become tickets, answers become Skills
Start with three tickets that went wrong.
The first: at 2:14 a.m., a gold-tier customer sent an inquiry; the first human reply came at 10 a.m. — against a 4-hour SLA, more than 3 hours late. The customer's words on the follow-up call: "Is your global support global, or is it nowhere?"
The second: the same "how do I raise my rate limit" question got answered twice — once by the Shanghai shift, again by Lisbon, neither aware of the other — citing two different policy versions. The customer sent screenshots of both to both managers.
The third: a new hire spent three months shadowing before daring to hold a shift alone. Her engineering counterpart, hired the same week, shipped a feature before she took her first solo ticket.
None of this was about effort. The duty desk simply lacked an operating model across time zones. This team — six people in Shanghai, Lisbon, and San Jose, relaying coverage for customers around the globe — turned inquiries into tickets and answers into Skills, and the desk started running differently.
What Wujie Harness is
Wujie Harness is an AI collaboration platform that puts communication, execution, review, and work memory in the same workspace. For a support team, two things set it apart from a ticket system plus group chats.
Inquiries and replies flow in one place. Customer emails and conversation records become ticket issues; the handling process, the reply, and the customer's feedback all live on the same issue. Handovers require no context transfers — whoever picks up opens the issue and knows everything.
Replies have drafts; people have the final say. The Support agent drafts replies from the Support Playbook skill, and may only quote what the playbook contains — it invents nothing. Support does one thing: review. Nothing sends until a person confirms it. The agent never talks to customers directly.
How the duty desk is staffed
Six people, three regions, coverage handed over in the order the sun rises. The three shifts overlap by 90 minutes, reserved for handover:
| Shift | Local hours | Coverage |
|---|---|---|
| Shanghai | 09:00 – 17:30 | APAC |
| Lisbon | 16:00 – 00:00 | Europe, Middle East |
| San Jose | 00:00 – 08:30 | Americas |
Handover follows a fixed checklist, kept on one pinned issue shared by all three regions, ticked item by item:
- Every open ticket: who it is handed to, and its current state;
- SLA-critical tickets starred, with time remaining;
- Escalated issues: how far they have gotten, and where they are stuck;
- Whether the Support Playbook gained any entries today;
- Special customer situations (frustration, commercial sensitivity) flagged separately.
Whoever is on duty watches the #support-global channel. Nobody asks "where did that conversation leave off" — the answer is on the issue.
One ticket, 23 minutes
Take an ordinary night and follow one gold-tier ticket from arrival to reply.
23:47 A gold-tier customer's email arrives: they want to raise their API rate limit from 100 to 500 rps, contract B-2209 attached.
23:48 Lin Yue, on the Shanghai shift, pastes the essentials into #support-global and @-mentions the Support agent, converting the email into ticket issue SUP-311 — customer, question, SLA deadline, and contract number all on the ticket. The clock starts.
23:52 A reply draft lands on the issue: the rate-limit policy (quoting Service Policy v3.2 §4.1 verbatim), the upgrade request link, and the expected effective time — all written to the playbook's standard. DingTalk pops a reminder at the same moment: "Awaiting review: SUP-311 reply draft is ready."
23:53 Lin Yue reviews: contract tier (gold), current limit (100 rps), link validity — all correct, approved and sent. Draft to sent: one minute.
23:55 The customer has the reply. Eight minutes after the inquiry; 3 hours 52 minutes left on the SLA clock.
23:58 The next ticket's draft is already waiting in Lin Yue's inbox.
support-global
Follow-the-sun customer support- LYLin Yue23:47
@Support agent Gold-tier customer emailed asking to raise their API rate limit from 100 to 500 rps (contract B-2209). SLA: reply within 4 hours.
The same ticket on the old desk: either it cost Lin Yue 40 minutes of live policy research, writing, and self-checking — or it rolled over to Lisbon, and the customer waited 8 hours for an apology plus an answer.
Why the drafts can be trusted
Every sentence the agent writes has a source. An entry in the Support Playbook skill looks like this:
Entry: API rate-limit increase Policy source: gold-tier customers may request up to 500 rps; contract number required (cites: Service Policy v3.2 §4.1) Steps: Console → Rate limits → Request increase (screenshot attached) Tone: confirm eligibility first, then the steps, then the expected timing; never promise an exact effective date Languages: zh / en / pt
The agent may only quote what an entry contains, and every draft carries its citation — the reviewer can check it against the policy source at a glance instead of trusting memory.
Playbook updates take effect immediately: the day the policy moves to v3.3, the entry updates, and every draft afterward cites the new version. The "two answers, two versions" incident dies mechanically — the three regions never need a sync meeting, because the playbook is the single source.
SLA and the escalation path
The Support agent also carries an SLA & Escalation skill — the same document a new hire reads:
| Customer tier | First reply within | Reminder raised |
|---|---|---|
| Gold | 4 hours | 40 minutes left |
| Enterprise | 8 hours | 1 hour left |
| Standard | 1 business day | 2 hours left |
When an SLA nears its limit, a to-do appears in the inbox and a reminder reaches whoever is on duty, on their own turf — late evenings and early mornings included.
Questions the playbook does not cover get no improvised answers. When the agent cannot draft, it notes "outside playbook scope" on the issue; support escalates into an engineering issue with the customer's environment and reproduction steps, and assigns it. SUP-314 was one: a customer reported bulk-export timeouts; it escalated to engineering issue OPE-188, engineering's fix progress landed back on the issue, and support replied to the customer with the latest state — the two issues stay linked, so what support tells the customer is always true and checkable.
The shift starts in the inbox
Whoever is on duty opens the inbox and finds everything the desk needs a human for: two drafts to review, one escalation, one mention. Work the queue — review, confirm, reply — fifteen minutes, read and archived, nothing left dangling.
Inbox
3- Workflow deliverable review23:52
Support agent drafted a reply for SUP-311 — awaiting review
- Agent blocked22:10
Support agent paused SUP-314: out of playbook scope, needs escalation
- Mentioned21:47
Lin Yue mentioned you in support-global
Nobody stares at a screen waiting for customers, and no customer message lies unseen in some group chat.
The experience pipeline
The first time someone handles "how do I raise my rate limit," it takes 25 minutes of doc-digging and asking around. The tenth time, the draft cites the playbook entry and review takes 2 minutes. What happens in between is a fixed pipeline:
A closed ticket gets marked "frequent" → collected into a knowledge candidate → the Monday 15-minute knowledge review walks through the week's candidates → on approval, one click publishes: a new entry in the playbook skill, an FAQ addition in the Wiki.
A new support hire spends week one reading the playbook and the FAQ Wiki, week two shadowing, week three on duty alone — a path that used to take three months. And the drafts the agent writes always cite the playbook's latest entry: when the playbook changes, drafts follow automatically.
Reminders land in DingTalk and Feishu
The three regions live across two habitats: domestic colleagues on DingTalk, overseas colleagues on Feishu.
Tickets awaiting review, SLA deadlines approaching, @-mentions — reminders reach whoever is on duty, on their own turf: Shanghai colleagues on DingTalk, Lisbon and San Jose colleagues on Feishu, each receiving their own. Before the Lisbon colleague clocks out, they hand over per the checklist; the incoming San Jose colleague gets the handover reminder in Feishu, and the full context is on the issues. The desk's operation depends on no one remembering to check a particular tool.
What changed
Faster. Median first response dropped from 6 hours to 40 minutes; late-night inquiries get drafted immediately and reviewed on shift; gold-tier SLA attainment went from 87% to 98%.
Consistent. All three regions quote the same playbook and the same policy text; customers get the same standard of answer at any hour, in any language.
Retained. Every inquiry is a ticket, every reply has a source; frequent questions flow through the pipeline into skill entries and the Wiki — the team's experience no longer walks out with turnover.
Accountable. Agents draft, people review and send — every sentence a customer receives has a source and an owner; every escalation has checkable progress.
Feature map: a cheat sheet for the presenter
| Feature | In this story | Docs |
|---|---|---|
| Channels | The coordination desk for three regions; inquiries convert to tickets | Channels |
| Issues | Tickets: customer, question, SLA, and reply context in one place | Issues |
| Agents | The Support agent drafts from the playbook; people only review | Agents |
| Skills | The reply playbook and SLA escalation path, written once, followed by all | Skills |
| Inbox | Drafts to review, escalation requests, SLA deadlines in one queue | Inbox |
| Knowledge | Frequent questions flow through the pipeline, published after review | Knowledge |
| Documents | The FAQ Wiki — a new hire's first reading | Documents |
| Runtimes | Local daemon; customer contract details never leave the intranet | Runtimes |
| DingTalk / Feishu | Reminders delivered automatically to whoever is on duty | Connectors |
| Usage & governance | Agent usage reports, owner-only environment variables | Governance |
Replicate this in your team
Start with two things: write the standard answers to your 20 most-asked questions into a Support Playbook skill — policy source, steps, and tone, three parts per entry; and put the shift handover checklist on one pinned issue. The moment the first support person realizes "all I do is review," the duty desk is running differently.