What impact would it create if ACS services went down?

What impact would it create if ACS services went down?

⚡Quick answer -

If the ACS (After-Call Services) pipeline is down, live calling, IVR menus, and recordings still work. The impact is limited to post-call automations:

• No After-Call API/webhook pushes → CRM won’t auto-log new calls.

• No After-Call SMS → customers/agents won’t get the usual text alerts.

• Billing/usage and Call-log enrichment (disposition, tags, recording link) are delayed until ACS recovers.

When to use this guide?

Know what breaks vs. keeps working if ACS is down, how to keep operations moving, and how to verify/backfill once service is restored.


What is ACS?

ACS (After-Call Services) is the post-call pipeline that runs right after a call ends. Depending on your setup, it drives:

  • After-Call API (webhook) → pushes call data to your CRM.
  • After-Call SMS → sends messages to callers and/or users.
  • Billing/usage updates → adds call charges/metrics to Billing.
  • Call log writes → stores post-call fields (disposition, tags, recording link).

Prerequisites (for quick diagnosis)

Have these handy before you test/escalate:

  • Client/Account ID and example Call ID/UID, with timestamps (IST).
  • Whether After-Call API and/or After-Call SMS are enabled for the affected flows.
  • Your webhook endpoint URL and whether it accepted other traffic (2xx) during the same window.

What to do now?

  1. Check service health
    • Open your organisation’s Status Page (if available). Note any ACS/automation incidents.
  2. Run a controlled test call
    • Place one short call that should trigger ACS (e.g., a missed call if your rules send SMS/webhook for missed).
    • Record the time, DID, department, and expected action (SMS/webhook/log/billing).
  3. Verify each component
    • Webhook: Inspect your endpoint logs for a POST within ~0–120s of the call.
    • SMS: Check recipient device(s); review Reports/Logs → SMS/After-Call SMS if available.
    • Logs: Open Calls → Logs and filter by last 60 minutes; look for your test call’s disposition/recording link.
    • Billing: Refresh usage after a short interval; note if the test call appears later.
  4. Decide continuity actions
    • If webhooks are down, rely on Calls → Live and create Follow-Up tasks manually or from CRM call lists.
    • Pause time-sensitive exports/BI that depend on ACS fields to avoid partial data.

Backfill & verification after recovery

  1. Spot-check new calls (past 30–60 min) in Calls → Logs; confirm disposition, tags, and recording links appear.
  2. Reconcile CRM
    • Export the outage window from Calls → Logs (CSV) and import to your CRM; dedupe by call_id/UID + timestamp.
  3. SMS catch-up
    • If customer-facing SMS didn’t send, decide whether to send a one-time follow-up (avoid duplicate/confusing messages).
  4. Billing confirmation
    • Ensure usage for the window is now reflected; note any adjustments on the next bill.

Troubleshooting (self-checks)

  • Only some calls are missing? The issue may be rule-specific (e.g., After-Call SMS enabled only for Missed).
  • Webhook shows errors? Your endpoint may be rejecting payloads (non-2xx). Check TLS, auth headers, and rate limits.
  • Duplicate CRM records? Implement idempotency in your CRM ingest (dedupe on call_id/UID).
  • Recording link absent? Large files can appear a bit later than the log shell—recheck after a brief interval.

Escalation (copy-paste email)

To: support@myoperator.com
Subject: ACS outage suspected — [Account ID]
Body:
Account/Company: [ ]
Impacted components: Webhook / After-Call SMS / Billing / Log writes
Example Call ID/UID & time (IST): [ ]
Expected vs observed behavior: [ ]
Webhook endpoint (if used) & HTTP result: [URL | 2xx/4xx/5xx]
Outage window tested (IST): [start → end]
Business impact: [e.g., CRM timelines stale, missed customer alerts]
Attachments: screenshots/log excerpts