A company that runs customer, partner and staff conversations inside WhatsApp groups usually has a policy gap before it has a tooling gap. Nobody wrote down who may open a group on the company's behalf, which payloads may circulate, how member phone numbers are handled, or what happens to admin rights on an employee's last day. Without that spec, each group is configured by whoever created it, and the number that gets banned or leaks a member list is the one nobody was watching.
This note reads the 9bot guide on building a corporate WhatsApp usage policy as an engineering document. The guide splits the policy into five domains: roles, content and timing, personal data, moderation controls and offboarding. Each domain can be mapped to a control you configure, monitor and review on a schedule.
Start with the primitives. Ivan Schroll's governance paper (DOI 10.17605/OSF.IO/G6HF9) compares the group architectures a business can choose. Ordinary groups and Business app groups hold up to 1,024 members with unlimited admin roles, but the creator cannot be removed and there is no organisation level record of admin actions. The Cloud API Groups API binds the group to the business number, yet caps it at 8 participants. None of the options combines large customer groups with native organisational control.
That gap is where a governance layer belongs. It does not replace the platform. It runs on an account the company already controls and enforces, on every message, what the policy document only describes.
| Surface | Improvised operation | Policy enforced through 9bot |
|---|---|---|
| Admission | Whoever holds the invite link walks in | Automatic member approval and time based access |
| Payloads | Links reviewed whenever an admin happens to look | Forbidden Links filter backed by a domain whitelist |
| Volume | Repeated posts tolerated until someone complains | Antispam and antiflood |
| Abuse | Admin judges in private, one case at a time | Banned words plus a warning ladder ending in removal |
| Evidence | Screenshots in a personal gallery | Moderation logs, deletion logs and PDF reports |
| Identity lifecycle | Former staff keep admin rights indefinitely | Same day revocation and two company admins per group |
Two rows deserve emphasis. Identity lifecycle is the one engineers underestimate. Admin rights are attached to phone accounts rather than to your directory, so they survive HR events unless a person revokes them by hand. The governance paper adds a sharper edge: when the last admin exits, WhatsApp promotes a random member, who may well be a customer. Keeping two company controlled admins in every group removes that path entirely.
Evidence is the other one. After an incident, compliance will ask what was removed, when and under which rule. The guide points to the Moderation area, the deletion logs and the Moderation tab inside Reports, which breaks down, for a chosen period, the spam and links that were blocked plus the warnings and punishments issued. That is a record you can hand to an auditor instead of a reconstruction from memory.
Treat a banned operations number as an outage with no failover. The guide is careful on this point. The WhatsApp Terms forbid unsolicited bulk messaging, bans tend to correlate with complaints from users and with unusual patterns of automated sending, and no tool can promise immunity. What a policy can do is reduce the signals that trigger reports:
Each of those lines can become an indicator tracked per number. Company posts per group per day, links removed per week and joins approved through filters are values you can chart the way you chart error rates for a service. When one number drifts, you know which group to inspect before a member reaches for the report button.
Policy text and enforcement should move through the same review cycle. Writing the controls as a versioned file lets legal approve the exact artifact that operators deploy, and turns every policy change into a diff. The structure below is a reference for your own repository, not a 9bot import format. Every key corresponds to a control the guide names, and the bracketed values are yours to fill.
policy_id: corp-wa-usage
scope: every_group_created_or_managed_for_the_company
roles:
owner: department_manager
administrators:
min_company_accounts: 2
numbers: company_controlled_only
moderators: support_team
reviewer: legal_or_dpo
enforcement_agent: 9bot_on_company_number
admission:
member_approval: automatic_with_filters
time_based_access: enabled
content:
links:
default: deny
allow_domains: ["<company domain>", "<approved partner domain>"]
antispam: true
antiflood: true
banned_words_list: "<list reference>"
third_party_promotion: deny
schedule:
company_post_window: "<start>-<end>"
days: "<days>"
enforcement:
ladder: [notice, notice, final_notice, removal] # 9bot default, adjustable
offboarding:
revoke_admin_role: same_day
data:
export_approval: "<team>"
export_location: "<location>"
retention_after_exit: "<period set by legal>"
review_every: "<period>"
The principle you apply to service accounts applies here too. A moderation tool acts with the permissions of the connected account, and the governance paper notes it cannot remove a group's creator, so scope it to the company number and to the groups in your register. Exceptions to the link filter should be explicit entries in the config, visible in review, rather than habits nobody can audit.
Admin accounts are privileged identities. The paper on admin account takeover (DOI 10.17605/OSF.IO/HZUN5) describes how a single shared verification code hands an attacker every group that person administers. The paper on scams (DOI 10.17605/OSF.IO/CYP2G) shows why that matters commercially: a hijacked admin can post a Pix payment request to the whole customer base with the group's credibility attached. Two step verification on every admin account belongs in the policy, not in a wiki.
The data protection paper (DOI 10.17605/OSF.IO/ZG9U7) argues that a business group falls under the LGPD and the GDPR even when it runs on an employee's phone, and that members seeing each other's numbers is a structural property of groups. The usage policy turns this into four questions the config must answer: the purpose of each group, who is allowed to pull a member list or chat export and where it is stored, how fast data about people who left is deleted, and how a member requests removal. For collection limits, see what a group admin can legally collect.
Once the policy is configuration, run it like infrastructure. A weekly health check can confirm that every registered group still has two company admins, that the link filter is active and that the last review date is inside its interval. Policy changes can be rehearsed in a test group before rollout, so a new banned word or domain rule never surprises a live customer group.
A usage policy that lives only in a PDF behaves like a firewall rule nobody deployed. Bind each clause to a control, version the configuration, make offboarding a same day event and keep the logs. 9bot is the execution layer for that model: an independent, paid product with a 7-day trial, with no affiliation to Meta. The guide states that it is not legal advice, so have your legal team validate the final wording.