Tenyx implementation cost: Agentforce Voice credits, telephony and the build

A voice agent is the most unforgiving kind of agent to build. A chat customer will wait three seconds for a reply. A caller hears three seconds of silence as a dropped line. A chat agent can show a list of options. A voice agent has to say them, and the caller has to remember them. So a Tenyx cost estimate is really two estimates: what the agent costs to run per call, and what the telephony and call design cost to make a conversation feel normal.

The acquisition record is brief: "Salesforce completed its acquisition of Tenyx on September 13, 2024." The signing announcement set out the purpose: "Upon close of the acquisition, Tenyx will extend Salesforce’s existing autonomous agent capabilities for Agentforce Service Agent by integrating Tenyx’s innovative voice AI solutions, specifically tailored for service use cases." Salesforce's price lists in October 2026 carry no Tenyx-branded item. The voice capability a buyer licenses is Agentforce Voice, and this guide prices that. Where Salesforce has not said which parts of Agentforce Voice came from Tenyx, this guide does not guess.

#What Agentforce Voice is, in buying terms

Agentforce Voice is not a separate agent product. Salesforce's page says "Voice-enabled agents use the same subagents, actions, and data that power your existing agents, making them more than conversational." In practice that means your voice agent shares its subagents, actions and grounding with the chat agent you may already run. That has a cost consequence. If you have built and tested actions for a messaging agent, much of that investment carries over, and the voice project becomes call design, telephony and testing rather than a full rebuild.

Language coverage is the first scoping question, and the answer is on the same page: "Agentforce Voice is GA in all regions and available in English (US/UK/AU)." For an Australian, British or American service desk this is a direct fit. If a large share of your callers speak another language, the phase one scope may need to stay with English calls and route the rest to people until Salesforce extends coverage.

#The price list, as at October 2026

These are list prices read on 11 October 2026 from the Agentforce pricing page and Salesforce's contact centre and partner telephony pricing pages, in US dollars unless stated. Salesforce marks each as information only and subject to change.

On the native contact centre cards, every currency other than US dollars shows "Not currently available in this region" as at October 2026. Australian buyers should ask their account executive which telephony route is actually sold here before designing around native voice.

The editions line is short and worth quoting: "Contact Center is available on Core, Advanced and Max Editions." Those are the Service Cloud editions priced at US$195, US$395 and US$550 per user per month, billed annually, on the Service Cloud price list.

#Turning voice actions into a monthly bill

Salesforce prices the agent by action, not by minute: "Agentforce actions are 20 Flex Credits, while Agentforce Voice actions are 30 Flex Credits." At list, a voice action costs fifteen US cents. Salesforce's worked example on the pricing page is a reservation change by phone: identify the caller by email, answer questions from knowledge, fetch time slots, finalise the booking. That is four actions, 120 credits a call. At 300 calls a month the example comes to 36,000 credits, or US$180.

Use the same method with your own call reasons. Pull a month of call data, group it by reason, and write the actions each reason needs. A balance enquiry may be two actions. A change of address with identity checks may be five. Then add a margin for the calls that wander: callers change their minds mid-call far more often than chat users do, and every extra lookup is another 30 credits.

The agent meter is only half of the running cost. Telephony minutes, carrier charges and, on the partner route, transcription are billed elsewhere. The partner pricing page is explicit: "Voice-to-text transcription to be licensed from the telephony partner."

#What the implementation is made of

Call reason analysis. Start from recordings and IVR data, not from a workshop. Identify the five to ten call reasons that are frequent, rules-based and low risk. Those are phase one.

Telephony route. Decide between a partner telephony provider you already run, the Amazon Connect bundles, or native voice on Max. This decision changes cost, timeline and who owns call quality. Migrating numbers, IVR trees and call recording settings is its own work package.

Voice and persona. Agentforce Voice offers a range of pre-built voices. Choose one, write how it introduces itself and what it says when it cannot help, and have legal review the disclosure that the caller is speaking to an AI agent where your jurisdiction expects one.

Call design. Spoken prompts need shorter sentences, fewer options and explicit confirmation of anything the caller must remember, such as a reference number. Each subagent built for chat should be reviewed for voice, even if the actions are shared.

Identity verification. Phone callers cannot click a link easily. Design verification that works by voice, with a clear fallback to a person.

Actions and integrations. Reuse existing actions where they exist. Voice adds latency pressure, so slow back-end calls that were tolerable in chat may need caching or a faster endpoint.

Handoff. Salesforce says Agentforce Voice transfers to a live agent with the conversation history and customer context. Test that the rep actually sees it, on the right queue, within the time the caller will wait.

