Frequently asked questions about a Hebrew phone agent

Daber AI is an AI phone agent that answers calls in Hebrew and carries them through to the end, 24/7, over your existing phone lines. It also places outbound calls, answers on WhatsApp, and is available as a browser voice widget on your site. In practice it behaves like a service representative: it finds out what the caller needs, answers out of a human-approved knowledge base, books appointments, pulls information from systems you connected, and hands off to a person when required. Every call ends with a recording, transcript, summary, sentiment, escalation reason and resolution status.

Both. The same agent answers inbound calls and places outbound ones, including full campaigns. Outbound campaigns support automatic retries, a circuit breaker that halts a campaign behaving badly, and optional voicemail detection so a call is not wasted on a recording. Outbound calls are documented exactly like inbound ones — recording, transcript, summary and resolution status.

Yes. The agent books, moves and cancels appointments during the call, against the calendar or system you connected through the API. It can also pull an existing record — a case status or order details, say — and read it back to the caller, rather than only logging a request for someone to handle later. You set the rules: which appointment types, which hours, and when the agent should hand off to a person instead of booking itself.

Yes. The agent recognises a returning caller by phone number and recalls their previous conversations, so it does not make them tell the story from the start. That memory crosses channels: someone who wrote on WhatsApp and later called by phone is recognised as the same person. If a conversation was anonymised at the caller's request, it is no longer included in that memory.

Yes — that is in fact the environment the product was built around. It can be installed at your own site as a full self-hosted deployment, including an air-gapped install, in line with the Israeli government information-security standard (Directive 5.43), and run in AWS il-central-1. Local models can be used so no data leaves the perimeter. On top of that there is Hebrew-aware PII masking, a full anonymisation flow with an audit trail, role-based access and an activity log — plus per-department control of which entity types get masked.

Hebrew is the product's home language, not a translation layer over an English system. A call can run on a speech-to-speech model, where the agent hears and speaks directly, or through a speech-recognition → language-model → speech pipeline, depending on what suits your calls. The infrastructure around the call is built for Hebrew too, including PII detection tuned for Hebrew rather than relying on an English-only model. The only way to be convinced is a test call — ring it from a mobile, not from a quiet office.

The agent is built for spoken Hebrew as it actually sounds, including accents and non-standard speech, and this is exactly what a test call should probe before you decide. We do not publish accuracy percentages, because the real figure shifts with line noise, sentence length and topic. What helps in practice: when unsure the agent asks for clarification instead of guessing, you can interrupt it mid-sentence, and if the exchange is going nowhere it hands off to a person. If most of your callers are a specific audience, ask to hear a test call that mirrors them.

It asks for clarification instead of guessing, and if that does not help it hands off to a person. You define in advance exactly when that handoff happens and where it goes — a cold transfer to a number, or a bridged transfer that dials a specific extension and brings the person into the call. Guardrails also escalate automatically after several consecutive blocks, so a caller never gets stuck in a loop of answers the agent should not be giving. The escalation reason is recorded on the call, so you can see exactly where it happened and fix the script or the knowledge base.

There is noise cancellation tuned specifically for telephony, and it suppresses background human voices, not just ambient noise. That matters more than it sounds: what most often ruins a contact-centre transcript is not air conditioning or traffic but other people talking near the caller, which the agent might otherwise treat as part of the conversation. You can also interrupt the agent mid-sentence, so a caller who already knows what they want does not have to wait for it to finish.

Yes — the agent is not limited to Hebrew and can run in other languages. That said, the product was built with Hebrew as the primary case, and that is what we can commit to with the greatest confidence. If most of your callers speak another language, ask for a test call in that language before deciding, exactly as we would tell you to do in Hebrew. Note that the model selection can differ per language, so it is worth agreeing on that during setup.

It sounds like a conversation rather than a recorded announcement: you can cut the agent off mid-sentence and it stops, and it responds to what was said rather than reading out a menu. The call can run on a speech-to-speech model where the agent hears and speaks directly, which is usually what sounds most natural. That said, we do not promise nobody will realise it is a system — the only way to know whether it clears your bar is to hear a test call, and you can also write the opening line yourself so it matches your tone.

