An airline's service copilot offers a recovery before it knows the member tier stored in the customer app. Which design fits?
Select an answer to reveal the explanation.
Short Explanation
A gate agent who has not looked at the boarding pass will hand the wrong recovery to the wrong member. You have the service copilot read the member tier from the customer app before it offers a recovery. Guessing the tier from the tone of the chat skips the record that already has it.
Full Explanation
The member tier lives in the customer app, and the recovery the service copilot may offer depends on that tier. Orchestration here means the service copilot reads the tier from the customer app first and only then chooses a recovery, so the offer matches the membership the airline already stores. The customer app stays the system of record for that tier, and the service copilot does not keep a private tier of its own. Guessing a tier from the tone of the chat invents a status the customer app could have supplied. Offering the same recovery to every member and leaving the tier unread ignores a distinction the loyalty program exists to make. Copying tiers into a side sheet the service copilot does not read, then offering recovery from a fixed script, moves the data to a place the copilot will not use and replaces the tier rules with one script. Exam caveat: reading the tier does not authorize every recovery in the script. The offer still has to stay inside the recovery the tier allows. Operational check: set a test member to a known tier, start a service conversation, and confirm the copilot retrieves that tier before it names a recovery.