AI number

Routine inquiries

Repeated questions—opening hours, contacts, order status, delivery terms—get answered immediately without a queue. Your team can focus on expert work and exceptions.

Routine inquiries about your services

Callers get answers about products, services, and pricing in their own language. The AI can use your company context and, where needed, data from your systems so responses stay on-brand.

Absence notifications

Employees can report absences by phone; details can flow to HR or shift planning via webhook or integration. One channel reduces email and chat overload.

Sick-leave notifications

Sick leave can be recorded following your policy: consistent structure, privacy, and the right follow-ups (e.g. to a manager or HR). Less manual call handling for admin.

Data collection

During a call you can collect structured information: feedback, leads, support details, or fields you already track in CRM or ticketing. Summaries and captured data can be delivered to your systems automatically.

Spam calls and content-based classification

The AI can classify topic and intent (e.g. support, sales, suspicious or clearly unwanted) and route handling—or end clearly unnecessary attempts. That keeps queues and staff time off the wrong calls. Exact policies, prompts, and thresholds are agreed during onboarding.

Integration with customer systems (webhook)

Call lifecycle events are sent to your configured `call_webhook_url` as JSON: fields include caller/callee numbers (`caller`, `callee`), `call_id`, `action` (e.g. initiated, ringing, answered, completed), and `context` (state, `collected_data`).

Your endpoint can return HTTP 200 with an `instructions` object: for example `welcome_text_webhook` for the opening, `use_prompt` or `add_to_prompt` to adjust the system prompt, and `collected_data` updates. That lets your backend enrich context and steer AI behavior during the call. Webhook failure or a late response does not drop the call (fail-open). Technical surface: Call Webhook API (see also integration examples on this page).

Example: call center and service menu

The call can start with a classic service menu: for example “For service in Finnish, press 1”, “For service in English, press 2”, and “AI-assisted service—skip the queue, press 3”. On the third path the AI serves in multiple languages, including overnight, can collect and classify a work queue, and write data to your systems via webhook or integration.

You can call the customer back once a human has handled what the AI logged. With deeper integration, some cases can be resolved end-to-end automatically by the AI without a separate manual step—implementation is case-specific.

Scheduling and calendar

On the voice path the model can invoke selected tools—in the documented stack this includes calendar and reservation integrations (`calendar_tool`, `reservation_tool`). Callers can check availability or book a slot; the exact toolset and permissions are agreed during onboarding.

Callback requests and leads

Callers can leave contact details or a callback request; fields can be written to `collected_data` and forwarded via webhook to CRM or sales queues. The AI can confirm details during the call before they are stored.

Transfer to a human

When the case needs a specialist, the call can be transferred to an agent—the same idea as the interactive demo on this page (handoff from AI to human). Routing and policies are configured in the service setup.

Tool calls (function calling) during the call

The model stack may use function calling: tools such as caller details, calendar, reservations, and number lookup (e.g. `caller_info_tool`, `calendar_tool`, `reservation_tool`, `number_lookup_tool`—names and rollout are project-specific). Tool output is fed back into the conversation; answers can be grounded in system data, not only free-form text.

Multimodal voice path and LLM

Calls can be handled on a multimodal voice path (audio ↔ model). Webhook lifecycle `action` events are supported on both legacy and multimodal handling; real-time transcript events and a ready-made summary (e.g. `call.summary_ready`) can be delivered to the same webhook URL. Which language model is used and how it is configured are agreed during onboarding.

Webhook

This follows the Call Webhook API spec: you set one `call_webhook_url` per number and an optional API key. The platform sends `POST` requests with JSON (`schema_version`, `call_id`, `action`, `event_time`, `context`). Call phases are distinguished by the `action` field (e.g. `call.initiated`, `call.ringing`, `call.answered`, `call.completed`, `call.failed`)—same URL for all.

Your endpoint returns HTTP 200 with JSON that may include `instructions` (e.g. `welcome_text_webhook`, `use_prompt` / `add_to_prompt`, `collected_data` merges). That lets your backend inject context and steer behavior without a custom wire protocol. Failed or late responses do not drop the call (fail-open).

During the call the same URL may also receive real-time transcript events (body shape differs from lifecycle actions). When the summary is ready, a separate `call.summary_ready` (or an extended `call.completed`) can be sent to the same URL with transcript and AI-generated summary in `context`.

Summary as JSON

The call summary can also be delivered to a ticketing system or another backend as JSON so the summary can be processed automatically.

URL context during a call

During a call you can use context tied to a URL, campaign, or support ticket: for example where the caller came from on your site or which issue is open when your systems pass that information through. That reduces repetition and helps the AI understand the situation without a long preamble.

Other integrations

Additional connections (REST, middleware, admin workflows) can be implemented case by case. Zapier integration is available under a DPA. The exact API surface and available events are agreed as part of onboarding.