Why Your Enterprise AI Sits Unused: From Deployment to Value Operations

Assume a company launches an after-sales ticket assistant that can summarize customer issues, retrieve handling records, cite service policies, and generate reply drafts. Tests pass, training is done, and the first week sees active trial use. A month later, the project team finds that when actually processing tickets, staff still search old records, ask colleagues, and copy historical replies. The AI platform gets occasional logins, but business outcomes show no clear change.

Teams often blame "employee habits" and respond with more training, notifications, or mandatory daily usage quotas. Invocation numbers rise again, yet no one can say which tickets were handled better because of AI.

The core question must be: When employees complete this work, what burden does AI actually reduce, and what new burden does it add?

After technical usability is proven, the enterprise still needs to verify two things: whether employees are willing to keep using the tool, and whether their work improves as a result.

After Acceptance, Still Need to Pass the Employee Test

The iResearch "2025 China Enterprise AI Application Industry Research Report" discusses employee adoption from three angles: psychological acceptance, scenario experience, and capability growth (reference [1]). That framework gives diagnostic direction, but specific barriers must be validated on the ground.

Value operations means continuously observing how employees use AI, fixing obstacles to effective use, and verifying whether work methods and business results actually improve.

It requires distinguishing three levels that cannot substitute for each other:

Exposure: Account opened, training attended, a few questions tried.

Actual adoption: When facing an applicable task, the employee incorporates AI-provided evidence or suggestions into the handling process and verifies as required.

Value realization: The full task shows improvement in time, rework, quality, or customer outcome, without introducing unacceptable risk.

An employee clicking "adopt" may just be meeting a KPI; an employee rewriting most of a draft may still have used AI to locate key evidence. Rejecting an erroneous suggestion after verification is still actual use and should be logged as "used, suggestion rejected," not conflated with never used.

First Find Where Employees Drop Off

Using the ticket assistant example, project staff should shadow an employee through a complete handling process: when they think to use AI, how they input materials, what they verify after seeing results, and which system they return to.

Pay special attention to the moment of "tried then quit." "It's hard to use" is only a starting point; the actionable insight is: "He just reopened three pages to cross-check a single warranty conclusion."

The following diagnostic tool (compiled by the author) can be used for the first adoption diagnosis; multiple barrier types may coexist.

Adoption Barrier Diagnostic Table

Barrier: Not applicable — Evidence: Current tickets rarely fall within the supported scope; main pain points still solved manually. — Priority fix: Reconfirm target tasks and scope; narrow or adjust capability promises.

Barrier: More troublesome to use — Evidence: Repeated system switching, copying materials, re-entering known information, then manually moving results back. — Priority fix: Connect context and results to the ticket node; reduce duplicate input.

Barrier: Don't trust — Evidence: Answers repeatedly wrong, citations don't support conclusions, policy versions unclear, forcing staff to re-check from scratch. — Priority fix: Fix quality issues, show verifiable evidence, provide verification and escalation entry points.

Barrier: Can't judge — Evidence: Can generate drafts but doesn't know which question types must be double-checked or escalated. — Priority fix: Train judgment and takeover using real tasks; clarify usage boundaries.

Barrier: Fear usage consequences — Evidence: Afraid errors fall entirely on themselves, or logs used for undisclosed personal evaluation. — Priority fix: Clarify responsibility division, log purposes, and appeal channels.

Barrier: No sustained benefit visible — Evidence: Veterans faster than assistant, corrections yield no feedback, trial time eats into normal work. — Priority fix: Validate gains by person and task group; allocate learning time and feed back fixes.

Observation must not only include enthusiastic volunteers. New hires, veterans, those who quit after trying, and different shifts may surface different issues. Interviews must allow the answer "I genuinely don't need AI for this task."

After diagnosis, the business owner and product owner jointly pick the single biggest barrier, assign an owner, and define a verification method. Do not turn all six problems into one "keep optimizing the model" ticket.

Make AI Add One Less Step

Suppose handling a ticket requires opening a separate assistant, copying the customer description, adding product model, uploading history, then pasting the generated reply back into the ticket system. Even if draft generation is fast, this path may save no time—especially when staff must still verify policies, correct content, and re-log results. AI effectively adds a step.

