Staff Tasks & Communication

What you asked for

One place where management, cleaners and maintenance each see their own tasks, schedule, status, deadline, priority, property details and photos — with tasks increasingly generated automatically from reservations and guest messages. You are weighing Slack, but open to keeping LINE if something more structured sits behind it. The stated priority is reducing communication, not adding a tool.

The decision, first

Keep LINE. Do not move cleaning and maintenance staff to Slack. Put a structured task system behind LINE and use LINE purely as the delivery and interaction channel.

This is not a compromise; it is the better architecture, and the evidence is fairly one-sided. Slack adoption in Japan is real but concentrated in white-collar and IT-forward workplaces, and it generally requires company-issued devices and deliberate top-down IT investment to take hold on a frontline. For part-time, high-turnover, often older cleaning staff using their own phones — and for Indonesian-speaking staff in Bali — LINE is already installed, already open, already understood. Japanese SMBs with onsite staff routinely and explicitly choose LINE or LINE WORKS over Slack for exactly this reason: low IT literacy and no company phones.

Forcing a second app onto a cleaner is not a small cost. It is the difference between a system that gets used and a system that gets bypassed back into a LINE group chat within a month — at which point you have added a tool and reduced nothing.

Slack still has a legitimate place: the management layer. Ops managers, revenue, finance and you are a different population, on laptops, comfortable with threads and integrations. Alerting the management team into Slack while dispatching frontline work through LINE is a coherent split, not an inconsistency.

What LINE can and cannot do

The LINE Messaging API, used through a LINE Official Account, gives you more than most people assume:

And the hard limits, which shape the design more than the capabilities do:

• A bot cannot reliably read everything in a group chat. It receives only the events it is permitted to see, cannot retrieve history, and cannot cleanly attribute accountability inside a group thread. Therefore: group chats are for broadcast only. Today's schedule, "villa 3 closed for maintenance," typhoon notices. Never for assigned, accountable work.
• You need each staff member to add the Official Account as a friend to obtain their userId. This is a one-time onboarding step and it is the whole basis of individual dispatch. Build it into hiring.
• Push volume is metered. The API and bot logic are free; you pay per push message beyond your plan's monthly allowance (Japanese OA plans step up from a couple of hundred free pushes, to a few thousand, to tens of thousands). At hundreds of units this is a real line item and it rewards two design habits: batch a day's jobs into one morning card rather than one push per job, and prefer replies over cold pushes.

LINE WORKS — the paid enterprise suite — is a different product and mostly not the answer. It gives you an admin console, org chart, calendar, drive and a basic Tasks/Board feature, per user per month. But it does not give you job dispatch from reservations, photo checklists, par-stock logic, or KPI reporting. You would still build all of that. So you would be paying per seat for groupware and building the operations logic anyway. Consider LINE WORKS only if you separately want company email, shared drive and device management for a growing back-office — a genuine possibility at 1,000 units, but a back-office decision, not an operations-system decision.

Why not just buy Breezeway or Turno

These are good products and it is worth being honest about the trade. Breezeway, Operto Teams, Turno, Properly and Doinn all do the core thing well: auto-generate turnover tasks from PMS/OTA calendars, run photo checklists, and give cleaners a mobile app. Breezeway in particular has strong PMS integrations and genuinely detailed checklist tooling; Turno is the simplest for cleaners and adds a cleaner marketplace and payments.

The problem is the last mile. None of them has first-class Japanese localisation, and none is LINE-native. They assume an English- (or Spanish/Portuguese-) language app with push notifications. On the hotel side, HotSOS, Quore, Alice and Flexkeeping are more capable still but are built around a front-desk/room-status model and are priced and shaped for hotels, not distributed apartments and villas.

So the realistic options are:

1. Buy an ops platform, ignore the staff app, deliver through LINE. Use Breezeway or Operto Teams as the scheduling brain (it already knows how to turn reservations into turnovers) and push job cards into LINE yourself via its API. Less to build, but you now maintain a bridge, and the checklist data lives in someone else's schema.
2. Build a thin task app with a LIFF front end. More work up front (this is genuinely a few weeks, not a few days), but the staff experience is in Japanese and Indonesian, inside LINE, with exactly your checklist structure — and the task data sits in your own spine where the supervisor in Chapter 6 and the inventory forecaster in Chapter 4 can read it.

Recommendation: option 2, for the same reason you should not build a PMS — the asymmetry runs the other way here. A wrong calendar is catastrophic; a wrong checklist is annoying. Task management is low-risk, high-differentiation, and no vendor serves your specific staff population. This is the right thing to build.

How it should be built

Roles and views

Three roles, three genuinely different screens. Resist the urge to make one flexible view.

