Kogan.com’s reported customer inquiry automation result is the kind of metric engineering leaders should pay attention to: the company says it automated 67% of inquiries and tripled its true resolution rate using Agentforce across order management, returns, and related support flows. The important lesson is not “AI answered more tickets.” It’s that the workflow was designed around resolution, not just deflection. For teams building support automation, that distinction changes the architecture, instrumentation, and rollout plan. See Salesforce’s summary of the deployment in the Kogan.com Agentforce case study.
Why customer inquiry automation works when it targets resolution
Many support automation projects fail because they optimize the wrong layer of the system. A chatbot that can greet users, classify intent, and cite policy is not necessarily reducing cost unless it can complete a transaction or route the case with enough context to prevent repeat contact. Kogan’s reported jump in true resolution suggests the automation was tied to business actions such as order status lookup, returns handling, and policy-aware responses rather than generic conversational containment.
That matters because support automation sits in a messy part of the stack. Customer interactions often depend on order management systems, return merchandise authorization logic, fulfillment events, refunds, and identity verification. If your assistant can only summarize knowledge-base articles, it will produce a high chat deflection rate and a mediocre customer experience. If it can execute safe, bounded actions, you get measurable operational value.
What engineering teams should copy from this pattern
The production lesson is to treat the assistant as an orchestration layer, not a standalone AI toy. The assistant should retrieve data, call approved services, and fall back to humans when confidence or policy boundaries are exceeded.
Use a narrow action surface
Start with a small set of high-volume, low-risk intents:
Order status and delivery tracking
Return eligibility checks
Refund status and timelines
Address changes before fulfillment
Basic account and policy questions
These are ideal because they are repetitive, well-structured, and easy to validate. They also have clear failure conditions. If the assistant cannot confirm identity or locate the order, it should escalate rather than guess.
Instrument for true resolution, not vanity metrics
Support automation teams often celebrate containment, but containment can hide bad experiences. A customer who gets stuck in a loop was “handled” but not helped. Measure at least the following:
True resolution rate: issue solved without reopening or repeat contact
Containment rate: conversations not routed to an agent
Escalation quality: handoff includes intent, account context, action history, and reason for escalation
Time to resolution: from first message to outcome, not just first response
Post-contact reopen rate: whether the “resolved” case comes back
If you cannot measure post-contact reopen rate, you do not know whether automation reduced work or deferred it.
Customer inquiry automation needs policy, not just prompts
One of the biggest mistakes in AI support design is over-trusting the model to infer business rules. Returns, refunds, and order changes are policy-heavy workflows. They require deterministic checks: date windows, item condition, regional rules, fraud controls, and customer entitlement. LLMs can help interpret the user’s intent and choose the next step, but the final decision must come from systems of record and explicit rules.
A reliable pattern looks like this:
Classify the intent from the user message.
Retrieve authoritative data from CRM, OMS, or returns platform.
Apply policy rules in code, not in prose.
Have the assistant explain the outcome in plain language.
Escalate when data is missing, ambiguous, or risky.
This is where many teams underestimate the integration cost. The hard part is not the model call; it is establishing trustworthy connectors, stable schemas, identity verification, audit logs, and rollback paths for action execution.
Practical rule: if the assistant can change money, order state, or customer identity, the system must be designed like a transactional workflow, not a chat demo.
Common failure modes in production support AI
If you are evaluating a similar rollout, watch for these anti-patterns:
Knowledge-base only automation that cannot act on the account
Loose guardrails that let the model answer outside policy
Fragile integrations with no retry strategy or circuit breaker
Weak escalation design that forces customers to repeat themselves
No red-team testing for edge cases like refunds, fraud, and identity mismatch
Support automation that ignores these issues can create expensive downstream work for agents. In ecommerce, that often shows up as refund disputes, delivery confusion, and angry repeat contacts. The system appears efficient until the backlog of exceptions surfaces.
A rollout framework for CTOs and engineering managers
If your team wants to implement customer inquiry automation in a way that holds up in production, use this short checklist:
Select one workflow with high volume and predictable policy boundaries.
Define a resolution metric before writing prompts or building UI.
Integrate only authoritative systems for order, returns, and refund data.
Keep human handoff visible and preserve conversation context.
Log every action with intent, data source, policy decision, and outcome.
Test failure cases such as stale order status, duplicate returns, and identity conflicts.
Run a phased rollout by intent type, not by all customers at once.
This approach lets you prove value without betting the support org on a single assistant experience. It also gives product and operations teams a clear way to expand coverage after the first use case works.
What this means for technical product leaders
The Kogan.com result is a reminder that AI support tools are becoming operational systems, not just UX enhancements. The winners will be the teams that design for system integration, policy enforcement, and observability from day one. That is more work than deploying a chatbot, but it is the only path to material savings and better customer outcomes.
If you are evaluating your own support stack, start by mapping the top five inquiry types, the systems they touch, and the exact rule that determines resolution. Then decide where AI adds leverage: intent parsing, data retrieval, explanation, or escalation. If you want to discuss architecture choices or validate your support automation readiness, DigitioHub can help you pressure-test the stack before you scale it.