Testing. Test with real accents, background noise, speakerphones and poor mobile lines. Test interruptions, silence and callers who ask for a person in the first second.

Cutover. Move one call reason or one phone number at a time, with the old IVR path kept ready for rollback.

#What drives effort up or down

The telephony route is the largest swing factor. If your current provider already integrates with Service Cloud and you only add the agent, effort is moderate. If the voice project also replaces the telephony platform, it becomes a contact centre migration, with number porting, routing, recording and workforce management in scope.

The second factor is whether a chat agent already exists. Shared subagents and actions mean shared testing. A first agent built for voice carries the full cost of action design.

Third is compliance. Call recording consent, payment card handling on calls, and regulated disclosures each add design and testing. Payments by voice in particular usually need a certified payment flow outside the agent.

Fourth is the hours the agent will cover. An agent that only answers overflow during business hours can hand off freely, because people are there to take the call. An agent that answers overnight, when no rep is available, needs a different design for every call it cannot finish: a callback request written to a case, a promised time, and a queue that picks it up at opening. That design is cheap to build and expensive to forget, because a caller who was promised a callback and did not get one becomes a complaint.

Finally, peak events change the arithmetic. A storm, an outage or a product recall can multiply call volume for a day. Credits scale with that volume, which is the point of consumption pricing, but it also means the finance team should see a daily credit view during incidents rather than a monthly invoice afterwards.

#What a data migration means for a voice project

The phrase "data migration" sits oddly on a voice project, but there is real data to move, and a quote should list it.

First, the call logic. If you ran Tenyx or another voice bot, its intents, sample utterances and branching rules are the best specification you have for the new subagents. They will not import directly, but a partner who reads them saves weeks of discovery. Ask for them to be exported before any old contract ends.

Second, recordings and transcripts. These are usually kept under your retention policy in the old platform or a storage archive, not loaded into Salesforce as live records. Loading them is rarely worth the cost unless a regulator or a quality programme needs them searchable beside the case.

Third, telephony configuration: phone numbers, IVR menus, business hours, holiday messages, queue names and overflow rules. These move with the telephony route, and the carrier usually controls the porting date.

Fourth, knowledge. If the voice agent answers policy questions, the articles it grounds on must be written for being read aloud. Long tables and footnotes that work on a web page do not work in a caller's ear. Budget for editing, not just for loading.

#Shaping the phase one budget

A simple way to keep the first business case honest is to build it from three lines you can each check against a price list.

The first is credits. Take your phase one call reasons, multiply actions per call by 30 credits and by monthly call volume, and price the total at US$500 per 100,000 credits. Add a margin for wandering calls.

The second is telephony seats. Count the reps who will receive transferred calls. At list, partner telephony for twenty reps is US$1,000 a month before any minutes, and native voice on Max is US$75 per rep on top of the Max seat.

The third is the build, priced per work package by the partner you choose.

Then set the measure that will decide phase two. Containment alone flatters a voice agent, because a caller who hangs up looks contained. Track resolved calls, transfers with complete context, repeat calls within a week, and credits per resolved call. If credits per resolved call rise month on month, the call design needs work before the volume grows.

#Getting quotes you can compare

Ask every bidder to quote against the same call data and to return:

• a price per work package, with telephony migration separated from agent build
• the actions per call reason they plan, so you can check the credit forecast
• their latency target and how they will measure it
• the accents, devices and line conditions in their test plan
• the handoff design for each call reason, and the queue it lands on
• what they assume your telephony provider will do, and at whose cost

#Costs that are usually left out

• Telephony minutes and carrier charges beyond any bundled allowance.
• Transcription licensed from the telephony partner on the partner route.
• Data 360 credits if the agent grounds answers in unstructured content.
• Edition changes: native voice needs Max, which reprices every licensed seat.
• Number porting and IVR retirement, often run by the carrier on its own timeline.
• Quality monitoring: someone has to listen to calls weekly for the first months.
• Rep training on receiving warm transfers with context, which changes how calls open.

#Where the other Tenyx questions live

How voice fits the wider agent design is on Tenyx and Agentforce Voice. The acquisition timeline is on what happened to Tenyx. Licence questions are on Tenyx licence cost. Telephony and API surfaces are on integrating Tenyx with Salesforce. Whether to move a working IVR at all is on should I migrate from Tenyx, and how to test a partner before you sign is on hire a Tenyx Salesforce partner.

Our Agentforce consulting team can turn a month of call data into a credit forecast and a phase one call list before you commit to a telephony route.