SIP telephony in Tigy: routing calls to voice agents

Prepare the prompt agent

Open the correct workspace, select the agent and check its instructions. Use a recognizable pilot introduction, such as the serviced branch name. Save and test in the editor to establish a comparison for the telephone call.

Enable SIP

In the agent’s telephony settings, enable creation of the SIP destination when needed and copy the complete address shown on screen. Think of this address as the call destination belonging to that particular agent. Do not copy it from memory or use another agent’s address.

Configure the telephone origin

Route calls from your SIP-compatible system to the copied SIP address. Origin configuration depends on the service and your permissions. Agree with its administrator which route changes, which contacts enter the pilot and how to reverse it.

Make a traceable call

Call through the intended origin, check the introduction, ask a known question and review the agent’s run. Record time and run identifier. If the wrong destination answers, investigate routing before changing the prompt.

Verify exceptions

Test destination unavailability and, when configured, transfer to staff. Check how the origin behaves when a call fails to complete. One successful call does not establish audio quality, coverage or capacity.

How do you confirm the call reached the correct agent?

Record the workspace, agent, telephone origin and complete SIP address copied from settings. Place a call with an identifiable synthetic question and locate its run by time and agent. Similar greetings across two agents can conceal an incorrect destination.

If the wrong agent answers, compare the copied destination and origin route before changing the prompt. If no call arrives, investigate telephone delivery. After confirming association, test audio, tools and transfer separately; SIP connectivity does not establish all those capabilities.

Define what the telephone pilot must demonstrate

SIP pilots answer different questions from editor conversation tests. They must show that origins route to the correct agent, audio supports service and ending follows the expected path. Good instructions cannot repair incorrect routing. Keep conversational behavior and telephone delivery as separate evidence rather than treating a fluent response as proof of the entire connection.

Choose a simple verifiable task for the first call. In a fictional case, an agent gives one branch's opening hours from an approved source. This allows checks of association, introduction and response before adding external actions or transfer. Use test information so failures do not change live customer records.

Record call origin, intended agent and external configuration owner. Do not copy credentials into test records. Retain enough information to trace the journey without exposing authentication data or unnecessary personal contacts. Owners should know where to inspect the relevant system settings rather than rely on copied secrets in shared notes.

Define how to restore previous service if pilots fail. Restoration belongs to the telephone system and must be understood by route owners. Do not promise automatic recovery merely because test plans describe an alternative. Validate that the responsible person can apply the approved restoration process before directing meaningful service volume toward the new path.

Check the selected agent's specific endpoint

Each agent has its own SIP destination. Copy the complete address from telephony settings and give it to the person responsible for your phone system or calling service. They should send calls to that destination. Check which agent answers before testing the conversation.

Check agent identity before and after configuration. Workspaces with multiple agents may have similar names, making it easy to copy the wrong number. Use clear operational identification and recognizable test calls without sensitive data. Record the intended association so a second reviewer can verify the same destination independently.

Publishing behavior changes does not mean reassigning another agent's number. Distinguish conversation revision from telephone association. If service reaches the wrong agent, inspect the copied destination and origin route. Changing the greeting may conceal the symptom while leaving the actual association incorrect.

Place a call through the intended path and find its corresponding execution. Compare time, agent and test question. This evidence helps confirm association without relying only on introductions that may resemble other configurations. If expected records cannot be found, first determine whether the call reached Tigy before diagnosing recognition or prompt behavior. Routing evidence should precede assumptions about what happened inside an agent.

Observe audio and turns on the target channel

Connected calls can still have audio problems. Check that both parties are heard, speech remains intelligible and pauses or interruptions produce expected behavior. Do not declare quality merely because a connection was established. A successful route and a usable conversation are separate conditions.

Use short phrases containing representative names, dates and numbers. Compare spoken input, recognized text and responses. If values change in transcription, investigate incoming audio and transcriber settings before blaming instruction rules. If text is correct but tool parameters are wrong, the failure belongs to another stage and needs a different investigation.

Include callers interrupting to correct information. Agents should use current requests and keep next steps clear. Good text responses do not establish that spoken interactions work over telephony. Review whether callers can understand questions and confirmations without excessive repetition, especially for critical fields.

