Running a Bilingual IT Service Desk Inside Lark or Feishu: What Actually Changes

Putting the service desk where your staff already type feels like the easy win — until every chat message becomes an unstructured request with no category, no owner and no clock. A bilingual 24/7 service desk can run inside Lark or Feishu without losing any of that, but only if every message is converted into a ticket automatically, in both directions, the moment it arrives. This article covers what changes when chat is the intake channel, and what has to be true before you trust a first-line resolution number.

What happens when a whole company already lives in Lark or Feishu?

Picture a consumer brand headquartered on the mainland, with a Hong Kong office handling regional sales and compliance and a smaller Singapore office covering Southeast Asia distribution. Every department already runs inside Lark or Feishu — group chats for finance, group chats for logistics, a group chat for "IT Help" that someone set up two years ago and never structured. This is a composite scenario built to be representative, not a named client.

The company also has a ticket system. Nobody in Hong Kong or Singapore opens it. Staff already have Lark open all day for everything else, and asking them to switch tools to log a laptop problem is a step nobody takes until the laptop is unusable. So requests arrive the way every other request at that company arrives: as a message in a chat, addressed to whichever engineer replied last time.

This is not a story about a bad vendor or a lazy IT team. It is what happens by default when the intake channel your users actually use and the system your IT team actually measures against are two different things. The gap between them is where dropped requests, invisible workload and a service-quality argument all live.

What actually changes when chat becomes the intake channel?

Moving intake into a chat app is not simply "the same helpdesk, new front door." Three things change at once, and each one has a knock-on effect on how the desk has to be run.

Volume rises, because the friction that used to filter requests disappears. A ticket portal has just enough friction — a login, a form, a category field — that a genuinely minor annoyance often doesn't become a ticket. A chat message costs nothing to send. Question volume typically goes up when a desk moves into chat, and a desk staffed and processed for portal-era volume will fall behind fast.

Triage moves earlier, onto whoever happens to see the message first. In a portal, a dispatcher looks at every new ticket before anyone works it. In a group chat, the first person to notice a message is often the one who answers it — regardless of whether they are the right owner, whether the issue has already been reported by someone else in the same thread an hour earlier, or whether it needs to be escalated rather than answered.

The request arrives without the context a form would have forced out of the requester. A ticket form asks for a device, a location, a screenshot, a category, before it lets you submit. A chat message says "my laptop is acting up again" — as a reply four messages down in a conversation about something else entirely. Everything a form would have collected has to be extracted afterward, in a second conversation, which is exactly the back-and-forth a chat-based desk is supposed to avoid.

None of this means chat-based intake is the wrong idea. It means the desk needs machinery underneath the chat interface that a portal gave you automatically and that a raw group chat does not.

What are the non-negotiables for running a service desk inside chat?

Four rules turn a chat channel into something you can actually run a service desk against. Skip any one of them and the desk degrades back into a group chat with an IT label on it.

Every message becomes exactly one ticket, automatically, the moment it is sent. Not "an engineer creates a ticket if they think it's worth logging." Every inbound request — a question, a complaint, a repeat of yesterday's problem — gets a ticket ID the instant it lands, before a human has read it. This is the single change that prevents requests from being silently absorbed into a conversation and then forgotten once the conversation moves on.

A category taxonomy that survives contact with actual users, not the one that looked complete in a workshop. Users don't self-classify accurately, and they shouldn't have to. Build a short list of categories mapped from real request patterns — hardware, account access, application, network, onboarding/offboarding, "other" — and let the first human or automated triage step assign it, rather than asking the requester to pick from a menu they don't understand.

The SLA clock starts at the message, not at the hand-off to whoever eventually works it. This is the rule most desks get quietly wrong. If the clock only starts once a ticket is "accepted" or "assigned," every minute a message sits unread in a busy group chat is a minute that never gets measured — which means your SLA report can look excellent while your Lark channel has messages sitting unanswered for hours. The clock has to start at message receipt, full stop.

