How to end a voice agent call with a clear next step

Define the final outcome

Write how the prompt agent summarizes the task: information supplied, confirmed operation or pending request. A tool error does not justify claiming a booking was made. Explain the actual state in a short sentence.

Ask without prolonging

After the recap, check for another in-scope question. Respect an explicit request to end. Avoid repeated farewells creating extra turns without information or preventing the caller from ending.

Configure termination

The documented end-call tool can finish calls according to configuration. Its message and reason should match the situation. Review maximum duration and inactivity settings too; prompt text about silence does not replace these controls.

Protect continuity

If staff review is needed, explain that dependency. Destination receipt must be verified through your integration. If the person leaves early, the record should preserve pending state rather than automatically treating it as success.

Test four endings

Test a completed task, failed tool, explicit termination request and silence during collection. Listen to the final utterance and inspect the record. Ending does not prove resolution; compare with the verified destination state.

What should you say before closing each outcome?

For information, recap the answer and relevant condition. For confirmed operations, repeat essential fields and the returned reference. For requests under review, explain that they were recorded and still depend on staff. Use established states in every case.

In a fictional example, an integration accepts a preferred time but does not reserve a calendar slot. “Your preference was received; staff confirmation is still needed” preserves that state. “It is booked” misrepresents it. Test the final utterance alongside destination records, including callers ending before completion.

Choose the closing message from actual request state

Closing should reflect what happened during service. Answering a question, recording interest, opening a request, and executing a change are different outcomes. A generic phrase such as “everything is fine” may conceal that difference and make the caller believe they received confirmation that does not exist. Define closing messages by state, using simple wording and sufficient evidence for each assertion.

At a fictional store, the agent explains opening hours from an approved document. It may close by confirming the information and asking whether another related question remains. In another call, it records a contact request. The message should describe that record and the approved next step without announcing that staff already contacted the customer. If a tool confirms a reservation, the recap may repeat the date and time returned by the system.

Consider pending state as well. A request under review should not be described as approved. Explain what was submitted, which reference is available, and how to follow it according to the operation. If a tool failed, state that the action could not be confirmed in this interaction. Do not replace this information with a cheerful farewell that makes the failure disappear from the conversation. An honest incomplete outcome is more useful than an unsupported completion claim.

Write the required condition for each message in the instructions. “Confirm booking only after an accepted response” is verifiable. “End positively” may remain tone guidance but cannot replace that condition. Callers need to know whether their question was answered, a request was recorded, or something remains to be done. Accurate state matters more than making every interaction appear equally complete.

During review, compare closing language with tool results or consulted sources. A conversation ending without technical error may still fail the caller's objective. Call state indicates that the interaction ended; task evidence establishes what was actually achieved. Keep those two judgments separate when evaluating both ordinary calls and exceptions.

Recap details that prevent an incorrect action

A useful recap need not repeat the whole conversation. Select elements the caller should remember or correct: date, location, reference, result, and next step according to the task. A long summary can dilute the most important information. If someone asked only for a branch's hours, do not end with a complete company presentation. If a service was booked, its date and location need clear confirmation.

In a fictional appointment example, the caller selected a Tuesday at another location. Closing should use the values actually recorded, including the corrected location. Do not repeat the first time discussed merely because it appeared earlier in the conversation. The tool result and confirmed intent should guide the summary. If a change occurred after writing, explain the final state verified by the system.

Distinguish preferences from commitments. “You prefer a morning callback” describes recorded information; “the team will call tomorrow morning” requires approval and evidence of a process supporting that promise. A recap can mention a preference without guaranteeing fulfillment. This is particularly useful for requests depending on a team outside the agent or on availability not yet checked. The final message should not silently promote a requested preference into a confirmed appointment.

When a reference is difficult to understand by voice, use the approved confirmation or follow-up procedure. Do not invent delivery through another channel if no action is configured for it. If an integration sends the reference, confirm only its returned state. A caller saying “you can send it” does not establish that delivery happened.

Test corrections during the farewell. Someone may interrupt to say the date is wrong or their contact number changed. Resume service and check an allowed modification before ending. Do not force termination because the closing message has started. A summary should detect errors and improve continuity, rather than become a stage that prevents relevant new information from being handled.

Offer a next step the operation can actually fulfill

A next step needs a destination and a clear meaning. “The team will sort this out” does not establish whether a request exists, someone received context, or the caller must contact another channel. Define continuity for incomplete answers, tool failures, and out-of-scope requests. Explain which action happened and which action still depends on another person or system.

At a fictional company, the agent cannot check a contract. The alternative may be providing an approved contact channel or recording a review request according to existing capabilities. These routes are not equivalent. If the agent only provides contact information, do not say staff were notified. If it records a request, confirm the available reference and approved follow-up. Do not invent a callback deadline to make the farewell more convincing.

Where telephone transfer exists, verify destination and failure behavior. Tigy supports transfer on compatible telephone channels, but a web call should not receive a transfer promise unsupported by that channel. Direct transfer also does not automatically deliver conversation history to the receiving person. If staff need context, test separate delivery through the operation's process. Both connection and information continuity need evidence.

Initiating a transfer does not guarantee that human service was completed. The preceding message should explain what is about to happen without asserting resolution. If transfer fails and the agent continues, use the approved alternative. A configured tool does not prove its destination is available at that time. Test after-hours behavior instead of assuming ordinary-hours success applies everywhere.

Review continuity with the team receiving requests. Can they find the record, understand the reason, and use the correct contact details? Is someone responsible for responding? If any answer is negative, fix the process before adjusting only the closing sentence. An executable next step reduces repetition and aligns expectations with actual service, including when the agent must explain that it could not complete the task.

Test termination as part of the task

The end-call tool allows termination when the conversation has reached a conclusion or the caller asks to leave, according to configuration. A spoken farewell alone does not guarantee technical termination; a technically ended call does not establish task completion. Instructions should specify when to end and which conditions need verification first.

Prepare tests covering completed requests, pending submissions, integration failures, explicit requests to end, and corrections during farewell. Also include a caller asking another related question when the agent offers further help. Determine whether a new in-scope need exists and handle it rather than automatically ending because the first task was performed. The final moment of a conversation should remain responsive to meaningful caller input.

Observe interruptions and response timing in voice tests. A caller may need several seconds to write down a reference. Behavior also depends on conversation settings, not just tone descriptions in the prompt. An instruction to be patient does not replace silence or duration controls. Test the actual channel to verify that closing is understandable and happens at the appropriate moment. Text-only tests cannot establish how the farewell sounds or how interruption affects it.

Review what happened after the call in an operational sample. Did customers return because they believed an action was complete? Did staff receive requests requiring recollection? Does final system state match the message? These signals reveal problems an isolated transcript may miss. Separate recording failures, ambiguous wording, and missing continuity, because each needs a different correction.

Keep closing scenarios in new-version reviews. Changes to instructions, tools, or returned states may alter the final message. A good ending leaves the caller with accurate information about the outcome and next route. It need not prolong a resolved conversation, but should not cut off a relevant correction or manufacture completion to meet a duration target. Evaluate both the farewell and the evidence supporting it.