How to connect a phone number to a voice agent in Tigy

Prepare the agent and connection

Connecting a number to a voice agent requires three checks: published agent, provider configuration and assignment of the number to the correct agent. Tigy AI inbound documentation describes Twilio, Telnyx and VoIP connections through SIP (Session Initiation Protocol) with specific procedures. Follow the chosen provider’s path and confirm connection with an actual call.

For the Twilio example, have an account-owned number and required credentials. Keep the token in telephony configuration and confirm account access to the number.

Associate the number with the right agent

Add the provider configuration in Tigy and register the number with its country code. Select the prompt agent that should receive incoming calls and save. The configured number determines the destination.

Check workspace and selected agent. A successful editor test does not establish that the phone number uses the same configuration.

Follow the call through both systems

Call the configured number and check that the agent answers. Inspect provider and Tigy logs to locate failures before or after connection.

For a Twilio integration, ask the telephony owner to also check the automatic notification that passes the call to Tigy, known as the voice webhook. The connection must allow the provider to send these events. Note any synchronization warning so you can investigate it with that person.

Validate service on the real channel

After verifying inbound routing, test audio, numbers, external lookups and intended handoffs. Transfers require compatible configuration; browser and phone behavior should be checked separately.

Record the number, agent and version used. Later changes should include a new verification call as well as prompt tests.

Make a call with traceable evidence

Call with known questions, fictional lookups and exceptions, recording time and locating the run.

Missing runs suggest routing; audio and tool failures need their own layers investigated.

Transfer tests need formats and unanswered destinations. Context delivery requires separate integration.

Change routing with recovery available

Assign routing-change and recovery ownership before failures.

Limit pilots and inspect missing or incomplete calls by origin and time.

Verify new assignments with new identifiable calls rather than old sessions.

Check published agent, configuration, and number separately

Telephone connection depends on distinct parts. The agent needs an appropriate executable version. Telephony configuration needs credentials and conditions for the provider in use. The number must be assigned to the agent intended to answer. Publishing does not automatically create that association. A call failing to reach the service may fail at any of these stages, so investigation should establish which remains incomplete.

At a fictional company, staff publish a reception agent and test browser voice. Calling the company number then reaches the previous service. Browser testing demonstrated agent behavior, not telephone routing. Check number configuration and assigned destination. Rewriting instructions does not fix a call that still reaches another service. The selected channel must be verified independently from the conversation logic.

Begin with one number and a limited objective. That allows configuration checks without combining many agents, locations, and destinations. Record workspace, telephony configuration, number, and expected agent. Use the interface and documentation corresponding to the available provider. Do not assume one integration's fields match another or that credentials from another account can operate the selected number. Keep those relationships explicit during setup and troubleshooting.

Check authorized workspace usage before testing as well. Being signed in does not guarantee a new execution can start. If usage or billing blocks a call, review displayed state before changing service instructions. The first result should be concrete: calling the configured number starts a conversation with the expected agent on a known version. Only then evaluate audio details and commercial behavior. A successful setup form is not a substitute for this real-channel check.

This separation makes launch easier to review. Staff can demonstrate publication, assignment, and a real call rather than rely on one broad assertion that telephony is connected. Each piece of evidence answers a specific question about the path from the dialed number to the agent's actual response.

Configure integration without distributing credentials

Telephony configuration should use the information required by the selected integration. Check that it belongs to the account controlling the number, and keep secrets out of prompts, public documents, and support reports. Screenshots may show configuration state without exposing tokens. Integration maintainers need appropriate access, but that does not require another owner's personal password.

In a fictional example, staff create a recognizable configuration and add a number. Incorrect credentials prevent calls even though the number looks correct in the dashboard. Investigate relationships among account, configuration, and provider before repeatedly changing agent assignment. If an error appears, record the step and description. Do not send the secret alongside evidence merely to prove it was copied. Troubleshooting requires observations about failure, not exposure of authentication material.