A written record exists after the thread scrolls away. Chat is transient by nature — the conversation about a printer three weeks ago is buried under two thousand messages by now. Every ticket needs its own durable record: what was asked, what was done, who did it, when it closed. That record is what makes a monthly report, an audit, or a "didn't we already fix this" conversation possible six months later.

Chat-native intake vs a ticket portal vs a hybrid: how do they actually compare?

• Chat-native intake (message becomes ticket automatically): matches how staff already work, so volume is fully captured and nothing is lost to "I didn't feel like logging into the portal." Its risk is that without automatic conversion, chat becomes an unstructured mess that nobody can report against — the mechanism, not the channel, is what makes this work.
• Ticket-portal-first (staff must open a separate system to log a request): gives IT a clean, structured queue with categories and priorities captured up front, but a meaningful share of real requests never reach it, because logging in is friction most staff skip for anything short of "my laptop won't turn on."
• Hybrid (chat for reporting, portal for tracking, synced automatically): the model that actually fits a Lark-native company — staff report the way they already work, IT still gets a structured, reportable queue, and the two stay in sync without anyone re-typing anything. It costs more to set up correctly than either pure model, and it is the only one of the three that holds up once volume grows.

How do you route requests bilingually without three separate teams?

The scenario company writes in three registers day to day: Simplified Chinese from headquarters, Traditional Chinese and English in Hong Kong, and English in Singapore. A desk that can only answer in one of them either forces every requester to translate their own problem or routes everything through a single bilingual bottleneck, which quietly becomes the slowest part of the desk.

The practical answer is not three separate desks per language — that recreates exactly the fragmentation the company is trying to escape by centralising on one chat platform. It is a bilingual first-line team, staffed so that Traditional and Simplified Chinese and English are all native-level within the same rotation, paired with a fixed rule about what language a reply goes back in: answer in the language the request arrived in, never in whichever language the engineer on shift happens to prefer that hour. Brocent's 24/7 multilingual help desk is built around exactly this requirement — Cantonese, Mandarin and English support across the same rotation, rather than a single bilingual engineer covering three time zones alone.

The category taxonomy has to be language-independent too. "Account access" should file the same way whether the request came in as 账号访问 from headquarters or in English from Singapore, so that a manager reviewing monthly volume by category sees one real picture, not three fragments that need to be reconciled by hand. If you're at the stage of actually vetting a provider's language claims rather than designing around them, our checklist for confirming real multilingual IT coverage goes through what to ask for before signing, and this article deliberately doesn't repeat it.

What does a realistic first-line resolution rate actually look like?

A 90%+ first-line resolution target is a real number a real buyer asked for, and it is worth taking seriously — but it is a target to design a desk around, not a badge that comes free with any chat tool. Three questions decide whether it is achievable, or just a number on a slide.

What counts as "first-line," and does it match how the ticket was actually closed? If an engineer looks something up, walks the user through a fix in the same chat thread and closes the ticket without ever reassigning it, that is a genuine first-line resolution. If the ticket sits open for two days while three people are quietly consulted in a separate private chat before anyone replies, counting that as first-line is a reporting decision, not an operational fact. The measurement has to track what actually happened on the ticket record, not what the closing note claims.

Does the taxonomy and knowledge base actually match the request mix you get? A first-line team resolves a password reset, a shared-drive permission, a printer queue and a known application error quickly because those are repeatable, documented problems. A genuinely new hardware fault or a vendor-side outage is never going to be a first-line resolution, and a target that doesn't account for that mix will be missed for the wrong reasons — or hit by quietly reclassifying the hard ones.

Is the first-line team staffed for the request mix, or borrowed from something else when volume spikes? A 90%+ target assumes the first-line rotation has enough trained people, in the right languages, at the hours requests actually arrive. If the same two bilingual engineers are also the ones who get pulled onto Tier 2 escalations, the number moves with whoever happened to be free that week, not with anything you can plan around.

