From Chinese Enquiry to Your Booking System

The part of a Chinese channel that gets attention is the front: the Mini Program, the notes, the first reply. The part that quietly decides whether any of it works sits behind that, in a place no customer ever sees. A conversation in WeChat has to become a line in the booking system your staff already run the day from — the one that holds the calendar, the vehicle allocation, the guide roster and the manifest for tomorrow morning.

Those two places were not built to know about each other. Every gap between them is somewhere a detail can fall out, and the details that fall out are the ones that matter on the day.

The short version: treat the handoff as its own piece of work. Decide which system is the single source of truth for availability, and never sell from a second calendar. Capture the passport name, party makeup, pickup point and contact route in structured fields at the moment of enquiry instead of fishing them out of a chat later. Send the confirmation back the way the enquiry arrived, not by email. And make sure a booking paid inside WeChat shows as paid in the system your team checks. A disciplined manual copy is a sound way to start; integration is worth it once volume makes the copying itself the risk.

Two systems that do not know about each other

Most operators already run a booking platform, a property system or a well-kept spreadsheet, and it works. A new channel adds a second place where a customer can say yes. From that moment there are two records of the same booking, kept by different people, in different languages, updated at different times.

The failure is rarely a lost booking. What happens is smaller and more expensive: a pickup at the wrong hotel, a child seat nobody packed, a name on the manifest that does not match the passport at check-in. Each one traces back to a moment where somebody copied information from one place to the other and something did not survive the trip.

What falls out in the copy

Some details are reliably lost when a chat becomes a record, because they arrive in a form the booking system does not expect.

The name. A guest writes their name in characters. The booking system, the airline and any ticketed attraction need it as it appears on the passport, in pinyin, where surname and given name sit in separate fields — and staff unfamiliar with Chinese names regularly put the surname in the first-name box or keep only one part. Ask for both, spelled as on the passport.

The contact route. A WeChat ID and a phone number are different things, and a +86 mobile number is often not the best way to reach someone who is traveling. Record how this particular guest actually wants to be reached on the day.

The party. "Two adults and my parents" is information a booking system wants as a count with ages, because it drives vehicle size, seating and pricing. Chat delivers it as a sentence.

The pickup point. Hotel names get written in Chinese, in English, or as a screenshot of a map pin. Only one of those can be pasted into a driver's run sheet. Store it in the form your drivers use.

The request buried in the ninth message. Dietary needs, a mobility question, a flight arriving late. It was said, clearly, in the chat, and it never reached the record because nobody scrolled back far enough.

A structured enquiry form inside the Mini Program removes most of this at source, since each detail arrives in its own field — the argument for a checkout with nothing to type applies equally to the enquiry that comes before it.

Availability has one home

Of everything in this post, overbooking is the most expensive failure, in money and in reputation, and it comes from one decision made badly or not at all: allowing two places to promise the same seat.

The rule is simple. One system holds availability, and every channel, the Chinese one included, sells against it. If the Chinese storefront shows a date as open, it is because the main system says so, either through a live connection or because someone checks before confirming. What must never happen is a separate calendar maintained for the Chinese side, because two calendars will disagree the first busy weekend and there is no good way to tell a guest who has already paid that their seat was sold twice.

Where no live connection exists, the practical version is "request, then confirm": the storefront takes a request, staff check the main system, and only then does the guest receive a confirmation. It takes longer, but it cannot promise a seat that is already gone.

The confirmation goes back the way it came

The booking system will usually want to send its own confirmation, in English, by email. For a Chinese guest, that message is close to invisible — the reasons are covered in why Chinese customers do not answer email. The guest who enquired in WeChat expects to hear back in WeChat, in Chinese, and in a form they can screenshot and forward to the people traveling with them.

So the handoff runs in both directions. Whatever the booking system decides — confirmed, waitlisted, changed — has to travel back to the channel the guest is actually watching, with the date, time, meeting point and what to bring stated plainly.

Paid in one place, recorded in another

If the guest paid inside the Mini Program, the money moved through WeChat Pay and a cross-border settlement, and none of that automatically appears in the booking system as "paid". Staff looking at the manifest see an unpaid booking unless somebody marks it. The same goes for refunds and part-payments.

Record the payment status in the main system at the moment of confirmation, with the order reference from the payment side, so that the two can be matched later. The matching itself has its own traps, which we covered in reconciling cross-border payouts against bookings.

Three ways to run the handoff

There is no single right setup. The sensible one depends on how many Chinese bookings arrive and how many people touch them.

Starting with the first is not a compromise. A checklist that captures the right fields is worth more than an integration that syncs the wrong ones, and it tells you which fields matter before anyone builds a connection around them.

Where CN1X fits

The Mini Program is ours to build, and designing the handoff is part of that work instead of an afterthought: which system owns availability, which fields the enquiry captures, how confirmations travel back through WeChat, and whether a direct connection to your booking platform is worth building at your volume. That sits within what we build.

If your Chinese enquiries currently arrive in one place and have to be retyped into another, tell us which system your team runs the day from and we will map what the handoff needs.