Record test conditions for reproduction. Origins, environments and relevant configuration help compare outcomes. Avoid turning clean-audio tests into guarantees for every setting. Expand samples as pilots encounter real service conditions. Where quality varies by origin, preserve that distinction rather than averaging away a recurring problem affecting one route. Use available evidence to separate delivery, recognition and conversation issues instead of making unverified claims about which dependency is responsible.

Validate actions and transfer as separate checks

After confirming routing and basic conversation, test each action included in scope. Tools must be configured and selected for the agent. Spoken responses should match external outcomes, including refusal and unavailability. Connection alone does not establish that integrations execute correctly or preserve caller authorization.

For transfer, verify channel support, destination and configuration. Do not infer compatibility from browser-based editor voice tests. Direct transfer in Tigy does not automatically send context; record delivery requires a separate verified mechanism. Confirm that receiving staff can discover any delivered record instead of treating technical delivery as sufficient continuity.

In a fictional example, agents query applications and then attempt staff transfer. Record query parameters, returned states, transfer attempts and observed results. Each stage answers a different continuity question. A successful query followed by failed routing should remain distinguishable from a fully completed handoff.

Include failed tools and unavailable destinations. Conversations should explain limits without announcing completed actions. Pilots need to show that callers receive truthful next steps when ideal paths fail. Where request collection provides an alternative, verify actual record creation and ownership. Do not promise callbacks or resolution deadlines absent from the approved process. Review final caller expectations alongside technical evidence so partial success does not become an unsupported claim of complete service.

Investigate failures at the stage where they appear

If calls do not reach agents, begin with origin routing and configured destinations. If they reach wrong agents, compare association and copied SIP addresses. Changing model responses cannot repair those conditions. Establish the delivery path before investigating behavior that may never have run.

When calls arrive correctly but callers are misunderstood, compare audio and available transcription. When interpretation is correct but tools fail, inspect parameters, authorization and external responses. This sequence prevents broad changes without diagnosis. It also separates unsupported expectations from defects: an unavailable operation cannot be fixed merely by telling an agent to perform it more confidently.

Use recognizable test questions and recorded times to correlate evidence. Avoid many simultaneous changes because they obscure which correction worked. Repeat the same check afterward and include a previously successful control case. Record effective configuration rather than relying on memory of what was changed during experimentation.

When evidence cannot establish causes, preserve uncertainty. Inconclusive tests should not be marked successful. Send concrete expected and observed behavior to the dependency owner through the team's normal process. Keep credentials and unnecessary customer details out of diagnostic records. A concise reproducible case is more useful than a large collection of unrelated logs, especially when the problem concerns one destination or one stage of the interaction.

Expand with verified capacity and maintenance

Single calls do not establish concurrency or stability at larger volumes. Check dependency limits and conditions against actual configuration and contracts. Avoid publishing capacity numbers unverified for the project. Separate theoretical support from observed behavior under the intended operating conditions.

Plan gradual expansion and observe demand, failures and continuity. Distinguish agent execution, telephony and completed tasks. Service outcomes may depend on APIs or staff even when SIP routing works correctly. Counts of connected calls should not become resolution rates without checking what callers actually obtained.

Assign owners for destinations, agent configuration and integrations. When branches change or agents are replaced, review telephone association and test cases. Do not assume editorial or publishing changes update every external route. Keep a concise maintenance record so someone other than the original implementer can verify current setup.

Close each stage with evidence of origin, agent, audio and outcome. Reliable pilots provide service that staff can explain and maintain. Subsequent expansion should follow that evidence with operational alternatives ready for known limits. Retain basic delivery and exception tests during later changes because added capabilities can alter an otherwise successful path. Where results remain inconsistent, narrow the expansion and investigate instead of allowing greater volume to make the underlying issue harder to identify.

Have another reviewer reproduce the check

Before expansion, ask another responsible reviewer to repeat the call through the same path. They should identify the intended agent, find the execution and explain the result without informal guidance from the original implementer. This reveals missing documentation and supports continuity when the team changes.