AI-assisted customer service inside WeChat, QQ or WhatsApp groups is feasible only when an official platform access route exists for your account and group type, and when the job is limited to testable behaviour. Treat platform access as a separate decision from AI answer quality: an access gap can stop the project before model work starts. The brief should settle both before development is commissioned.
Separate the three jobs behind group-chat AI
A proposal that says “AI bot for the group” hides three different jobs. Price and test them separately.
- First response. Acknowledge a new question, collect the order number or account detail, and tell the member what happens next. This needs clear trigger rules and a named owner for anything the bot cannot resolve.
- Answer lookup. Retrieve an answer from approved documents, policies or product notes, and show the source used. The bot should say when the knowledge base does not contain an answer rather than inventing one.
- Human handover. Pass the conversation to a person with context: group name, member question, answers already given and the reason for escalation. Handover is a workflow, not a chat message.
Map each job to a group, a trigger and an owner. If the buyer cannot name the owner, the project is not ready for build.
Confirm platform access before AI quality
Ask the platform first, in writing, which official route exists for your account type and group type: a bot API, a business messaging API or an approved app route, if one is available. Do not accept a vendor’s assurance that “it can be connected” without evidence under your own account.
Unofficial account automation, personal-account scripts or injected clients carry account and data-handling risk. Do not approve that route until the platform confirms it is permitted and your legal adviser has reviewed the implications.
| Decision | Put in writing | How to verify |
|---|---|---|
| Access route | The exact official API or bot route, the account type it applies to and any approval step | Ask the platform for current documentation; require the vendor to show a test group working under your account before contract |
| Group permissions | Who can add the bot, which group types are supported and what admin consent is needed | Run a test on one controlled group with a non-admin member and an admin member |
| Message limits and data access | What the API allows you to send, receive and store | Request the platform’s current limits in writing; test message types the pilot will use |
| Vendor evidence | Prior approval, app review record or sandbox access tied to your account | Ask for a demonstration, not a screenshot from another client |
| Fallback | What happens if access is revoked or the policy changes | Agree a manual-support fallback and an exit plan before build |
Fix scope items in writing
Use a scope table. Each row should be testable, not descriptive.
| Scope item | Requirement to specify | Verification step |
|---|---|---|
| Group whitelist | Named groups and IDs, who can add or remove a group, excluded groups | Vendor shows the allowlist and proves the bot stays silent in a non-listed group |
| Trigger rules | Exact keywords, @mentions, new-member events, reply-to-bot behaviour and per-group switches | Run a scripted set of trigger and non-trigger messages |
| Knowledge sources | Approved FAQ, policy documents, product notes, owner and update process | Test known questions, unknown questions and outdated documents |
| Quiet hours | Time zone, days, after-hours response and emergency contact route | Test a message inside and outside quiet hours |
| Escalation owner | Named role, backup person, handover channel and required context | Trigger a handover and inspect the context passed to the person |
Add a rule for what the bot must never do: quote a price, confirm a refund, promise a delivery date or give legal or medical advice unless those actions are explicitly approved and owned.
Settle message data and retention before storage
Decide what is stored before the first message is processed: raw text, member IDs, attachments, AI prompts and responses, and human handover notes. Record where each item lives, who can read it, how long it is kept and how it is deleted.
Ask the AI provider whether prompts or responses are retained, used for model training or processed in another region. If the answer is unclear, require a no-training or short-retention configuration in the contract. Data protection duties depend on where members are and where processing happens; confirm current requirements with qualified counsel and the relevant authority. Build access roles and deletion into the admin panel and backend rather than handling them by email.
Price from your own message volume
Cost drivers include the number of groups, messages per day, share that triggers the bot, AI calls per triggered message, knowledge retrieval, handover volume, admin controls, monitoring and maintenance. Ask for a quote per workflow and per 1,000 AI requests, plus a monthly support cap.
Here is an illustrative calculation only: 12 groups × 150 messages per group per day = 1,800 messages per day. If 25% trigger the bot, that is 450 triggered messages per day. At one AI call per triggered message and 30 days, the monthly volume is 13,500 calls. Replace every assumption with your own group exports or admin counts, then apply the vendor’s unit pricing. Use the AI API integration quote checklist to compare limits, logs and key handling.
Prove it in a pilot before full release
Run one or two groups for a fixed period. Define pass/fail tests in advance:
- The official access route works under the buyer’s account and approved group permissions.
- Trigger tests produce the expected response, and non-trigger messages stay untouched.
- A labelled set of real member questions receives answers that cite approved sources or correctly refuse.
- Handover delivers context to the named owner, including outside quiet hours.
- Logs show prompts, responses, handover events and cost per group without exposing member data to unauthorised staff.
- A deletion request removes the agreed data from live systems and backups according to the retention schedule.
Do not release all groups until the pilot owner signs the acceptance record.
FAQ
Can we use AI in a WhatsApp group with our existing business number?
That depends on whether an official access route exists for your account type and group type. Ask the platform for current requirements and get written confirmation before allowing any unofficial automation. The vendor should demonstrate access in a test group under your account.
Do we need a mini program or app as well?
Not automatically. The access route and the admin workflow decide the build. If staff need a dashboard for knowledge updates, handover queues and logs, scope that backend separately from the group-facing bot.
What should we give a vendor for a first quote?
Provide the platform and account type, group list and whether groups are internal or customer-facing, estimated messages per day, the official access route or confirmation that it is pending, knowledge sources, escalation owner, retention rules and pilot group. These inputs let the vendor quote the workflow instead of guessing.
To get a useful quotation, share your platform and account type, group count, message-volume estimate, access-route status, approved knowledge sources, escalation owner and retention rules. Manboo Studio can review the access route and scope the AI API integration, admin controls and handover workflow. Discuss requirements with the project details you already have.