Broadcasts
Queue Kakao AlimTalk template messages to eligible captured leads with explicit consent and provider readiness.
Queue Kakao AlimTalk template messages to eligible captured leads with explicit consent and provider readiness.
Know the current scope#
The dashboard broadcast feature currently targets Kakao AlimTalk. It is not a general Telegram/WhatsApp/Messenger/Discord campaign composer. A live AlimTalk gateway requires a registered sender profile, approved template, configured platform provider, and a reachable Korean phone number for each recipient.
The recipient count is resolved from non-erased leads on the current site with a reachable contact value, deduplicated by contact. Development/mock mode may accept an email fallback, but a real AlimTalk gateway needs an appropriate phone number. Confirm the displayed mode is live before treating a queued message as real delivery.
Understand the send boundary#
Selecting Send queues one durable job for every currently eligible recipient. The dashboard does not currently provide per-send segmentation, recipient editing, scheduled time, preview audience, pause, or recall. Do not use the button until the entire resolved audience is intended and authorized to receive the message.
The form accepts an approved template code and a body up to 2,000 characters. A provider can enforce a shorter template, exact approved wording/variables, timing, sender-profile, and policy limits. Make Agent Fast queuing does not override those rules.
Prepare a compliant broadcast#
- Confirm the site lead-capture flow requested the relevant contact and consent/lawful basis.
- Remove or erase people who should not be contacted before resolving the audience.
- Confirm a live AlimTalk provider and registered sender key are configured.
- Obtain the provider-approved template code and match the body to that template.
- Verify sender identity, purpose, links, required disclosures, and opt-out path.
- Use a separate test site/audience if you need a small production test; the current composer targets all eligible leads on its site.
Do not send credentials, sensitive account details, protected records, invented personalization, or an offer the agent/site has not approved.
Queue and observe#
After sending, history shows the body, status, intended recipient count, and successful send count. Jobs are idempotent per broadcast and lead so a queue retry should not intentionally create a second copy of the same broadcast/recipient pair.
“Sent” means the configured gateway accepted all tracked sends. It does not prove phone delivery, reading, conversion, or valid marketing consent. Use gateway delivery receipts and business reporting where available.
If some jobs fail, the broadcast retains the latest provider error while successful sends increment independently. Do not create a new identical broadcast until you understand whether the provider accepted any earlier attempts.
API automation#
Use broadcasts:write to create a draft and queue it through the Public API from a trusted server. Preserve idempotency and review recipient resolution/provider readiness. The API cannot make an unapproved AlimTalk template compliant.
Troubleshooting#
| Symptom | Check |
|---|---|
| Send button is disabled | No eligible site leads with a reachable contact |
| Mode shows local/dev | Live AlimTalk provider/credentials are not configured; no real customer delivery |
| Gateway rejects template | Approved template code, body/variables, sender profile, and recipient format |
| Recipient count includes unusable contact | Real delivery needs phone; clean lead capture/data before sending |
| History remains sending | Queue/provider error and sent count versus recipient count |
| Need to contact only a segment | Not currently supported in this composer; create an approved separate audience workflow rather than sending all |
Stop sending when complaints, unexpected recipients, template mismatch, or provider errors appear.