AI Concierge Conversation Design

Overview

Sojern's AI Concierge is a conversational product inside Sojern's Guest Experience Platform, giving hotel guests a 24/7 way to get help over chat, SMS, WhatsApp, and Meta Messenger, everything from property information and amenity hours to service requests, upsells, and issue reporting. It sits alongside Sojern's Guest Marketing Suite and Reputation Manager as one of the ways the platform reduces front-desk load while keeping guests engaged before, during, and after their stay.

The Concierge had shipped and was live, but it had grown one use case and one prompt file at a time, with no shared design foundation underneath it. I led the work to build that foundation: a persona, a set of language mechanics and guiding principles, and a library of reusable script templates for every core conversational flow. I then audited the live product against that foundation to see how far it had drifted, and, rather than hand over a static recommendations document, built a custom AI skill that lets any designer generate on-spec scripts or review dialogue against the guide going forward.

Problem

The Concierge's dialogue had been written use case by use case, by whoever was building that feature at the time. There was no single reference for tone, no shared vocabulary for common conversational moments, how to soften a rejection, how to recover from a misunderstanding, how to hand off to a human, and no distinction between how the agent should behave in chat versus voice. Every prompt file was, in effect, its own persona.

That mattered beyond consistency. Without a shared mechanics library, entire categories of guest experience were simply missing: what happens when a guest goes quiet mid-conversation, what happens when their session times out and they come back, what happens when the system has no data to answer with. These aren't edge cases for a guest-facing concierge, they're moments that happen constantly, and each one left unhandled was a guest either repeating themselves, hitting a dead end, or getting an answer that didn't sound like it came from the same product twice.

Research & Foundations

I grounded the work in best practises from Google and the Conversation Design Institute and created Sojern's own company-wide conversation design guide, and used both to define what "on-brand" should actually mean for this use case. The Concierge is deliberately treated as an extension of the property rather than a separately branded product, so, while Sojern has a company-wide agent identity for other virtual agents, I made the call to keep this persona nameless by design, expressed entirely through tone and behaviour rather than a name or introduction.

That persona rests on five traits: calm and direct, globally neutral, useful above all, consistent across channel and time of day, and trustworthy enough to say "I don't know" rather than guess. It uses they/them pronouns throughout, drops emoji entirely on voice, and never over-apologises, over-explains, or performs enthusiasm it doesn't need to.

Language Mechanics & Guiding Principles

Persona alone doesn't produce consistent dialogue, it needs mechanics underneath it: the small, repeatable structures that govern how the agent responds in a given moment, regardless of which use case it's serving. I defined the core set the Concierge needed: pre-expansions before answering, acknowledgements when moving between topics, closed-choice alternatives for presenting options, a three-attempt repair ladder for misunderstandings, and a four-step escalation structure, acknowledge, set expectations, summarise context, hand off, so a guest never has to repeat themselves to a human after being passed along.

Underpinning all of it are guiding principles the dialogue is checked against: write as spoken language, frame everything from the guest's side ("your booking is confirmed," not "I've gone ahead and confirmed it"), lead with brevity, always soften before a rejection, vary repair wording across attempts, escalate by the third no-match, treat the acceptance step as non-negotiable before closing, and keep the copy free of hedging, jargon, and unearned enthusiasm.

Script Templates & Conversation Flows

I built four reusable templates and eight fully scripted flows so that no new use case starts from a blank page. Templates 1–4 form the base pattern every conversation follows; Flows 5–12 cover the situations that sit outside a clean happy path, the moments the original product had never designed for.

The concierge persona reference, core traits, pronouns and voice, Do/Don't examples, and opening/closing style by channel.

Templates 1 and 2, the base conversation script structure and the happy path flow every use case starts from.

Templates 3 and 4, the three-attempt repair ladder and the rejection/escalation flow for when a request can't be fulfilled.

Flows 5 and 6, handling a guest pivoting mid-conversation, and the no-input sequence for when a guest goes quiet.

Auditing the Live Implementation

