Model the service journey before the channel

Start with a customer who reports a delivery failure, asks for a refund, and provides an order identifier. Determine which intent the agent should recognize, which evidence it needs, and which policies constrain the response. A voice channel, web chat, and asynchronous messaging may have different latency and accessibility expectations, but they should not produce contradictory refund authorization rules.

Define channel boundaries separately from business boundaries. The same policy decision can be implemented behind different channel adapters. Maintain consistent case identifiers, authenticated customer context, consent records, and data minimization whether the customer first contacts a bot or a person. This prevents the channel technology from becoming the de facto source of truth.

Decide what the agent may resolve autonomously

An agent may safely answer store hours or retrieve public shipping guidance. It may summarize a case for a representative if the relevant customer records are accessible under the current identity. A refund, credit adjustment, or disclosure of a protected record carries higher consequences and requires deterministic checks or human authorization. Split the process into answer, propose, validate, approve, execute, and confirm rather than one broad “resolve the complaint” action.

The authority boundary should live in the business service, not in a prompt. Even a convincing model response cannot skip a refund ceiling, fraud hold, or regulatory notice. Use the human-handoff guide to design what happens when automation reaches that boundary.

Preserve context at a human escalation

A useful transfer packet includes the customer's goal, authenticated context, channel, case number, evidence already retrieved, actions attempted, reason for escalation, and any warning about uncertain or conflicting information. It excludes unnecessary secrets and the model's private reasoning. The receiving representative needs a concise trace of facts and decisions, not a wall of generated text.

Make escalation triggers measurable: repeated fallback, frustration signals, an action outside the agent's mandate, conflicting policy, missing entitlement, high customer impact, or lack of a valid answer. Test whether routing selects the correct queue and service level, and whether a human can correct the agent's assumption. The transfer should be possible even when a downstream AI service is unavailable.

The handoff contract should include a durable conversation identifier, customer and case identifiers, the reason for escalation, recent validated facts, actions already attempted, and the authoritative knowledge snippets used. A human should not receive a raw opaque model trace as the only context. The contact-center system needs to distinguish an agent suggestion from an approved record update so the representative can see what is proposed and what was actually committed. Retention and redaction rules should apply to the handoff payload.

Design knowledge and tool contracts for service data

A support article may be authoritative for a refund window, but a live case-management system remains authoritative for the customer's current status. Knowledge retrieval should preserve publication version and effective dates; tools should return typed fields with explicit authorization. The agent must not infer customer eligibility from a similar customer record or from a stale FAQ.

Track which data originates in Dynamics 365, which sits in a knowledge base, and which derives from a model. Where agents use customer history, review retention and data loss prevention policies. When two records disagree, design a reconciliation or human review path rather than allowing the model to select whichever text sounds more plausible. The grounding guide describes how to control evidence quality.

Test the end-to-end experience under realistic load

Include a resolved routine inquiry, an escalated refund, an unrecognized account, a policy update mid-conversation, a dropped connection, and a user who switches channels. Verify both the customer's visible experience and the case system's actual state. A success message is not proof that the intended write was committed; read back the business record after a consequential action.

Measure transfer rate, repeated contacts, task completion, policy adherence, handling time, customer effort, and the reasons humans override automation. Avoid a metric that treats every human transfer as failure. For high-risk cases, a timely and context-rich escalation is exactly the correct outcome.

Include a disconnected customer mid-transfer, an unavailable queue, a failed CRM update after a success message is drafted, and a returning caller whose earlier conversation is still open. Voice channels add speech latency and interruption behavior, while messaging channels add long pauses and resumptions. Track containment only when the customer outcome really completed; routing away from a live representative is not a success if the customer later returns because the agent never finalized the task.

Give operations ownership of the complete workflow

A release plan should name who owns prompts and topics, who approves case policy, who operates the channel, and who can disable tool actions. Monitor service incidents and backlog trends, not only agent response fluency. Publish runbooks for authentication failure, integration outage, incorrect eligibility, and unexpected conversation loops.

The architect's work is complete when the service experience remains accountable across agents and people. A customer should receive consistent policy, an agent should be restrained by real access controls, and a human should inherit enough verified context to finish the job without reconstructing the entire conversation.