None of this means the target is unrealistic. It means the number is a staffing and taxonomy decision before it is a tooling decision, and a serious plan states its assumptions rather than presenting a single figure as guaranteed from day one.

What does 24×7 actually mean once chat is the intake channel?

Two very different things get called "24×7," and the difference matters more once requests can arrive at 2 a.m. Hong Kong time because someone in headquarters is finishing their day.

Follow-the-sun coverage hands the desk between staffed regional teams as the day moves west, so every hour has an active, fully staffed shift somewhere. On-call coverage means a smaller after-hours team is reachable but not continuously staffed, and responds when paged rather than watching the channel in real time. Follow-the-sun handles steady, unpredictable request volume well; on-call is built for genuine emergencies, not routine chat traffic, and a chat channel that only has on-call coverage overnight will quietly accumulate unanswered messages that look, the next morning, exactly like the problem this whole approach was meant to solve. We've covered how follow-the-sun handoffs and SLA tiers work in more depth in our guide to 24/7 multilingual service desks in Asia; this section only covers what's different once chat, rather than a portal, is where the shift handoff actually happens.

Deciding which model to run is really a staffing decision dressed up as a coverage decision. A follow-the-sun rotation needs enough trained, bilingual first-line staff in each region to keep the active shift genuinely staffed — not one person nominally "on" while doing something else — and that cost is easiest to justify when overnight volume is steady rather than occasional. An on-call model costs less to staff but should come with an explicit rule for what an unread overnight message gets: at minimum, an automated acknowledgement inside the chat thread the moment the ticket is created, so a requester at 2 a.m. Hong Kong time knows their message became a ticket, even if the substantive reply waits for the next active shift.

The honest question for a Hong Kong-and-Singapore operation with a mainland headquarters is not "do we need 24×7" in the abstract — it's which incidents genuinely justify staffed, real-time coverage across the full 24 hours, and which can wait for the next active shift with a clear acknowledgement in the meantime. A chat-based desk should never leave a message sitting with zero acknowledgement; an acknowledgement is not the same commitment as an active first-line response, and the two need different staffing.

When does a chat message need to become a dispatch instead of a reply?

Some requests cannot be resolved in a chat thread no matter how well the desk is run — a failed switch, a broken cable run, a physical hardware swap. The non-negotiable here is that escalation into an on-site visit has to be a deliberate, visible step inside the same ticket record, not a separate conversation that starts over in a different chat with a different person. The category, the history and the SLA clock travel with the ticket into the dispatch, rather than resetting because the work moved from a chat window to a technician's van. Brocent's published dispatch SLA tiers — response and on-site windows across Normal Business Hours, Extended Hours and 24×7 Emergency coverage — exist precisely so that this hand-off has an agreed clock attached to it, rather than an open-ended "someone will come by."

What should never be handled inside a chat thread?

Chat is fast, which is exactly why some categories of request should be kept out of it deliberately. Access approvals — granting a new system permission, restoring a former employee's account, approving an exception to a security policy — need an auditable approval trail with a named approver, not a thumbs-up emoji in a group chat that scrolls away. Anything that changes who can reach a system, rather than helping someone use the one they already have, belongs in a workflow with a record that survives longer than the chat history does. A chat-native desk should route these requests out to a proper approval process the moment they're recognised, not attempt to resolve them in the thread because that's where they happened to arrive.

This is a different question from whether the company needs round-the-clock coverage at all, which is its own decision with its own trade-offs. Here it's assumed the answer is yes, because the scenario company's chat channel never actually closes; what's still open is which parts of those 24 hours need an active, staffed reply and which need only an acknowledgement.

How does this fit into a broader managed IT plan?

