Integrating Tenyx with Salesforce

A contact-centre architect draws a handset, a cloud, and an arrow. The arrow says voice. Nobody has written where the call is stored, or what the caller hears if two speakers start at once. The drawing is a poster. An integration names the system, the object, and the failure when the call does not land. The system is voice for service. The object is the Case. The failure is a call with no Case, or two agents talking.

Tenyx is voice for service. Salesforce completed the acquisition on 13 September 2024. This page will not invent a generally available product name for that voice work. A name you hope to see in a catalogue is not a name the cited page gave. This page will not invent a telephony connector either. The phone platform you already run can be named by you, in your brief, because it is yours. A connector brand added to make the arrow look finished is not yours. The only sentence this page quotes from the announcement is the completion line. "Salesforce completed its acquisition of Tenyx on September 13, 2024."

#The system is the voice path

The system is the path a caller walks, not a logo. They reach a number you already publish. Something identifies them with a check your operation already accepts. Something answers, or something transfers them to a person. The path has a start and a stop. If you cannot say those steps for one reason people phone, you do not have an integration. You have a wish to add voice.

Keep the path to one reason. Order status is the usual pilot, because the rule is boring and the caller wants a fact you already store. Identify. Read the fact from the system you name. Speak the fact you are willing to defend. If the check fails, or the fact is missing, transfer. Four steps. A diagram with forty steps is a poster with small type.

The caller cannot see a screen. They cannot paste a screenshot. Silence is the defect they notice first. Write what they hear at each step, in a sentence a supervisor can read aloud. That sentence is the behaviour. A setting buried in a telephony product is not a sentence this page will invent. If your engineers have a platform open, they can point at it. This page was not on that call.

Do not copy a chat design onto the phone and call it integrated. Chat can show buttons. Voice has to be heard. A chat topic pasted onto a number will produce a call that wanders, and a Case that does not match what was said. Tenyx and the service voice quote is where that path is priced. This page is the landing.

#The object is the Case

The call lands when a Case exists for it. The Case holds the number or the identifier you used, the reason, the outcome, and the owner if a person took over. A recording, if your policy allows one, is referenced from that Case. A call that lives only in a phone log has not landed in Salesforce. The service organisation cannot see it on the record the rest of service uses.

Write the match. One call, one Case. A second call about the same order is either a new comment on the open Case or a new Case you link. Pick one before go-live. If voice opens a Case and the chat design opens another, you have split the story. The caller told it once.

The running identity of the voice design matters. Which user creates the Case. What that user is allowed to see. A design that runs as a wide administrator will read records the caller should not hear. A design that runs as a user with no access will fail closed or, worse, guess. Write the user. Write the objects it may read. Leave every other object out.

Transfer is a field, not a mood. The moment a person owns the call, the Case shows it. The note says why. The queue is one you already staff. If the note is empty, the person starts again, and the caller tells the story twice. That is a landing failure even when a Case exists. An empty handoff is a Case that did not receive the call.

#The failure is no Case, or two agents talking

Listen to the two misses as different tests. In the first, the caller hangs up and the supervisor cannot find a Case. The phone system may show a duration. Salesforce shows nothing. You cannot coach it, report it, or see that the order fact was wrong. The call did not land. Fix the create before you tune the voice.

In the second, a Case exists and two agents talk. The voice design keeps speaking after a person has taken the call. Or a person and the voice design both greet, both read the order, both try to close. The caller hears a muddle. Your recording, if you keep one, shows two voices and no owner. The failure is not that a person exists. The person is the right design for the exception. The failure is that both designs stayed on.

Write the rule that makes one of them stop. When the Case field says a person owns it, the voice design stays silent and leaves the audio path. When the voice design is still in its steps, a person does not barge in unless the caller asked or the check failed. Both sides need the same field. If they do not share it, they will talk over each other the first busy hour.

A third shape is two Cases and two speakers. Voice opened one. A screen-pop for the person opened another. The person types into the second. The voice design writes the first. The caller is one person. Your history is two. Make the screen-pop open the Case voice already created. Do not invent a telephony connector to excuse the double open. The fix is the shared Case id, passed because you designed it, not because a package name appeared on a slide.

#What the diagram has to show

System: the voice path for one reason, in service. Object: the Case, including the owner field. Failure: no Case, or two agents talking. You may name the queue and the order system you already read. You may not name a generally available voice product the source did not name. You may not name a telephony connector. You may not put a price or a daily cap on the arrow. None of those are in the cited page.

Say the three names without a brand. If you cannot, the diagram is a poster. What happened to Tenyx is the ownership page. It dates the close. It does not draw this path, and it does not publish a screen for you to copy.

#What you refuse to invent

A generally available product name is a procurement sentence. This page does not have one to give you. If a later page from the vendor names the voice product and shows it in your org, that page can carry the name. A proposal written now should say "voice for service" and then the path. Teams that wait for a coined name delay the Case design, which is the part they can finish.

A telephony connector name has the same problem. Your current phone platform is a fact about your estate. Write that fact if you know it. Do not add a second brand as the glue. Glue without a Case id is how two agents end up on the call.

A daily cap, a price, and a current screen are all absent from the source. Your volume band, if you have measured it, belongs on the implementation brief as your number. Do not invent a limit so the diagram looks governed.

Languages, recording, and consent are your policy. Write the ones you already run. A new recording rule invented to make the pilot interesting is a legal change, not an integration step. Leave it out until counsel has written it.

#How you test that the call landed

Place one call for the pilot reason. Hang up after the answer. Find exactly one Case. Read the reason, the fact that was spoken, and the identifier. Then place a second call that should transfer. Confirm a person received a note, and confirm the voice design stopped speaking when the owner field flipped. If you hear both, the stop rule failed. If you find no Case, the landing failed. Do not average them into a score.

Have a supervisor listen to five calls. They are listening for a second voice and for a story the Case does not contain. A call the Case cannot explain is a call that did not land, even if the caller seemed content. Contentment is not an object.

Rehearse the way back. The way back is the number routing to the queue you had before, without the voice design. Write who may make that change, and how a caller mid-conversation is treated. An integration you cannot silence is not ready.

When the pilot reason is dull, add the next reason on the same number only after the Case rule still holds. Dull means one Case, one speaker at a time, and a note a person can use. A new reason that needs a new object is a different diagram.

Keep chat on its own integration. A web message and a phone call can relate to the same customer. They should not be forced through one unmarked arrow. If they share a Case, say so, and say who is allowed to speak. That sentence is the whole difference between a service design and a poster of a cloud.

A Tuesday check is a count, not a feeling. List the calls on the pilot number. List the Cases the voice path created. The gap between those lists is the landing error. Do not hide the gap inside an average duration. Duration can look fine while the Case was never written. A call the Case cannot explain is unfinished, even when the caller said thank you.

Write the sentence the caller hears when the identity check fails. That sentence is part of the integration. It decides whether a person is summoned. A vague apology that does not transfer leaves a call with no owner. If the Case is also missing, you have the failure in both shapes at once. The sentence should name the next step a person can recognise: a queue you staff, a wait you mean. It should not invent a product name to fill the silence.

A failed check is still a contact you accepted. The Case should record that the check failed and that a person continued, or that the caller hung up. Dropping those callers from Salesforce because the check failed is how a call with no Case becomes the quiet defect. A dashboard of successful answers will not show it. Read the misses on purpose.