Use cases

Route customer requests before drafting a reply

Proposed design Editorial draft

Customer operations is a practical starting point because the destination and eventual handling are observable.

Customer requests Synthetic demo Proposed design
Queue · synthetic items
    RulesPolicy in code
    JevChoice · Score · Noul
    Frontier LLMDraft only
    HumanAccountable action
    Inputs

    Select an item.

    Jev + rules

    Judgments appear here.

    Outputs

    Tickets, drafts, queues.

    Our proposed workflow asks for a queue suggestion and flags ambiguous cases for review. A separate assistant can draft a reply after the route is established.

    Measure reassignment, time to ownership and customer delay. Avoid using sentiment as a substitute for the actual issue; a polite message can still describe an urgent service failure.

    Expose a narrow business endpoint such as POST /decisions/route-ticket. The adapter selects the question and policy versions; agents cannot lower thresholds or invent destinations.

    During the first experiment, leave the actual queue unchanged so a reviewer can compare the recommendation with normal handling. Include ambiguous tickets and a simulated outage.

    Next step

    Pilot one intake channel with known destination teams.

    Pilot card

    What a first pilot of this decision needs. Proposed design, not a measured result.

    DecisionWhich team should own a customer request before anyone drafts a reply?
    State Jev seesRequest text, product, customer tier.
    Questions
    • Choice Which team should review this request first?
    First action code may takeSet the queue; a draft is only requested once the owner is known.
    Stays with a personThe reply.
    Measure firstCorrect-first-queue rate; drafts thrown away because they went to the wrong team.
    Microsoft surfaceDynamics 365 Customer Service or shared mailbox; Power Automate.
    Out of scopeSending replies.