Verify number format according to the field and relevant documentation. Confusing originating numbers, inbound numbers, and transfer destinations creates different issues. An incoming call should reach the configured receiving number and assigned agent. Transfer, where available, uses another destination and needs its own test. Receiving calls does not prove every human-routing option works. Document which number serves each purpose in the pilot.

Provider routes and events are also part of configuration. Use documented values for the integration and inspect available records when calls do not arrive. If the provider received the call but Tigy did not start expected service, investigate the path between systems. If the call never reached the provider, the cause belongs elsewhere. This order reduces unnecessary changes to an otherwise correct agent.

After changing credentials or ownership, test the real path again. An old configuration may remain visible without valid authentication. Maintain a verifiable connection under defined responsibility, with sufficient diagnostic evidence and without secret circulation through channels that do not need it. The successful test should establish the integration's current state rather than rely on a previous launch result.

Test conversation and tools through the number callers will use

After confirming calls reach the agent, test the service objective through the telephone channel. Greeting, understanding names and numbers, confirming information, and tool usage need to work along this path. Text testing supported logic; browser testing supported voice; calling the number adds telephony conditions. Evidence from one stage does not automatically replace evidence from another.

At a fictional store, the pilot starts with opening-hours guidance and order lookup using a test tool. Make an ordinary call, one with a corrected number, and one with unavailable lookup. Check what was heard and which action occurred. If recognition captures the wrong identifier, an answer may look correct for another order; examine submitted parameters and results. Available recordings help investigate the audio experience alongside transcripts.

Include natural pauses and interruptions. Someone may speak slowly to dictate a reference or correct information during a response. Conversation settings affect when the agent listens and replies. Do not attempt to fix everything through tone instructions. Separate recognition, interpretation, tool delay, and turn ending to select the right adjustment. Repeat the same case after changing a control so the effect remains assessable.

If service offers transfer, test only capabilities compatible with the channel and configuration. Tigy's direct telephone transfer does not automatically deliver conversation history to the receiving person. A separate integration should provide context when needed. Check destination, unavailability, and continuity before promising a handover containing every detail. A successful connection needs to be distinguished from completed human service.

Use test tools and information for operations writing records or sending messages. A telephone pilot may execute real actions when those are configured. Inspect external systems to confirm outcomes and avoid duplication. Pilot acceptance should establish both that the number reaches the right agent and that service works accurately, rather than merely proving a voice answered. Review failures as part of acceptance so the agent's alternative route is as concrete as its ordinary success path.

Maintain a diagnostic sequence after launch

When service changes after deployment, investigate in sequence. Check called number, configuration, assigned agent, and utilized version. Then examine execution startup, audio response, and tool action according to the issue. Reaching the wrong agent requires a different correction from a slow external lookup. Separating stages avoids rewriting instructions to solve routing failures.

In a fictional example, staff edit and save an agent but calls still receive old answers. Saving and publishing are different actions. Check history and published version, then make a new conversation through the intended number. If assignment points to another agent, correct the destination through the appropriate process. Investigation should follow the configuration actually used rather than the one someone believes they edited. A recent save timestamp is not evidence that public execution changed.

Retain identifiers and times for problematic calls to review Runs and available integration records. Do not copy credentials into reports. For audio, listen to an available recording. For tools, inspect actions and results where present. For calls never starting execution, investigate the telephone path before searching for a transcript that may not exist. Choose evidence matching the failed stage rather than treating all issues as conversational quality problems.

Revisit the pilot when credentials, numbers, destinations, instructions, or tools change. Integration that worked at launch still needs ownership. Define who reviews failures and who updates service conditions. If a human alternative exists, verify current hours and destinations instead of treating agent availability as proof of staff availability. Test that alternative under its real operating conditions.

The desired result is an explainable operation: staff know which number receives calls, which agent answers, and which actions it may perform. A small collection of real-channel tests verifies those relationships after changes. This supports predictable deployment with evidence-based diagnosis and avoids promising transfers, lookups, or continuity the configured path cannot provide. Keep test outcomes related to configuration versions so future investigation starts from a known working reference.