This is not a development project, and the timeline is decided almost entirely by how many systems you want to connect. A basic setup is four steps: define the agent from a call-script document you paste in, load the knowledge and approve it, connect your existing number over SIP or Twilio, and run test calls before sending real traffic to it. Connecting a calendar, CRM or internal systems adds time depending on your side, which is why we prefer to give a timeline only after seeing your list of systems.

Mainly three things: a document describing what a good call sounds like at your organisation, the knowledge the agent needs in order to answer, and the decision about who calls get transferred to and when. The script document can be exactly what you already have — an opening, objection handling, qualifying questions, a close — and we generate a flow from it. Knowledge can arrive as knowledge-base entries and also as a catalogue or price list in CSV or Excel. Finally, the phone numbers or extensions the agent should transfer to when a call needs a person.

From two sources: a knowledge base you populate, and a call flow generated from your script document. You simply paste the script — opening, objection handling, qualifying questions, close — and the system builds a flow with scripted lines and deterministic branching, meaning the agent says exactly what you wrote where that matters. You can also upload a catalogue or price list as a file and the agent will filter and enumerate it during the call. Every change is kept as a version, so you can roll back.

You do. Every knowledge-base entry arrives as a draft and needs human approval before the agent may answer from it — there is no path by which content reaches a live call without someone on your side having seen it. That applies to entries created through the API as well. You can also pin only part of the knowledge to a particular agent, so one agent does not answer out of material meant for another department.

Yes — you upload a CSV or Excel file and the agent can filter and enumerate it on the call. This exists precisely for the questions a plain knowledge base answers badly, such as 'which options do you have in this category?', which require going over all the records rather than retrieving one passage. If the result set is too wide, the agent asks a narrowing question instead of reading out a long list. The raw rows themselves are visible only to admin and reviewer roles, not to every user.

Yes, and without involving us. Changes to the script, the flow or the knowledge base are made from the interface, and every change is kept as a version — so you can see what changed and roll back if something broke. That is a meaningful difference from a recorded phone menu, where every small correction means re-recording prompts and often a third-party vendor.

Yes, and this is the step we most recommend not skipping. You can talk to the agent through a browser voice widget before sending real calls to it, and you can also route only part of your traffic at first — after-hours only, say, or one topic only. Every test call produces the same full documentation as a real one, so you can listen, read the transcript and fix the script before widening.

Yes. The agent connects to your existing lines over SIP or Twilio, and you keep the same number your customers already know. There is no need to replace your phone system and no need to publish a new number. You can also start partially — unanswered calls only, certain hours only, or a single branch of your existing menu — and widen once you have seen results.

Yes. Alongside the multi-tenant cloud service there is a fully self-hosted, on-premise option including an air-gapped install, in line with the Israeli government information-security standard (Directive 5.43), as well as deployment in AWS il-central-1. Local models can be run so that processing of the entire call stays inside your perimeter. For regulated bodies this is usually the deciding question, so it is worth raising in the first conversation rather than at the end.

They are all answered at the same moment. Concurrent calls do not create a queue, because handling does not depend on a particular representative becoming free — which is exactly the difference you feel after an ad, on the day after a holiday, or when something goes wrong and everyone calls at once. If a transfer to a person is ultimately needed, your own availability does apply there, so it is worth defining in advance what happens when nobody can pick up on the other side.

Yes, and you decide exactly when. There are two forms: a cold transfer, where the call moves to a number and the agent drops out, and a bridged transfer, where the person is dialled into the call and joins it. You can set triggers such as a particular topic, a caller asking for a representative, or an enquiry flagged urgent. Guardrails also escalate automatically after repeated blocks, so a caller is never left stuck.

Yes — that is what bridged transfer is for. In a cold transfer the call is handed to the carrier, so no extension can be dialled afterwards; in a bridged transfer the agent dials out itself, waits for an answer, dials the extension, and only then leaves the call with the two people talking. An extension can be set at agent level or at a specific node in the flow, so different topics reach different people.

