SuperDial

Results go back by API, webhooks, CSV or EHR and PMS write-back, with scheduling system integration, and SuperDial uses EDI and API connectivity where payers support it and portal automation where they do not. On calls, agents authenticate with identifiers such as NPI, tax ID, date of birth, member ID and claim ID.

SourceSuperDial, superdial.com/platform and /voice-agentsread 2026-10-05

Customers build the flow themselves. Scripts are assembled from reusable blocks for IVR navigation, representative questions, follow ups, document requests and escalation paths with conditional logic, and voice, portal, API and EDI channels combine with escalation when one fails. Teams also set disclosure language, voice options, retry logic and policies for each client.

SourceSuperDial, superdial.com/platform and /voice-agentsread 2026-10-05

SuperDial encodes each payer's phone tree, scripts, required inputs and phone numbers (payer resolution in the API) and returns results with source evidence. This is call setup for each payer, and there is no body of knowledge the agent answers from. A managed payer phone book keeps payer numbers with dynamic lookup, and a payer name resolves to a canonical payer record and dialing number.

SourceSuperDial, superdial.com/platform and docs.superdial.com introductionread 2026-10-05

Calls follow deterministic scripts with escalation paths and escalate to staff when they fail or return incomplete data, which SuperDial calls putting human judgment second. An escalation hands the right person a short packet of what was tried, what was captured, what is missing and the recommended next step. There is no approval step before a result is saved.

SourceSuperDial, superdial.com/voice-agentsread 2026-10-05

SuperDial is HIPAA compliant, with SOC 2 Type II controls and BAAs before PHI exchange, TLS in transit and AES-256 at rest, and support for SSO, MFA and customer-specific data controls. There is a Vanta trust center. Customers can also set retention policies and restrict model training on their data.

SourceSuperDial, superdial.com/workflows/patient-calling and /voice-agentsread 2026-10-05

Each workflow returns structured data with source evidence and auditability, a call can be followed through waveform, transcript, extracted fields and final result, recordings and transcripts are kept where permitted, and the portal monitors batch performance. Captured answers carry source metadata, timestamps and confidence scores, and dashboards track outcomes, next steps and completion rates.

SourceSuperDial, superdial.com/voice-agents and /platformread 2026-10-05

The agents keep no memory between requests. Each request carries its own inputs and returns a structured result. Recordings and transcripts are kept where permitted, under retention policies the customer can set.

SourceSuperDial, docs.superdial.com introduction and superdial.com/voice-agentsread 2026-10-05

For customers with stricter requirements, SuperDial says it can support more isolated deployment patterns and governance models, but it names no region or environment and offers no way to choose one. Workflows can be set up onshore or offshore.

SourceSuperDial, superdial.com/voice-agentsread 2026-10-05

A script library offers prebuilt templates for common payer workflows, and packaged workflows cover benefits verification, prior authorization, claim status, credentialing and enrollment, and patient calling, each its own job. Provider data management is listed among the workflows too, and teams can adapt the templates to their own process.

SourceSuperDial, superdial.com/platformread 2026-10-05

Work arrives as API requests, batch submissions or CSV uploads from the customer, results return by webhook, and outbound payer, provider and patient calls follow. No inbound channel or schedule starts the agent on its own, so the customer starts every run. A webhook fires when a request reaches its final state, and retries follow rules the customer sets.

SourceSuperDial, docs.superdial.com introduction and superdial.com/voice-agentsread 2026-10-05

No model provider or model is named, and the customer has no choice of model. Customers can restrict model training on their data.

SourceSuperDial, superdial.com/platform and /voice-agentsread 2026-10-05

A public REST API (bearer token from key and secret) creates single or batch requests, reads results, lists schemas and resolves payer-specific inputs, with webhooks, an OpenAPI spec and a sandbox that tests integrations without placing real calls. The bearer token lasts an hour, results include transcripts, recording URLs and summaries, and each request ends as SUCCESS, PARTIAL or FAILURE. The older Calls API is being retired, and integrations are moving to this one.

SourceSuperDial, docs.superdial.com introductionread 2026-10-05

Pilots validate the script, ROI and exception path before expansion, and teams can see which payers, scripts, identifiers and escalation paths produce the best outcomes. The API sandbox tests the integration, not the agent, and there is no test set or check a change must pass. Dashboards track completed transactions, handle time saved, hold time avoided and escalation rate.

SourceSuperDial, superdial.com/voice-agents and /platformread 2026-10-05

Portal automation is one of SuperDial's named channels alongside voice and API or EDI, so agents act inside payer portals that have no API. It navigates portals, retrieves status, captures documents and extracts fields, though SuperDial does not say how the portals are operated.

SourceSuperDial, superdial.com/platformread 2026-10-05