Experience can be reshaped around three positions:

Place the entry where the task happens. When the employee opens the ticket, pull existing product info and service records per permissions, show the exact materials used this time. If a purchase voucher is missing, explicitly state what's missing—don't make staff re-enter data already in the system, and don't default to widening data access.

Align output with the next judgment. Staff usually don't need a full after-sales analysis report; they need to know: what is the customer request, does policy apply, where is the evidence, what material is still missing, what can be replied next. Candidate conclusions should appear with their sources for item-by-item checking.

Confirm return to the original flow. Verified content enters the ticket draft; modifications and escalation reasons are recorded at the original node. Refunds, compensation commitments, and external sends still follow existing permissions and approval rules; if service times out or results are unavailable, staff can continue the original process.

Every redesign must answer "which search, copy, or duplicate logging was reduced." If it only adds a more prominent chat window, the adoption barrier likely remains.

Trust Needs Evidence, Concerns Need Arrangements

Employees have two distinct concerns: whether the result is reliable, and what consequences they face after using it. Each requires a separate solution.

Trust in results must be built on reliable performance and verifiable evidence. When the assistant says "meets free repair conditions," it should at least show product identity, applicable policy, validity period, and the record supporting the conclusion. Citations must be checked for actual support; missing purchase vouchers should be flagged as insufficient evidence.

Reasonable trust shows as the ability to allocate verification effort by risk. For verified low-risk summaries, spot-checks under approved rules may suffice; for compensation commitments, policy exceptions, and information conflicts, item-by-item confirmation or escalation remains mandatory. Long usage or high acceptance clicks must not automatically lower review standards.

Concerns about usage consequences require concrete organizational arrangements: how trial and learning time count as work, which actions still need employee confirmation, who handles technical failures, what usage logs are used for, and how role and performance changes are communicated.

If the organization hasn't decided on role arrangements, it should not casually promise "AI will never affect jobs." More credible than slogans is stating what's already decided, what's still pending, and the channels for employee participation and objection.

Nor should "rejecting AI suggestions" be treated as negative behavior. An employee spotting an expired policy and escalating to human may be using the system correctly. Necessary logs can be kept, but their purpose, access scope, and retention period must be declared upfront; adoption analysis should focus on task- and team-level barriers, not simple ranking by personal invocation counts.

Training Must Enable Independent Task Completion

Teaching staff to input questions only solves the entry barrier. The real practice needed is how to judge after getting results.

Ticket assistant training can use three types of de-identified cases: a standard ticket with complete information, a ticket missing vouchers, and a ticket where history conflicts with current policy.

Staff must not just generate replies but also identify evidence, spot gaps, correct errors, and escalate when necessary. Training completion evidence is the ability to independently complete these tasks—not attendance or passing a feature quiz.

Different people need not use the same way. New hires may need step-by-step guidance and policy explanations; veterans may only need fast evidence location and anomaly detection. Forcing veterans through the full guided flow turns assistance into burden.

Business managers must allocate real trial time; product or on-site support handles sticking points, then gradually reduces hand-holding. Only when staff can complete applicable tasks and correctly handle exceptions without the project team's immediate help does capability enter daily work.

Use a Scorecard to See If Work Really Changed

The scorecard first defines: team and task scope, applicability conditions, observation period, current baseline, improvement targets, and quality floor. Applicability scope must be set beforehand—cannot retroactively count only successful tasks; non-use due to permission errors or service timeouts must be retained and attributed separately.

Taking "evidence organization and reply assistance for ordinary after-sales tickets" as an example, the following recording method applies.

Metrics Scorecard

Observation: Task adoption — Metric: Among applicable tickets, count and proportion where AI results were actually referenced in handling. — Prevent misreading: Auto-load and page-open don't count as actual reference; combine handling records with spot checks.

Observation: Sustained use — Metric: Track the same cohort of employees with applicable task opportunities; record task adoption ratio per period and reasons for interruption. — Prevent misreading: Mark leave, role changes, and zero-task periods; two periods of use each once doesn't prove a stable habit.

Observation: Total human effort — Metric: Total manual time per ticket for preparation, search, verification, modification, feedback, and subsequent rework. — Prevent misreading: Measuring only generation time misses work shifted to employees and other roles.