Yes. The same agent, with the same knowledge base and the same rules, also answers on WhatsApp — it is not a separate product with its own content. Recognition by phone number carries across channels, so a caller who started on the phone and continues on WhatsApp counts as the same person and the earlier conversation is recalled. WhatsApp threads appear in history like any other enquiry.

Yes, there is a browser voice widget that talks to the same agent. That means a site visitor can start talking immediately without dialling and without filling in a form, and you do not need an extra phone number for it. Widget calls are documented in the same history with a recording, transcript and summary, so no channel disappears from the picture.

Yes. You can run an outbound campaign from a list, with automatic retries for people who did not answer. There is a circuit breaker that halts a campaign behaving badly so a fault cannot roll into thousands of calls, and optional voicemail detection so a call is not spent on a recording. Every outbound call is documented exactly like an inbound one, and transfer to a person works there too.

Only the people you allow. Permissions are role-based, and every view or action is written to an audit log, so you can check afterwards who accessed what. You can also set at department level which types of personal information are masked in transcripts, so even an authorised viewer sees no more than their role requires. Access to the recordings themselves is controlled separately from access to transcripts.

The system is built so the agent stops and hands off to a person rather than carrying on guessing. It answers out of a knowledge base where every entry was human-approved, and guardrails block answers that go beyond what was defined — and if blocks repeat, the call is escalated automatically with the escalation reason recorded. On top of that every call is fully documented, so you can listen, see exactly where it happened and fix the flow or the knowledge. Every change is kept as a version and can be rolled back.

Yes — every call is kept with a recording, transcript, summary, sentiment, escalation reason and resolution status. That means you can both listen to an individual call and filter by the metrics to see trends, such as which topics keep coming up or where callers arrive frustrated. Access is role-restricted and every view is written to an audit log, and transcripts are displayed with personal information masked according to the setting you chose.

Every call produces a recording and a transcript, and the transcript is automatically masked for personal information using Hebrew-aware detection. Access to that material is restricted by role, and every action is written to an audit log — so you can tell who viewed what. You decide at department level which entity types get masked, so a sensitive department can mask more than another. There is also a full anonymisation flow for erasing details on request.

Yes, there is a dedicated anonymisation flow for exactly this. You can run it on a single conversation, on every conversation belonging to a particular phone number, or by date range and case identifier. The action erases the caller's details, blanks the personal information inside the transcripts and cuts off access to the recording, and is written to the audit log together with a reference identifier you can quote back to the person. Anonymised conversations also stop being included in returning-caller memory.

That depends on your decision, because the system supports several model providers — including local models running inside your own perimeter. In a fully local configuration no data needs to leave in order for the call to work. In a cloud configuration external model providers can be used, which is usually fine for a commercial business but not for a regulated body. We recommend settling this during scoping, because it also drives the deployment choice.

Yes, and the decision is made at department level rather than only organisation-wide. That lets a department handling sensitive matters mask more entity types than one dealing with general enquiries. The detection itself is Hebrew-aware, meaning it does not rely on an English model that misses Hebrew names and addresses. If you change the setting, historical conversations can be reprocessed so they reflect the new behaviour.

Yes. There is a REST API for two-way integration, signed webhooks that notify your systems of events such as a call finishing, and activity write-back into Salesforce and HubSpot. There is also a remote MCP server, which lets you build and manage the workspace from the LLM client you already use. If your system is not one of the familiar names, integration goes through the API — bring your list of systems to the scoping call.

The price depends on volume and deployment, so we give a written quote rather than a fixed price list — but the pricing model itself is simple and we explain it up front. There are three options: a monthly package with an included hours allowance plus an hourly rate for overage, prepaid credit drawn down as you use it, or pure pay-as-you-go with no package. The choice mostly follows from whether your volume is steady or spiky. Cloud and self-hosted deployments are priced differently, so it helps to tell us up front which you need.

Either — you pick the model that matches your volume profile. On the package model you pay a monthly amount that includes an hours allowance, with an hourly rate for anything beyond it; that suits steady, plannable volume. On the credit model you buy an amount up front and draw it down as you actually use it, with no monthly reset; that suits seasonal activity or campaigns. On pay-as-you-go there is no package at all and you pay only for what was used.