> For the complete documentation index, see [llms.txt](https://docs.voiceb.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.voiceb.ai/product-updates/september-2026-voiceb.ai-product-release.md). # September 2026 — VoiceB.ai Product Release By Alex Bisbe. Oct 6th 2026 September moved VoiceB from evidence to self-service. August proved the outcome: the form confirmed the sale, the drawer played back the call. September puts that proof in front of the client — on a dashboard they shaped themselves, in their own language, bound to their own live data — and lets Agent Studio build the campaign around it: CRM mapping, call transfer, data collection, form tracking, all configured from a conversation instead of a settings screen. September also closes the last gap between the agent and the client's systems. Agents can now call APIs that sit behind expiring tokens and OAuth logins, with credentials stored per campaign and never exposed to the model. And outcomes were redesigned so that every call lands in exactly one bucket, with a new **Closed** outcome for sales confirmed inside the call. The objective: a platform the client can read without us, and a campaign the operator can build without engineering. Releases covered: Voiceb App 1.4.3 → 1.5.3 and Infra 1.0 (Sep 2 – Oct 1). ## 🚀 Key Highlights **Custom Dashboards (1.5.0)** — a new Dashboards section, built by prompt in Agent Studio and rendered live from account data. Org-scoped, multi-select campaign and agent filters, VoiceB theme, client logo. **Agent Studio configures the campaign** — new tools to set up CRM/integration field mapping, live call transfer, Data Collection schemas, Form Step Tracking and the Valid/SOLD tag toggle directly from chat. Agent Studio and Tools are out of beta. **Credential store and auth proxy for agent tools (1.5.2)** — tools can call customer APIs behind OAuth2 or custom-login tokens. Credentials are stored encrypted per campaign and resolved server-side; the LLM never sees them. Webhook integrations use the same store (1.5.3). **Outcome routing redesigned (1.5.1)** — Customer Care as an independent gate, Dropped based on content rather than duration, and a new **Closed** outcome for payment or signature confirmed in-call. **Multi-language agents** — one agent, 2+ languages and 2+ voices. One script, one set of tools, one number per market. **UTM passthrough** — `utm_*` parameters captured by the widget travel with the call and land as mappable properties in HubSpot and Salesforce. ## ✨ Custom Dashboards — Reporting Inside the Product Until now VoiceB had no client-facing dashboard a client could shape to their own reporting needs. CS produced genuinely good analytics for clients — but as one-off HTML files generated in Agent Studio, delivered outside the product, with hardcoded numbers. The client couldn't open them inside VoiceB, change the date range, or see the data behind them. On enterprise opportunities this had become a commercial blocker: the single biggest objection to replacing an incumbent orchestration layer was the Power BI reporting built on top of it.
Dashboards productises what CS was already doing — the same prompt-driven generation, but living inside the app, bound to live account data. **Dashboards section in the left nav** — directly below Agent Studio. Lists the dashboards available to the current user for the current organization. Org-scoped by default, with optional per-user dashboards; org isolation is as strict as everywhere else in the platform. **Built by prompt in Agent Studio** — describe the dashboard you want in natural language, or attach a reference HTML or screenshot to replicate. Claude generates the panel set, layout, chart types, metric definitions and the data query behind each panel. Saving publishes it to the Dashboards section; edits are conversational and versioned rather than silently overwritten. **Global selectors on every dashboard** — time range with presets and period-over-period comparison, campaign (all, one or many), agent (all, one or many). Selector state is encoded in the URL, so a view can be sent to a colleague as a link. **Live data binding** — panels query the account's own calls and leads from the database. No uploaded files, no pasted numbers, no manual refresh. Metric definitions are central and consistent across dashboards: "sold" means the same on every one. **Panel vocabulary** — KPI strip, outcome mix and profile-type mix by campaign, not-eligible rate with sub-reason breakdown, retry effectiveness by attempt number, widget funnel and CTR, call-to-sale rate, call timing by time of day, average duration by outcome, local language vs. English calls, plus CollectedData-backed panels (not-eligible reasons, business line, UTM source). **Theme and branding** — dark/light theme in the VoiceB palette, with the client's logo where the account has one uploaded. Dashboard UI language is configurable, so an account can see its own dashboard in Spanish, English or any other language. Agent Studio → Image: Dashboards section — global selector bar, KPI strip and outcome mix by campaign ### Why this matters A client that cannot see their numbers inside VoiceB builds them somewhere else, and whatever they build them on becomes the system they won't replace. Dashboards make VoiceB the reporting layer, not just the execution layer — and it does so without a BI team, because the dashboard is generated the way everything else in VoiceB is now: from a prompt, against real data. | Before September | With Dashboards | | --------------------------------------------------- | ----------------------------------------------------------------------- | | One-off HTML reports generated by CS, sent as files | Live dashboards inside the product, per account | | Numbers hardcoded at generation time | Panels query the account's calls and leads on every load | | Fixed date range, fixed campaign | Time, campaign and agent selectors on every dashboard, shareable by URL | | Built once, rebuilt by hand on change | Edited by prompt in Agent Studio, versioned | ## ✨ Agent Studio Builds the Campaign — Not Just the Agent Agent Studio could already write the script, pick the model and run the agent. For everything around the agent — which CRM fields to map, where to transfer a call, what data to collect — it could only explain the steps and send the user to the relevant settings screen. September closes that gap: the configuration itself is now a tool call. **CRM / integration field mapping** — map collected fields (`full_name`, `email`, `tax_number`…) to HubSpot, Salesforce or webhook properties from the chat, instead of from the Integrations section. **Live call transfer** — configure the destination, business hours and trigger condition for a transfer to a human agent directly in conversation. **Data Collection Schemas** — create the schema of fields the agent must collect, without leaving the chat. **Form Step Tracking** — configure the form steps the widget listens to (the completion → SOLD mechanism shipped in August) from Agent Studio. **Valid / SOLD status on tags** — toggle whether a tag counts as a valid or sold outcome via tool. **Filter and list calls by tag** — Agent Studio can now return the calls behind a tag (e.g. the 138 calls tagged "CUPS sin datos"), not just the count. Tag-level audits and targeted reviews no longer require opening calls one by one. **Agent Studio and Tools out of beta** — both sections drop the Beta label. **Resume last conversation** — re-entering Agent Studio picks up the previous conversation automatically. Agent Studio → · Form Step Tracking → · Tool execution modes → ### Why this matters Every setting that can be configured from a conversation is a setting that doesn't need an onboarding engineer. The workshop-style onboarding we run with clients — build the agent live, in front of them — now extends to the integration and the transfer logic. The agent, its data, its CRM mapping and its hand-off to a human can all be set up in the same session, by the same person, in the same place. ## ✨ Credential Store & Auth Proxy — Agents Behind the Client's Login Voice agents need to call customer APIs mid-conversation: CRM lookup, order status, booking. Those APIs are usually behind a short-lived bearer token from a token endpoint — OAuth2 client-credentials or a custom login POST. Until September a Tool could only carry static headers, so an API with an expiring token was simply unreachable.
**Campaign credential store** — credentials are configured per campaign in the UI: token URL, credentials, and how to read the token out of the response. Stored encrypted. A tool references a credential by key, and the proxy resolves it at call time as campaign + key — one tool definition works across campaigns, each hitting the same API with its own credentials. **"Use auth proxy" toggle on the tool** — when enabled, the tool is published to the voice provider pointing at VoiceB's proxy instead of the customer's API. The agent calls the tool exactly as before; VoiceB resolves the credential (cached or refreshed), builds the real upstream request server-side, and returns the response. **The real request never comes from the LLM** — upstream URL, method and headers are read server-side from the stored tool definition, never from the agent's payload. A prompt-injected agent cannot redirect the client's credentials to an arbitrary URL. The LLM-facing schema is byte-identical whether the toggle is on or off. **Response filtering** — the proxy can filter the upstream response down to the fields the agent needs, so a 1.5 MB API body becomes a response the model can actually use. **Webhook integrations use stored credentials (1.5.3)** — the webhook integration settings now offer a dropdown: send a fixed token (today's behaviour) or use one of the credentials stored for the campaign. Customers whose systems require a token-based login, not a fixed API key, can be integrated via webhooks without manual token rotation and with no secrets shown in the UI. Tool execution modes → · Data Journey, Storage & Security → ### Why this matters The enterprise APIs that matter — telco order systems, energy CRMs, insurance policy lookups — are never behind a static key. Before September, "the agent can call your systems" came with an asterisk. Now it doesn't, and the security model is the one an enterprise security team expects: credentials at rest encrypted, scoped to the campaign, resolved by our server, invisible to the model. ## ✨ Outcome Routing — One Call, One Outcome Analysis across five client accounts found that the old classification was misfiling a large share of calls: in some accounts only 4% of "Not Interested" contained a stated rejection. The rest were unanswered calls, ineligible callers or unresolved product discussions absorbed into the same bucket by default. Outcome routing was redesigned so that each outcome has an explicit true/false condition and no two conditions overlap. **Customer Care as an independent gate** — checked before the Interested / Not Interested split, so it can never overlap with Not Interested. **Interested / Not Interested formalised** — an explicit routing test, with a retraction clause and an "actively asks questions" clause. **Dropped is content-based** — true if the call never reached a discussion of the product or service, regardless of how long it lasted. No more duration cutoff. **New outcome: Closed** — checked before Sold, for calls with explicit in-call confirmation of completed payment or signature. **Sold revised** — excludes calls where payment or signature is confirmed (that is Closed's territory) and requires no later reversal of acceptance. **Talk to Agent** — now the Interested branch's catch-all: explicit or implicit desire for a human, checked after Reschedule. Understanding Status & Outcomes in VoiceB → Why it matters: outcome-based pricing only works when outcomes are unambiguous. A call now lands in exactly one bucket, and "Closed" distinguishes a sale the agent confirmed on the line from one that still depends on a later step. ## 🔧 Improvements & Fixes ### Agents & voice **Multi-language agents** — one agent can now carry 2+ languages and 2+ voices (a default language plus additional ones, a primary voice plus one per language), at parity with the underlying provider. Multi-market accounts no longer need one agent per language, each with its own script, tools, integrations and number. Agent Studio → **Initiation-failure handling enforced on publish** — the Initiation Failure setting is now toggled in code on every ElevenLabs agent publish, so no agent goes live without it. **Agent variable assignment on creation** — fixed an inconsistent bug where provider, model and memory were sometimes not assigned when creating an agent. ### Widget & attribution **UTM passthrough to CRM** — `utm_*` query parameters captured by the widget are sent as variables on click-to-call and VoIP call initiation, stored on the call, and exposed as mappable `variables.utm_*` source properties in the HubSpot and Salesforce integrations. Widget Configuration Guide → **Widget "call" interactions vs. real calls** — widget call-attempt events were being counted as calls (232 interactions vs. 40 real calls on one campaign). The widget funnel now separates call attempts from matched calls. **Widget interaction metrics for chat/VoIP agents** — impressions, clicks and calls no longer show 0 for chatbox and VoIP-type agents with real interaction volume. **Widget preview state** — preview now compounds reliably across tools and across repeated calls to the same tool. ### Outbound **C2C retry after inbound conversion** — a pending click-to-call retry is now cancelled when the lead has already called back inbound and been marked sold. Previously the retry fired anyway, re-contacting a customer who had already bought. Outbound Campaigns Guide → ### Integrations **Error-only debug trace, sync status and resync** — the integration drawer gains a Debug Trace section for post-call CRM/webhook sync, logging failures only. Each call shows an `ok` / `failed` sync status; failed calls get a **Resync** button that re-sends the call to the integration. Trace logs are visible to org admins only, and Agent Studio can read them. **Salesforce (Nango) organization-scoped** — each organization now has its own Salesforce provider config and connection, with deterministic credential resolution in connect, webhook and runtime flows. Existing integrations were migrated with no action required. **Export pipeline** — fixed the Excel storage error and added CSV delivery by download link. **Tag colours** — tags render with their configured colour instead of all showing red. ### Platform & infrastructure **Infra 1.0 — AWS foundation (eu-central-1)** — a Terraform-managed AWS foundation in Frankfurt with secure account controls, audit logging, GuardDuty, budgets, IAM Identity Center, GitHub OIDC for keyless CI and VPC networking, plus an isolated non-production SIP trunk test tenant (hardened Asterisk, Secrets Manager-backed Twilio credentials, restricted SIP/RTP access, health endpoint). Groundwork for the telephony provider and DDI management programme. Data Journey, Storage & Security → **Docs query reliability** — the `.md?ask=` targeted documentation query no longer times out repeatedly before succeeding. **GitHub ↔ Linear automations** — PR and issue status sync improved; every item in this release is traceable from Linear to its merged PR. ## Final Takeaway September was about self-service. May made sure every lead gets contacted. June put the operation in the operator's hands. July gave the agent hands of its own. August made the result verifiable. September makes it visible to the client without us in the room — and makes the campaign buildable without engineering in the room. A dashboard the client shapes and reads on their own. A CRM mapping set up in a conversation. An agent that logs into the client's systems with credentials it never sees. An outcome that can only be one thing. From September, VoiceB is a platform the client operates — not one we operate for them. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.voiceb.ai/product-updates/september-2026-voiceb.ai-product-release.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.