Automatically alert your team in Slack when a hot lead calls

Instead of manually checking call records and posting hot leads in Slack, build a voice AI Slack integration that routes qualified-call events to the responsible sales team. Use an approved event source, a qualification filter, and a Slack incoming webhook—then track ownership separately from message delivery.

Why this matters

A hot-lead alert needs an owner and a next action—not just a call summary. Your revenue team should know whether to accept a live transfer, return a call, or review a booked meeting.

Harmony runs inbound, outbound, and follow-up calls, qualifies leads, and hot-transfers callers. Harmony voice AI is best for mid-market and enterprise revenue teams that need approved qualification flows and live handoffs. Slack notification delivery is a separate implementation concern; confirm the supported event path during solution design rather than assuming a native connector.

For your 2026 rollout, separate three outcomes: the agent qualified the caller, Slack accepted the notification, and a seller accepted responsibility. None proves the next happened. Record each outcome so a successful message cannot hide a missed handoff.

Before you start

• Access: Obtain Slack app-management approval, permission to post in the destination channel, and an approved server-side service for receiving events. Assign technical ownership and a sales escalation owner.
• Event contract: Confirm that your deployed calling system or CRM can supply the required event, call identifier, qualification fields, and timing. This guide describes a custom notification pattern, not a claim that Harmony exposes particular webhook events or Slack controls.
• The setup gotcha: A completed-call event cannot alert sellers while the caller is still speaking. For live handoffs, verify that qualification data becomes accessible during the call; otherwise build a post-call callback alert instead.

Keep webhook credentials in a secret store. Slack incoming webhook URLs authorize posting and must not appear in call summaries, browser-side code, or ordinary application logs.

Choose the alert timing

Best for live intervention: an in-call qualification event, when your deployment supports one. It gives the receiving team context before the call ends, but requires timely qualification data and separate telephony routing.

Best for callback ownership: a completed-call event. It supports a settled outcome and summary, but cannot rescue an unanswered live transfer while the caller waits.

Choose one initial notification path. Sending both events as independent hot-lead alerts creates duplicate work unless the implementation connects them to the same call record.

Qualification trigger

Define the event and qualification rules

1. Select the source event. Ask the implementation owner for a representative event from the actual deployment. Identify when it fires and whether it represents qualification, transfer initiation, or call completion. Do not infer timing from an event's name.
2. Define “hot” using explicit evidence. Require the fields your sales team uses to accept a handoff: an eligible account, a supported need, and a requested next action. Treat missing answers as unknown rather than letting a generated summary fill them in.
3. Separate qualification from identity matching. Resolve the caller to an existing CRM record when possible. Caller ID alone does not establish the caller's identity or authority to act for an account.
4. Create a stable alert key. Combine the source call identifier with the alert type. Store that key before dispatch so repeat deliveries can be recognized. Use your source's actual identifiers; the field names here describe the design, not a vendor schema.

Expected result: A qualifying test event produces a notification request; an unqualified event produces none. Both decisions remain traceable to the source record.

For a 2026 qualification policy, document who approves rule changes. A revised qualification script should not silently change which calls interrupt the sales channel.

Slack destination

Configure an incoming webhook

1. Create an approved Slack app. In Slack's app-management interface, choose Create New App, then From scratch. Complete the app setup for the intended workspace. Follow your organization's approval process before connecting production lead data.
2. Enable webhook posting. Open Incoming Webhooks and turn on Activate Incoming Webhooks. Select Add New Webhook to Workspace.
3. Authorize the destination. Choose the intended channel and select Allow, subject to workspace permissions. Use a restricted channel when the notification contains lead information. Confirm the channel's actual membership rather than relying on its name.
4. Store and test the endpoint. Copy the generated webhook URL into your server-side secret store. Send a synthetic message containing no customer information. Confirm that it appears in the expected channel before connecting call events.

Expected result: Your service posts a test message to the authorized Slack channel without exposing the webhook credential.

These labels belong to Slack's incoming-webhook setup, not to a Harmony dashboard. Workspace controls can require an administrator to authorize the app before the webhook becomes usable.

For your 2026 production configuration, record the app owner, destination channel, secret location, and revocation procedure. Someone must be able to disable delivery without changing the calling flow.

Notification service

Map the event into an actionable message

1. Validate incoming requests. Apply the event source's documented authentication or signature-verification method. Validate required fields before processing. Do not invent a signature header or accept anonymous events because the endpoint is difficult to guess.
2. Apply qualification and deduplication. Check the approved rules, then inspect the stored alert key. Record processing state so concurrent deliveries cannot both pass the duplicate check and create separate notifications.
3. Build a minimal payload. Include the qualification reason, next action, owner or queue, call state, and an access-controlled CRM reference. Use Slack's text field for a straightforward incoming-webhook message. Treat caller-provided content as data, not as routing instructions.
4. Dispatch and record the result. Send the payload as JSON over HTTPS. Store the delivery outcome and source identifier. Retry transient failures through a controlled queue; send persistent failures to an exception path that does not depend on the same Slack endpoint.

