When an outsourced service agent calls a customer, the number displayed belongs in the operating brief. The client and provider should agree which identity the agent may use, what the call concerns and where a customer who calls back will arrive.
The Genesys Cloud release notes dated November 9 describe a new option for agents to select the outbound caller ID for non-ACD calls from administrator-approved numbers. The notes list the feature as included with all licences. Availability still needs checking: Genesys describes a regional rollout starting Tuesday and finishing by the end of Friday, with feature access also subject to its release schedule and applicable requirements. A dated release note is not proof that an individual organisation has the option enabled.
Agree on the identity before the call
For an outsourcing relationship, the useful starting point is the purpose of the call. A client may want a provider to follow up an unresolved service request, confirm an appointment or speak to another business contact. Each instruction should make clear which approved number is appropriate for that purpose.
The following suggestions are operational analysis, not Genesys configuration instructions or legal advice. Put the permitted choices in the same working brief as the task. Explain who can resolve an uncertain case and how the agent should proceed when the intended choice is unavailable. An agent should not have to invent the client's preference during a customer conversation.
Imagine a provider serving two fictional clients. Both ask for outbound follow-up, but their customers use different return-contact routes. A general instruction to call the customer leaves an important decision unstated. A specific brief connects the task to the relevant client identity and follow-up arrangement.
Test what happens when someone calls back
The displayed number is only one part of the customer experience. As a proposed acceptance check, follow the return path with the people responsible for receiving it. Can they identify the relevant service? Do they understand why the customer may be calling? What happens when the original agent is unavailable?
Use an agreed test rather than assuming the return path works because an outbound call was placed. The client and provider can record the expected result and the observed result in plain language. If the test exposes an unclear handoff, decide who owns the correction before treating the process as ready.
This is also a place to define the limits of the agent's responsibility. An agent may be authorised to make a follow-up call without being authorised to change a client's contact arrangements. The brief should identify the person who can make that decision.
Keep the approved list understandable
Where several choices are permitted, give the team enough context to select the intended one. A list that makes sense to its administrator may still be confusing to a person handling several clients' work. Review the agent's actual task and the language used in the brief together.
Record changes to the agreed operating arrangement and tell the affected people when they apply. If the client changes its return-contact process, check whether the provider's instructions need revision as well. A technical change and a changed service promise should reach the team as a coherent update.
Before relying on the new selection feature, confirm its availability in the relevant organisation and carry out a small accepted test. Then review the call as the customer experiences it: the reason for contact, the identity presented, the conversation and the route back to help. That gives both sides a clearer standard than simply confirming that a call button works.
Evidence limits: the feature description and rollout caveat are vendor documentation, not independent performance findings. The client–provider examples and acceptance checks are proposed operational practices.
AI-generated conceptual editorial image; fictional service agent, not a Genesys interface demonstration or Myaa client.