Reception by Fulin Labs

Multilingual spa bookings: what to translate before confirming a time

Quick answer (updated ). Translate the booking facts and its status, not just the greeting. Before confirming a spa appointment, both guest and staff should understand the same service, duration, price, local date and time, number of people and approval state. When a fact is missing, ask rather than invent it.

Reception by Fulin Labs serves spas and massage shops through chat. We build the product used in the examples here. This checklist is a proposed operating workflow, not a claim that translation alone increases revenue or removes the need for staff.

1. Make service names unambiguous

Some guests ask for an effect, such as a gentle treatment, while a menu uses a technique or package name. Keep the menu’s service identifier behind the translated description so that staff prepare the treatment the guest selected. Ask a staff member to review the wording rather than treating a fluent sentence as proof of accuracy.

Test two easily confused services and a request for something you do not offer. The receptionist should explain what is available and ask a clarifying question when needed. It should not silently replace a service or promise a therapist preference that has not been approved.

2. Repeat the price basis and duration

Use the shop’s real currency and state whether the amount is per person. For a party of two, a per-person price and the total are different facts. If fees or deposits apply, state the shop’s published policy. If the policy is unknown, bring in a person instead of assuming there is no charge.

Illustrative wording: “You requested two 60-minute treatments. The menu price is [amount] [currency] per person. Is that the service you want?”

Replace every placeholder before using this wording with guests. Do not make claims about treatment benefits beyond the shop’s approved information. A translation task does not supply missing service or pricing facts.

3. Resolve the date in the shop’s local time

Tourists may still have a phone set to their home time zone. “Tomorrow at four” is not a complete booking detail. Repeat the full local date and time, and distinguish morning from afternoon. If the guest changes the day, recheck the slot rather than carrying over availability from the old date.

4. Translate “requested” and “confirmed” differently

A booking may be confirmed under the shop’s rules or held for a staff decision. The guest-facing words must match that state. In Reception, rules determine which requests need approval; configuring a receptionist does not prove that an owner’s notification channel is active.

Pending example: “We have your request for [service], [date], [local time], [party size]. It is waiting for the shop’s approval. You do not yet have a confirmed appointment.”

Use a separate confirmation message only after the system or an authorized staff member has confirmed it. A friendly “see you soon” can be misleading if it replaces the status. Check how a decline or change reaches the guest as well.

5. Give staff the original message and the decision they need to make

When a guest asks for a person, disputes a charge or raises a service complaint, avoid turning the issue into a new booking. Staff need the guest’s original wording, the related appointment if known and the question that needs an answer. An acknowledgement is not a resolved complaint or an approved refund.

Test the staff handoff in the language your team uses. Check where it arrives, whether a person can act and whether the guest sees an honest waiting state. Do not count a configured adapter or webhook verification as a completed real conversation.

6. Test the actual guest language and actual channel

Language options can differ between a web chat, the owner interface and a direct messaging connection. Check the current product flow rather than assuming every option works on every channel. Test one complete conversation with a speaker who can judge the service details, including an ambiguous time and a request that requires approval.

The Reception demo is a safe place to explore the guest and owner views. It runs in your browser and is not a live shop. Repeat the test with your own menu, rules and configured account before sending customers there.

7. Keep a small acceptance record

Write down the language, channel, menu version, test date, expected result and the observed guest/owner messages. Fix disagreements before launch. After launch, measure real requests, confirmations and completed visits separately, with the total number of eligible conversations as the denominator. No shop conversion or booking lift is established by this checklist.

For the physical entry point, follow the QR-code booking setup guide. To prepare your own receptionist, start with your menu, or discuss a managed pilot. Early-access setup needs no card; managed services are quoted separately.