Observation: Verification and trust — Metric: Execution of spot-checks on applicable tickets, compliance on mandatory item-by-item reviews, and errors found in spot-checks. — Prevent misreading: Reduced review time or higher acceptance rate alone cannot prove trust is reasonable.

Observation: Business quality — Metric: Return, reopen, and complaint rates for same-category tickets within the same tracking window, plus count and impact of critical errors. — Prevent misreading: Separate AI-used from non-AI-used tickets; keep denominator definitions consistent and report sample size; faster closure may just shift problems downstream.

Observation: Independent handling — Metric: Cases where applicable tasks are completed, exceptions correctly identified and taken over, without project team shadowing. — Prevent misreading: Continuous rescue by shadowing staff cannot count as employee independent capability.

One card: business owner confirms scope and quality floor; operations staff aggregate records; product and tech explain usage interruptions and system faults. Records primarily come from existing processes; minimal time-motion observation and interviews supplement—avoid making staff fill another daily report to prove AI value.

When comparing, fix task classification and metric definitions; use similar tasks, similar proficiency, and same observation window; where possible, use phased or grouped rollout. Do not directly compare employee-self-selected AI tickets versus remaining tickets—their difficulty may differ. Policy, personnel, or product version changes must be recorded to avoid attributing all concurrent improvements to AI.

For example, if draft time shrinks but verification and rework increase, it only shows generation is faster; if sustained adoption rises while total manual effort per full task falls and reopens/complaints don't worsen, a more credible value signal emerges.

Saved hours can be used for backlog clearance, service improvement, or overtime reduction—but cannot be directly converted into realized cash savings. Full cost-benefit attribution is left for a follow-up article.

Operate One Task First, Then Decide Whether to Expand

This method can start with a small-scale trial covering diverse users and tasks, without prescribing a universal cycle or pass rate.

First, record the baseline. Business owner selects ticket scope; on-site staff observe the full handling process; product team identifies the top adoption barrier, quality floor, and failure fallback.

Then, fix and verify. If the main barrier is missing policy evidence, prioritize adding evidence display and version prompts; if it's duplicate handling, first connect input and draft backfill. Record each change and verify with comparable tasks—avoid simultaneous large changes that make effects unexplainable.

Finally, make the operational decision. Only when sustained adoption forms, efficiency or quality hits preset targets, and other key metrics meet the floor, expand gradually. If willingness rises but results don't improve, keep diagnosing. If quality red lines are crossed, or added burden yields no expected gain, shrink scope, roll back, or stop.

For instance, adding a little verification time that significantly cuts erroneous compensation or repeat complaints may still be worth keeping. Such trade-offs should be evaluated by the business owner against pre-agreed targets—not by a single "must be faster" rule.

Employee feedback must show visible results: who handled the reported issue, what's fixed, what's not yet supported. Whether specific corrections become knowledge or model assets needs separate confirmation and validation—don't treat every edit as a correct answer.

For one-off low-risk writing, personal data organization, or rarely used tasks, a full adoption operations mechanism isn't needed; simple experience and outcome collection suffices. Background AI should mainly evaluate business handling and exception takeover, not apply active employee usage rates.

Most importantly, employees not using it may be a valid conclusion. If the original process is already efficient enough and AI shows no provable gain, stopping the push is an effective operational decision.

Summary

After technical launch, the project still faces a test in employees' real work: did it reduce repetitive labor, make evidence easier to verify, equip staff to handle exceptions, and ultimately produce better results?

Enterprise AI adoption should be built on employees being able to complete work more reliably. Only such sustained use has a chance to turn technical capability into business value.

But this work cannot long rely on the project team's enthusiastic shadowing. The next article will discuss: what responsibilities management, business, HR, platform, and on-site teams should each bear, and who decides when conflicts arise.

References

[1] iResearch: "2025 China Enterprise AI Application Industry Research Report," December 2025, p.28 "Employee-Centric Value Operations," p.29 "Team Talent Role Upgrade." The adoption barrier diagnostic table and behavioral scorecard in this article are methodological summaries; the after-sales ticket case is an illustrative hypothesis and does not represent any project or measured results disclosed in the report.

https://report.iresearch.cn/report/202512/4779.shtml