A chat-based service desk is one piece of a wider support relationship, not a standalone product. It sits alongside the same managed services foundation — monitoring, patching, on-site dispatch when a chat conversation escalates into hands-on work — and the same reporting discipline that any credible help desk should apply, chat-based or not: monthly volume by category, response and resolution times, and a first-line resolution figure that states what it is measuring. Brocent's per-user managed IT plan prices this kind of support by user per month, with Hong Kong tiers starting at HK$855.14 for 1–5 employees and rising to HK$1,247.40 and HK$1,561.21 as headcount and scope grow — full detail is on the pricing page. If you're weighing whether a chat-native desk fits a Lark- or Feishu-run organisation with offices in Hong Kong and Singapore, talk to our team about what the taxonomy, staffing and SLA design would actually look like for your request volume.

Frequently asked questions

Can Lark or Feishu actually replace a ticket system?

Not on its own. Lark and Feishu are excellent at what they're built for — fast, native communication — but a chat app has no concept of a ticket, an SLA clock, a category, or a durable closed-ticket record. What replaces the ticket system is the combination of the chat app as the intake channel and an automated layer that turns every message into a structured ticket the instant it arrives. Skip that layer and you have a very fast, very unstructured group chat.

How do you stop requests from being lost inside a busy group chat?

By removing the choice to lose them: every inbound message gets a ticket ID automatically, before any human triages it, so nothing depends on someone noticing a message in a scrolling thread. Combine that with a rule that no ticket closes without an explicit resolution note, and a daily check for messages that generated no ticket at all — which usually means the automatic capture missed a channel or a message format, and needs fixing at the source rather than caught manually every day.

What is a realistic first-line resolution rate for a desk like this?

It depends entirely on the request mix and how honestly "first-line" is defined. A desk handling mostly repeatable, documented issues — password resets, access requests, known application errors — staffed with enough trained bilingual first-line engineers, can realistically target a high rate, including 90%+. The same target applied to a request mix heavy in novel hardware faults or vendor-dependent issues, or measured by a definition that lets multi-day, multi-person tickets still count as "first-line," is not a target — it's a number chosen to look good on a slide.

How do you handle three written languages without three separate teams?

Staff a single first-line rotation with genuine fluency across all three registers your business uses, and set a fixed rule to reply in the language the request arrived in. A language-independent category taxonomy underneath means reporting isn't fragmented by language either — a manager reviewing monthly ticket volume should see one categorised picture, not three that need reconciling by hand.

Does a chat-based service desk actually work for 24×7 coverage?

Yes, but only if you're deliberate about which model you're running. Follow-the-sun coverage — a staffed, active shift somewhere at every hour — genuinely handles steady overnight chat volume. On-call coverage, where a smaller team is paged rather than watching the channel, is built for emergencies, not routine traffic, and will quietly accumulate unanswered chat messages overnight if it's asked to do a follow-the-sun job.

What about staff who still prefer to send an email instead of a chat message?

A well-designed intake layer should treat email as another channel feeding the same ticket pipeline, rather than forcing every requester onto chat. The categorisation, SLA clock and record-keeping rules are the same either way — the channel a request arrives through shouldn't change how it's measured or reported, only how the requester experiences sending it.

How is a chat-based desk actually audited?

The same way any service desk is: through the durable ticket record each message generates, not through the chat history itself. A monthly export — creation time, category, first-line versus escalated resolution, closing note — lets a manager or an outside reviewer recompute volume and resolution figures independently, the same discipline that makes any SLA report checkable rather than simply trusted.

What if the company uses Microsoft Teams or Slack instead of Lark or Feishu?

The operating model described here doesn't depend on which chat platform a company standardises on. The non-negotiables — automatic ticket capture, a category taxonomy that survives real users, an SLA clock that starts at the message, a durable record outside the chat thread — apply identically whether the intake channel is Lark, Feishu, Teams or Slack. What changes between platforms is the integration work needed to capture messages automatically, not the design of the desk itself.