• Cleaner (LINE / LIFF). One question answered instantly: what am I doing today, in what order, where. A day list of job cards; tap a card to get address and access notes, room-specific instructions, the checklist, and photo slots. Buttons: On my way · Started · Blocked · Done. Nothing else. No project views, no comments thread, no notifications about other people's work.
• Maintenance (LINE / LIFF). Same skeleton, different content: a ticket queue by priority, the reported symptom with the guest's photo attached, unit history ("this AC was reported twice in 90 days"), parts used, and a resolution note. First-time-fix is the metric this view exists to serve, so make parts and history visible before the visit, not after.
• Manager (web). The board: today's timeline across properties, unassigned work, at-risk turnovers (checkout and check-in on the same day with no cleaner assigned is the single most important alert in the whole system), overdue tickets, and photo review. Bulk assign, reschedule, reassign.

Task generation

Three sources, in order of value:

1. From reservations. Every confirmed checkout produces a cleaning task, scheduled in the window between checkout and the next check-in, with a duration estimate from unit size and history. Every reservation change moves or cancels it. This alone eliminates most of your current LINE traffic, because "what needs cleaning tomorrow" stops being a question anyone asks.
2. From guest messages. Chapter 1's classifier turns "the AC isn't cold" into a draft maintenance ticket, pre-filled, awaiting one approval tap. The guest's own photo comes along with it.
3. From schedules and inspections. Recurring preventive work (filter changes, deep cleans, smoke-alarm checks) and follow-ups from failed checklist items.

Human approval sits on generation for anything AI-inferred, and nowhere else. A reservation-driven cleaning task does not need approval — the reservation is the approval.

Status model

Keep it boring and enumerable: scheduled → accepted → in_progress → blocked → done → verified. Only blocked needs a reason code (no access, unit not vacated, missing supplies, damage found), and every reason code should be able to trigger something else — "missing supplies" is an inventory signal, "damage found" is a maintenance ticket and possibly an OTA claim.

verified matters more than it looks. Photo-verified completion is what lets you stop chasing, and it is the evidence base for the cleaning-defect KPI below.

Photos

Require them at fixed points, not everywhere. Two to four per turnover (bed made, bathroom, kitchen, general) plus unlimited free-form for problems. Photos should be compressed on device and stored with the task, and — this matters legally — treated as operational records, not guest data, and kept out of any store that holds guest identity documents (Chapter 7).

KPIs worth tracking

These are the numbers that make the system pay for itself, and each one should be visible on the manager board from day one rather than added later.

• Turnover time — checkout to verified, against an SLA (e.g. ≤3 hours for a same-day turn). Segment by cleaner and by unit; unit outliers are usually a layout or supplies problem, not a person problem.
• On-time start rate — scheduled start versus in_progress. The leading indicator of everything else.
• Cleaning defect rate — failed checklist items plus guest cleanliness complaints per 100 turnovers. Ties directly to review scores and comps.
• First-time-fix rate — maintenance tickets closed without a return visit. Target 85–90%. A low rate almost always means parts or triage, not skill.
• Recurring-issue rate — repeat tickets on the same unit within 90 days. This is your capex signal and the pattern the supervisor should surface loudest.
• Photo compliance rate — because a checklist nobody photographs is a checklist nobody completed.
• Cost per turnover — labour plus consumables, per unit. The number your management fee is ultimately justified against.

Effort and risk

Effort: moderate. A LIFF task app with three role views, reservation-driven generation, photo upload and a manager board is the largest single build in this handbook after the guest inbox — realistically the second module you commit engineering time to, and the one most sensitive to getting the staff UX right on the first try. Budget for at least one full round of watching a real cleaner use it on a real turnover and rewriting the screens afterwards.

Risk: low technically, moderate organisationally. The technical risks are LINE push cost and the friend-add onboarding step. The organisational risk is the one that actually kills these projects: staff quietly reverting to LINE group chat. Mitigate it structurally, not with training — when the only way to see tomorrow's schedule is the app, and the schedule is genuinely correct and complete, group chat stops being easier.

Decisions for you

1. Confirm LINE for frontline, Slack (optional) for management only. If you want Slack for the management team, say so now; it changes nothing structurally but adds an alerting target.
2. Build the task app, or buy Breezeway/Operto and bridge to LINE? Recommendation: build. But if you want a running system in weeks rather than months, the bridge is a legitimate interim.
3. Do you want LINE WORKS for the back office? Separate decision, separate budget. Defer.
4. Who owns "verified"? An ops manager reviewing photos, or trusted-cleaner self-verification with spot checks? This determines how much management time the system consumes and should be decided before the board is designed.