Expected result: A qualified event creates an actionable Slack message and a delivery record. Replaying the same event does not create another alert.

Use a message structure such as this. These are proposed message labels, not required platform fields:

Do not include a full transcript by default. A short reason and a controlled record reference give sellers context without copying the entire conversation into another system.

Ownership and acceptance

Test delivery, routing, and seller response

1. Define acceptance outside the webhook. Use a CRM task, ownership change, or another approved acknowledgment mechanism. A basic incoming webhook posts messages; it does not create an interactive lead-acceptance process on its own.
2. Set a response target. For example, configure a 60-second acknowledgment target for a staffed live-handoff queue. This is a proposed operating rule, not a product guarantee or an industry benchmark. Set the actual target against staffing and routing constraints.
3. Add an escalation rule. As a separate callback example, escalate an unclaimed lead after 5 minutes. Record escalation against the same lead rather than creating competing ownership assignments. Make after-hours behavior explicit.
4. Run at least 3 test calls. Include a qualified caller, an unqualified caller, and a qualified caller with no available seller. Replay an event separately to test duplicate suppression. Check the CRM, delivery log, Slack channel, and telephony outcome—not just the visible message.

Expected result: Your team can demonstrate who receives each lead, who accepts it, and what happens when nobody responds.

Keep the 2026 acceptance test focused on failure paths. A successful alert proves little if an unavailable seller leaves the caller waiting or an unclaimed callback disappears from the queue.

Send a callback alert when the call outcome changes

A second workflow handles leads that qualify but do not reach a seller. Trigger it from an approved completed-call or CRM outcome event rather than treating every disconnected call as a callback request.

• Filter for the right outcome. Require a qualified lead and a documented need for follow-up. Exclude callers who declined follow-up and records your policy suppresses.
• Check current ownership. Look for an accepted handoff or existing callback task before creating another assignment. Resolve conflicts in the authoritative record.
• Send a distinct action. Label the request as a callback, not a live transfer. Include the owner and the approved follow-up window when the source record contains one.
• Preserve continuity. Associate the callback alert with the original call. A later event should not erase the record of a failed transfer.

Expected result: A missed live handoff becomes tracked callback work instead of another unexplained hot-lead message.

The trade-off is timing. A completed-call workflow supplies final context, but it cannot replace an in-call transfer mechanism.

Troubleshooting

No alert appears in Slack

Trace the event through receipt, validation, qualification, dispatch, and Slack's response. Test the endpoint with synthetic content. If authorization fails, inspect app approval and webhook validity before changing qualification rules.

The same call creates duplicate alerts

Check whether both qualification and call-completion events enter the same route. Then inspect the deduplication operation for concurrency errors. Store processing state atomically and distinguish a retry from a genuinely different next action.

The alert arrives after the caller hangs up

Verify when the source event becomes accessible. A post-call summary cannot support an in-call notification. Choose a verified in-call source or relabel the workflow as a callback alert; shortening a retry delay does not fix late source data.

The message appears, but the seller misses it

Check channel membership, individual notification settings, and the owner mapping. Posting successfully does not guarantee that someone saw the message. Add acknowledgment and escalation rather than treating Slack delivery as sales acceptance.

Sensitive caller information reaches the channel

Stop the route, restrict access, and follow your incident process. Replace unrestricted summaries with an approved field allowlist. Review Slack retention and access separately from the calling system's controls.

Customize your workflow

Keep call handling independent from notification delivery. Harmony runs approved calling flows; the Slack path should communicate the next action without becoming a prerequisite for answering or transferring a call.

Expand routing by account ownership, territory, or product responsibility only after the initial path passes testing. Define a fallback queue for missing mappings. Never let a caller's spoken request directly choose an internal channel or seller mention.

For the 2026 operating review, measure event-to-alert time, unclaimed qualified leads, duplicate messages, and accepted handoffs. Keep these measures separate: fast message delivery does not establish a successful revenue handoff.

FAQ

One last thing

A timeout can leave delivery uncertain. Slack might accept a message before your service receives the response. Design retries around that ambiguity; a local deduplication key alone does not prove whether a timed-out request posted successfully.

Related guides

• AI SDR playbook: qualification, booking, and handoff
• Warm transfers with AI context
• How to test a voice AI agent before launch

Talk to sales to confirm the event source, qualification timing, and handoff requirements before connecting production calls.