Turn "for <client A> the printers work like X but for <client B> it's Y" into properly
structured intent variations. ATTENDED and admin-only: intent and variation editing is
admin-scoped; if you can't write, do not attempt it — deliver the interview results and
variation table as a spec the admin can apply, and say that's the degradation.
1. Locate or create the base intent: list and open the existing intents to find it; if the
concept doesn't exist at all, build the base (or hand off to intent-builder)
before authoring variations. One intent per concept — if the interview reveals two
genuinely different intents (VPN setup vs VPN broken), split them, don't overload
variations.
2. Interview the admin — short, concrete questions, one dimension at a time:
- Which situations need different answers? (per client, per site, per device model, per
app version)
- For each: what exactly differs — the steps, the contact to call, the tool name, the URL?
- What happens when the differentiating fact is unknown mid-conversation? (ask the user,
or fall back to the base reply)
Capture answers verbatim where they become reply text; don't paraphrase technical steps.
3. Draft the variation set and SHOW IT as a table before touching anything: variation ->
discriminating condition -> arguments it needs -> reply text. Get an explicit "yes".
4. Encode each variation: set its discriminating condition, the facts the intent must
collect (e.g. <client>, <device model>), and the reply text. Keep the base/default
variation as the safe fallback — the reply for "we
don't know which case this is" must be safe for ALL clients; never leave the unknown case
answerless or answered with one client's specifics. Client-specific reply text comes from
the admin's own words or documentation — never invent client procedures, URLs, or contacts.
5. Test plan before activation: for each variation, 2–3 sample end-user utterances plus the
expected variation match and reply; include at least one deliberately ambiguous utterance
that must fall back to default. Walk the admin through it (or run it together) before the
work is done. Apply the changes only after the plan passes. Replies are end-user-
facing: plain, localizable, no idioms, no environment-specific identifiers.
6. Output: the final variation table, the test plan with results, and any follow-ups the
interview surfaced but the admin deferred. Never activate on the member's behalf.
