The Three Things Clients Care About Most During AI Project Acceptance

Last month, I helped a logistics company conduct acceptance testing for an AI-powered intelligent dispatch system. The technical team prepared a polished demo featuring real-time route optimization, anomaly alerts, and automatic order assignment, all flowing seamlessly. The client watched for ten minutes, asked three questions, and the project stalled for two weeks.

These three questions had nothing to do with algorithmic accuracy.

First: Who Do We Contact When Things Go Wrong?

The client’s exact words were: “If the system crashes in the middle of the night, who do I call?”

Initially, we provided a WeChat group containing the project manager, backend developers, and algorithm engineers. The client felt this was insufficient—some people in the group didn’t reply, while others replied but couldn’t resolve the issue.

What we did instead: We created a one-page “Incident Response Handbook” clearly outlining the handling paths for three types of issues. P0 incidents (system unavailable) received a phone response within 30 minutes; P1 incidents (functional abnormalities) received a ticket response within 2 hours; and P2 incidents (user experience issues) were resolved within 24 hours. Each level was mapped to specific contacts and escalation paths.

Seeing this document, the client visibly relaxed. What they wanted wasn’t just “someone,” but “a process.”

Second: What Happens If Data Issues Arise?

The client asked: “If the AI assigns an incorrect route, causing the driver to travel an extra 200 kilometers, who is liable?”

This is a question of liability boundaries. Our initial design gave the AI full decision-making authority, with humans only responsible for confirmation. However, the client was concerned: if an AI judgment error leads to financial loss, how is responsibility allocated?

What we did instead: We changed the system from “AI Decision-Making” to “AI Recommendation + Human Confirmation.” Critical operations (such as cross-district dispatching or reassigning overdue tasks) required manual click-to-confirm execution. Additionally, the system logged every discrepancy between AI recommendations and human decisions to create an audit trail.

This change cost the technical team an extra three days, but the client signed off on the spot during acceptance.

Third: Can We Make Changes in the Future?

The client asked: “If I want to add a new feature in three months, such as assigning routes based on driver preferences, can you still modify it? Or will we need to go through a new bidding process?”

This reflects concerns about vendor lock-in and technical debt. After many AI projects are delivered, clients discover that the codebase is a tangled mess, maintainable only by the original team.

What we did instead: Along with the delivery, we provided an additional “System Architecture Overview” and “Secondary Development Guide.” These weren’t dozens of pages of fluff, but truly usable documents—including API interface lists, database table structures, input/output formats for core algorithms, and code examples for common feature extensions.

Summary

For AI project acceptance, technology is merely the entry ticket. What clients truly care about is: having someone accountable when problems arise, clear boundaries for liability, and the ability to extend the system for new requirements.

Next time I handle an AI delivery, I will clarify these three points during the requirements phase, rather than trying to patch them up at acceptance. Because trust isn’t built through demos; it’s built through processes.