# Voice simulations

> Test conversations and cross-channel journeys with participants that make or receive calls.

Voice simulations use automated participants to make or receive calls during a test. A participant can also use a browser or exchange messages when the journey crosses channels, such as requesting a callback after submitting a form.

## Prepare the project’s call resources

The project’s simulation service must support voice and have phone resources assigned to it. Before creating the scenario, an owner or admin should obtain the phone resource or pool reference from the administrator or Radiant team managing that service. For an outbound test, also confirm the permitted destination.

The editor uses these resource references; it does not provision phone numbers. A capability marked **unavailable** needs to be enabled for the project before a participant can use it.

## Configure the participants

Open **Simulations → New simulation**, or edit a saved simulation. Give it a name, describe the situation shared by participants in **Scenario**, and bound the run with **Maximum duration (minutes)**. Put the outcome you will assess after the call in **Expected result**.

For each voice participant, describe its role in **Persona** and its task, conversation constraints, and finishing condition in **Instructions**. Enable **Make calls** when it initiates a call, or **Receive calls** when it answers. Under **Resources**, choose **Add resource**, select **Phone number**, and enter the project’s resource or pool reference.

For an outbound test, identify the permitted destination and the task the caller should attempt. For an inbound test, configure another participant or test system to call the assigned number. If the same participant also uses the application, enable **Browser** and explain how that task connects to the call; see [Browser simulations](/docs/platform/simulations/browser-simulations.md) for browser access and sign-in secrets.

Participants do not receive **Expected result**. Their instructions need enough context to carry out the conversation without being told the answer they are meant to discover.

For a scenario that also exchanges messages, enable **Send SMS** or **Receive SMS** as needed and add the corresponding **SMS inbox** resource reference. These capabilities also require project support and granted resources; describe how messages relate to the call in the participant’s instructions.

## Run and inspect the conversation

Save the definition and choose **Run… → Start run**. In the run, inspect participant activity and the recorded calls, transcripts, and handoffs that the executor supplies. Compare the actual conversation and application behavior with the expected result.

If a participant is waiting for a resource, check the reported resource and its grant or availability before changing the conversation instructions. Use [Runs and results](/docs/platform/simulations/runs-and-results.md) for waiting states, stopping a run, and distinguishing a new execution from a status retry.
