How to Build an AI Customer Service Ticket System: Auto-Reply Bot Development and Human Handoff Testing

Disclaimer: This article is for technical education and demonstration only. It is not professional or financial advice. Any real-world deployment must comply with applicable laws and regulations.

I recently helped a client in online education deploy an AI customer service system with built-in ticketing. A friend handed me the full production-ready source code, saying it had already been through one round of bug fixes—there used to be issues in the ticket result push and the bot module. It took me two days to get everything running end to end, and I’m writing down the process along with the pitfalls I hit, so anyone building this themselves can save some time.

Hands-On Testing: Can the Bot Actually Hold Up?

Auto-Reply Bot

The bot is the core of this codebase. You configure a keyword library in the admin panel, with support for both exact matching and fuzzy matching—the fuzzy side uses word segmentation plus weighted scoring, and in my tests the hit rate was north of 80%. When a visitor asks “how do I request a refund,” the bot first replies with a standard script, then attaches a ticket submission entry point. I ran over 300 simulated conversations; false triggers weren’t frequent, but when synonyms aren’t fully configured the bot goes off-topic, so the keyword library needs to be fed and refined over time.

Ticket Flow and Result Push

What used to give the client the biggest headache was the result notification part—once a ticket is resolved, the system has to automatically push the outcome back to the user. The fixed version runs on a Redis queue plus WebSocket push, so users get the resolution without refreshing the page. I ran a load test: 200 concurrent users submitting tickets at the same time, the queue didn’t back up, and push latency stayed under one second. One thing to watch: WebSocket needs its own port. If you’re on the BaoTa panel (aaPanel), remember to open it in the security group, otherwise the frontend just spins forever.

Human Handoff

When the bot can’t answer, or the user taps “talk to a human” a few times in a row, the conversation automatically routes to a live agent. The admin panel shows a list of sessions in progress, so it’s clear at a glance who is handling what. Outside working hours you can switch on a leave-a-message mode and batch-process everything the next day—very friendly for a two- or three-person team.

Deployment Notes: The Environment and the Pitfalls I Hit

The stack is Nginx with PHP 7.4, MySQL 5.7, and Redis 6. The source is written in ThinkPHP, so make sure you pick the thinkphp rewrite rule for pseudo-static URLs, or every admin route will 404.

Three Pitfalls You’re Almost Certain to Hit

First, don’t keep the default database table prefix in the installation wizard—change it as a basic security measure. Second, the Excel import for the bot’s keyword library must be UTF-8 encoded; my first attempt used GBK and everything came out garbled, so I had to drop the table and re-import. Third, scheduled tasks need to be hooked into crontab—they handle automatic escalation of overdue tickets and the daily data summary. Adding a shell script in BaoTa that runs once a minute does the job.

The admin controls are finer-grained than I expected: role permissions go down to the button level, so a support supervisor can view statistics but can’t edit the reply scripts. Multi-language support covers Simplified Chinese, Traditional Chinese, and English—you add entries yourself in the lang directory. The source also ships with a payment interface module; my suggestion is to enable only subscription billing scenarios and switch every other channel off. Just enough to cover what you actually need.

Tip: Before going live, wipe all demo data thoroughly, especially test tickets and conversation logs. Run the bot’s reply scripts as a limited gray release for a week first, and only open it up to everyone once the hit rate stabilizes above 85%. Don’t let the bot take on every user from day one.

Who It’s For and Tips for Secondary Development

This setup suits three kinds of people: e-commerce or online education operators who want to ease the load on human agents; outsourcing teams that need to hand a client a working customer service system fast; and students using it for a graduation project or as practice for secondary development.

Secondary development isn’t hard. The bot’s response logic is all wrapped under app/service, so adding a new response strategy is mostly a matter of modeling your class after the existing ones. I added a WeCom (Enterprise WeChat) webhook along the way that posts a group notification whenever a ticket escalates—the whole thing took under an hour. The API documentation is rough, but the route naming is tidy enough that reading through the controllers gives you a clear picture of the structure.

FAQ

Q: What server specs do I need?
A: For a site with under 1,000 daily active users, 2 cores and 4GB of RAM is plenty. The key is giving Redis enough memory—512MB as a starting point, since both the queue and the session cache sit on it.

Q: What if the bot’s answers aren’t accurate?
A: Start by checking keyword library coverage. Export your support team’s chat history as corpus material, prioritize synonyms for the twenty most frequent questions, and the hit rate will climb noticeably.

Q: Can it connect to a WeChat Mini Program?
A: Yes. The source reserves an interface layer for this—just write an adapter to convert the message format. The WebSocket push logic doesn’t need any changes.

Q: Can this system be used commercially?
A: Deployment and use must comply with all applicable laws and regulations, and any unlawful use is prohibited. Before commercial use, confirm the licensing scope of the source code.

Disclaimer: This article is for technical education and demonstration only. It is not professional or financial advice. Any real-world deployment must comply with applicable laws and regulations.

#AI customer service #ticket system #auto-reply bot #source code deployment #deployment notes