Start with what happens at opening time
At 22:48, a fictional customer asks a Bangkok service business about an appointment. At 22:50 they send a photo. At 22:53 they write: “Actually Saturday, not Friday.” By morning the assistant has produced a cheerful acknowledgment, but the queue still says Friday and nobody knows what the photo shows. Fast replies have created slower work.
Design the morning handoff first. The opening colleague should see the current request, what changed, what the assistant already said, which facts remain unknown and the exact next action. They should not have to reconstruct the entire overnight conversation just to discover that the customer corrected the date.
Then write the overnight reply around the service the business actually offers. If staff return at 09:00 Bangkok time, say that only when the opening schedule is current. Holidays, closures and exceptional hours need an owner. Don't say “an agent will reply shortly” when the system knows nobody is assigned until morning.
What the acknowledgment can safely accomplish
A useful draft might say: “I've recorded your request for Saturday and passed the photo to the team for review. The team next reviews enquiries from 09:00 Bangkok time on 21 October. Your appointment isn't confirmed yet.” In the fictional example, each statement requires evidence: the request was stored, the photo is accessible to the team, and the stated opening time matches the actual schedule.
Do not say the photo was reviewed if it was merely received. If the workflow can't process an attachment, route it visibly and tell the customer that a person will check it. A voice note isn't an empty message. Treat unsupported formats as work requiring attention, not as permission to close the enquiry.
Keep overnight questions minimal. Asking for the service location may prevent a useless morning exchange; asking the customer to complete a long intake form can create more abandonment than value. Collect only the details needed to route the enquiry and identify the next meaningful action. Leave detailed diagnosis or commercial decisions for the appropriate person.
LINE events are not a perfect conversation transcript
LINE's receiving-messages documentation, checked 20 October 2026, warns that events can arrive more than once and redelivery can change their arrival order. It supplies event identifiers and timestamps. Design the intake so a repeated event doesn't create another ticket, while a later customer correction updates the existing request.
In the example, the Saturday correction must win even if the earlier Friday event arrives again during recovery. Preserve the sequence using the event information and conversation context, not just the order in which your database receives requests. If the relationship between messages remains unclear, flag it for the opening colleague instead of silently choosing.
The same LINE documentation explains that text arrives in the webhook and cannot be fetched again through a text retrieval API. Plan the authorised capture and retention process accordingly. It also describes unsend events; handling those requires updating visible records and derived summaries under your agreed policy. A removed message should not continue driving an appointment merely because the assistant copied it into a handoff.
The morning card should take less than a minute to understand
OVERNIGHT HANDOFF Conversation reference: Latest customer request, with source timestamp: Corrections that supersede earlier details: Attachments: received / accessible / reviewed by a person: What the customer has already been told: Any promised follow-up and its supporting schedule: Missing fact that prevents progress: Recommended next action: Assigned opening queue: Person accepting ownership: Accepted at: Automation paused for human handling: yes / no DRAFTING RULE Do not claim an appointment, price, refund or review is complete. Keep the source message available to authorised staff. Use the current opening schedule, including exceptions. If the handoff cannot be saved, expose the failure to the operator.
A queue assignment is not the same as a person accepting responsibility. Make acceptance visible at opening time. If the intended colleague is absent, the shift lead needs a way to reassign the work. Otherwise the assistant can keep generating perfectly formatted cards into a queue nobody reads.
The handoff must stop the next automatic reply
Imagine a colleague accepts the case at 09:07 and asks the customer for a location. At 09:10 the assistant sends an automatic “we'll be with you soon” message. At 09:15 it asks for the date again. The customer now has two apparent conversations with the same business.
Pause autonomous follow-ups when a person takes ownership, and have an explicit release action if automation resumes. The pause needs to cover the systems that can send, not just a badge in the inbox. Recheck the case state immediately before sending a scheduled message because ownership may have changed since the draft was prepared.
Next-day sending must use the appropriate supported LINE message method and current account permissions. LINE distinguishes reply and push methods in its sending documentation, checked 20 October 2026. Don't design a morning follow-up around an assumption that an overnight reply token can be reused indefinitely. Have the integrator demonstrate the actual route using a controlled test conversation.
Measure the first useful human action
Separate acknowledgment speed from the time to a substantive answer. For an overnight queue, also measure time from the next promised opening to accepted ownership. A request received while closed shouldn't be assessed as though the team advertised continuous staffing, but it also shouldn't sit unowned after opening.
Test a duplicate event, a late correction, an inaccessible image, a closure day and an absent shift owner. Disconnect the destination queue during a controlled test and verify that recovery preserves the enquiry without sending duplicate messages. Ask the opening colleague to complete the work using the card; don't accept a passing integration log as the only evidence.
For low volume, the right implementation may be an honest out-of-hours message plus a disciplined morning checklist. Add extraction and routing when they reduce actual effort. The valuable result is a customer who doesn't need to repeat themselves, and a person who knows exactly what to do next.
Sources and dates
Sources checked on 20 October 2026. Worked examples are teaching examples unless explicitly attributed. Provider documentation describes product behaviour; the operating recommendations are DLVX editorial judgement.
- LINE receiving messagesDuplicate and reordered events, timestamps, text capture and unsend handling. Checked 2026-10-20.
- LINE sending messagesSeparate reply and push messaging methods. Checked 2026-10-20.