← Series contents · Complete reading view
From a complaint to work that someone owns
“I have informed the team” is an easy sentence for a model to produce. It is also one of the least useful responses if no one has been assigned, no notification was delivered and the guest has no way to learn what happens next.
The issue workflow in the client platform was designed around the operational chain behind that sentence. A complaint needed a known stay, a record, a dispatch decision, an escalation rule and a persistent reference for later updates.
Turn the complaint into an explicit outcome
The input includes a guest’s description, a category, urgency and the resolved property or stay. The output needs more than a task ID. It should say whether the task was created, proposed or deduplicated; who owns it; whether a slot was booked; when it is due; and what escalation or notification occurred.
The platform’s dedicated issue flow puts the mandatory chain in code. The model interprets the request and explains the returned outcome. This avoids depending on the model to rediscover a dispatch procedure on every complaint.
A worked outcome might be:
{
"status": "created",
"task_id": "task-example",
"assignee": {"name": "Maintenance team", "kind": "load"},
"slot": null,
"escalation": {"recorded": true, "notified_channels": []},
"say": [
"The issue has been recorded.",
"An arrival time has not yet been confirmed."
]
}
The scenario is illustrative, but the distinctions are implemented concerns. An assigned person without a booked slot is not a scheduled visit. An escalation record without a delivered channel is not evidence that someone received a message.
Start with the right stay
A guest with several stays can report an issue at any of them. Before creating a task, the flow must know which stay the request concerns. The current stay focus, explicit references and recent conversation choices can help; unresolved ambiguity should produce a clarification.
This is also an authorization boundary. A task-status query should resolve against issues associated with the guest’s conversation and stays, not select an arbitrary task at the same property. Shared property identity is too broad to identify the guest’s issue.
The issue memory supplies references for later “any update?” requests. Live task state supplies the answer.
Deduplicate operational work
Messaging retries are one source of duplicates. Repeated guest complaints are another. An inbound idempotency key handles a repeated event, but a guest can send a new event about the same unresolved leak.
The issue flow checks for an applicable existing request and associated task. A valid duplicate can return the current status instead of creating another work order. The deduplication policy needs a defined scope, category and time window; it should not collapse unrelated problems merely because both are plumbing issues.
An evaluation should include a repeated complaint, a genuinely different issue in the same category and a recurrence after closure. The desired behaviour differs across those cases.
Availability is more than a role label
A staff member with the role “maintenance” is not automatically available. The platform’s scheduling API uses working schedules and occupied task intervals. Missing roster schedules can therefore produce no bookable slots even when staff records exist.
That is an integration and data-quality problem, not a prompt problem. Asking the model to “try harder to find staff” cannot create a schedule that the backend does not have.
The dispatch design first looks for suitable availability. When a slot is available, the earliest feasible slot matters; a tie can consider workload. When no slot exists, a configurable ownership ladder can assign responsibility without inventing a visit time.
Distinguish ownership from scheduling
The ladder can fall back through available team members, a property manager and an account owner, depending on configuration and available records. Its purpose is to avoid leaving an issue ownerless while preserving the truth about scheduling.
| Result | Meaning | Guest-facing implication |
|---|---|---|
| Staff and slot booked | A visit has a committed interval | State the interval and timezone |
| Staff assigned, no slot | Someone owns follow-up | Say a time will need confirmation |
| Host temporarily owns issue | Escalation requires operational attention | Explain that the host must arrange the next step |
| No assignee | Ownership is still unresolved | Do not suggest someone is already on the way |
| Proposal awaiting approval | No final task commitment yet | Describe a pending request |
These distinctions are easy to erase when a handler returns only success=true. They are also precisely what the guest needs to know.
Encode urgency rules where they can be tested
The implementation uses urgency-dependent due times and escalation thresholds. These are product operating policies, not universal hospitality standards. Their values belong in a controlled policy surface and should be validated with the client’s team.
An urgency policy can define shorter response windows for emergency and urgent categories and longer windows for ordinary requests. Escalate when the earliest feasible visit falls outside the relevant window. The mechanism compares the actual dispatch result with a configured policy; the model does not improvise an acceptable delay.
Times should carry timezone and date, especially when a guest and the operator are in different locations. “Tomorrow afternoon” is insufficient state for scheduling even if it is appropriate final wording after conversion.
Status updates have a second delivery path
When the backend changes a task’s state, an event can invoke the concierge to compose an update. The backend then owns channel delivery, including messaging templates and delivery rules.
This path needs the task’s facts and the conversation’s issue record: what was reported, what was promised and what the guest was already told. Otherwise a status update can read like a new, disconnected conversation.
The integration must specify which transitions emit updates. Assignment, appointment changes, completion and cancelled work are different events. Test each transition for correlation, content and delivery acknowledgement. A generic “status changed” hook does not establish that every meaningful operational change reaches the guest.
An asynchronous workflow is only accepted at first
Some requests are delegated to a workflow service because they take longer than the conversational deadline. The agent can report that the request was submitted, using the returned workflow identity. Completion requires a later result.
A downstream 422 or failed job must not disappear behind an earlier “started” marker. The workflow needs terminal status, a correlated event and a failure path visible to the operator. If the guest was told to expect follow-up, that commitment also needs ownership.
This is the operational meaning of an AI concierge: it participates in a workflow whose outcome outlives the sentence it generated.
Evaluate the whole chain
The test matrix should vary roster completeness, urgency, existing issues, multiple stays, declined time slots, failed notifications and backend suggestion mode. Check both the tool results and the final claims.
For example, a case with no staff schedule should not pass merely because a task exists. It should verify the fallback owner, escalation decision and absence of an invented arrival time. A proposed task should not be described as dispatched.
The resulting system is more dependable because the mandatory chain is explicit. The model can be warm and concise while the application keeps a precise account of what was—and was not—done.