Once the design foundation existed, I audited the production Concierge against it, a structural, prompt-level review of every agent's language against the persona, mechanics, and guiding principles, rather than a live-conversation test.

What I found

• Persona had drifted structurally, not just stylistically. The live product used a warm, emoji-forward, named persona, the direct opposite of the calm, neutral, nameless specification. Six separate prompt files each authored their own version of tone, several of them contradicting one another.
• Content quality was strong; conversational mechanics were largely absent. The bot rarely fabricated answers and escalated cleanly when data was missing. But the session-level mechanics the new guide called for, no-input handling, the three-attempt repair ladder, proactive push, session-expiry messaging, didn't exist in the code at all.
• Some mechanics existed, but only per use case. Disambiguation and rejection handling were partially built for specific scenarios rather than as a reusable, general-purpose pattern.
• Channel wasn't a concept the code understood. "Channel" was passed through as an inert label with no logic attached, so none of the chat-versus-voice rules in the guide had anywhere to attach to.

What I recommended

I prioritised the fix as an architecture problem, not a copy-editing one. The two blocking decisions, settling the naming question and establishing one shared persona module, needed to land first, so prompt rewrites wouldn't have to happen twice. Behind that, I proposed restructuring the six independent prompt files into layers assembled at build time: a single persona core, a channel-overlay layer for chat/voice deltas, a shared mechanics library exposing functions like repair_ladder(), rejection(), escalate(), and disambiguate() so every agent calls the same logic instead of reinventing it, and a session-and-timing layer to finally implement no-input handling, session-expiry routing, and proactive push as code rather than static text. I also recommended a lightweight governance layer, a prompt-linting check in CI against a banned-phrase list, and persona-consistency assertions added to the existing evaluation suite, so the drift this audit found doesn't quietly re-open next quarter.

The structural audit, persona and tone findings on the left, a flow-by-flow comparison of Templates 1–4 and Flows 5–12 against the live implementation on the right.

Scaling the Work: A Custom Design Skill

A guide and an audit are both static the moment they're finished, the next designer to write a new use case, or the next reviewer checking a script, has to already know the rules to apply them. To close that gap, I built a custom AI skill that encodes the full conversation design knowledge base, Google and Conversation Design Institute methodologys and Sojern's guiding principles, as a working tool rather than a reference document.

The skill reviews pasted dialogue line by line against the eight guiding principles and returns specific rewrites, generates new scripts against Templates 1–4 for a use case that doesn't exist yet, flags gaps in a flow before a designer starts building it, and can produce a formatted template document in Sojern's standard layout. In effect, it turns the audit's recommendations into something a designer or engineer can run against their own work today, rather than a set of rules that live in a doc until the next audit.

Deliverables

• A nameless, tone-based persona spec, traits, pronouns, register, and a Do/Don't reference, for chat and voice.
• A shared language-mechanics library and eight guiding principles, covering repair, rejection, escalation, acknowledgement, and disambiguation.
• Four conversation script templates and eight scripted flows, each with sample dialogue and a flow diagram.
• A structural audit of the live implementation, with findings organised by severity and a prioritised, sequenced set of architectural recommendations.
• A custom AI skill that generates on-spec scripts and reviews existing dialogue against the guide, so the design foundation stays usable after handoff.

Outcomes

This work is currently in progress with engineering: the persona and mechanics decisions are agreed, and the layered prompt architecture is being scoped against the audit's priority order, starting with the two blocking items, the naming decision and the shared persona module. I'll update this case study with results once the rebuilt prompt layer and governance checks are live.

Reflection

The most useful move here was treating tone as an architecture problem rather than a writing problem. It would have been easy to hand over a persona document and call the design work done, but the audit made it clear that the reason six agents sounded different wasn't a lack of guidance, it was that there was nowhere for shared guidance to live in the codebase. Diagnosing that before proposing a fix meant the recommendation was a restructuring, not a rewrite.

Building the skill mattered just as much as the audit itself. Design guides decay the moment they're finished, because the next person under deadline pressure won't necessarily go looking for them. Turning the guide into something that actively reviews and generates dialogue means the standard travels with the work instead of sitting next to it.