Post Processing¶

After-call handoff

Post processing shapes what happens after the call: final summary, summary email, and webhook delivery. It turns a completed call into something your team can act on.

Only tune post-processing after the live conversation captures the right information.

Post Processing controls what happens after the call is over. This is where you shape the final call summary and decide where that summary should go.

For the callback assistant, this area matters because a good live conversation is not enough on its own. The team still needs a clean summary, a clear delivery path, and a structured handoff after the caller hangs up.

Where to find it¶

The tenant menu exposes this area as Post Processing.

The page contains three tabs:

Summary Prompt
Summary Email
Summary Webhook

What Post Processing is for¶

Use it to control:

how the final summary is written
whether the summary is emailed automatically
whether the summary is sent to an external webhook

This is different from the Email Tool in the agent configuration:

the Email Tool is an agent action that runs during the live callback flow
Post Processing is tenant-level summary handling after the call has been stored

Both can exist at the same time, but they solve different problems.

Summary Prompt¶

The Summary Prompt tab defines how the final stored call summary should be written.

The UI shows the supported prompt variables. Common variables include {conversation_fact_summary} for stored conversation facts and {pre_call_context} when Pre Processing caller lookup is configured. If you leave the prompt empty, the backend default prompt is used.

When to customize it¶

Customize the summary prompt when:

the default summary is too loose for your team
you want a consistent structure for callback requests
the summary should emphasize fields like callback number and reason for the call

Recommended callback-assistant summary prompt¶

Use a prompt like this:

Write a plain-text callback summary for a human team.

Use short sections and keep the output operational.

Include:
- Caller name
- Company name
- Callback number
- Reason for the call
- Important notes or urgency

Use {conversation_fact_summary} where it helps improve accuracy.
Use {pre_call_context} only if pre-call caller context is available and relevant.

The point is not to make the summary sound clever. The point is to make it immediately actionable.

What good output looks like¶

A good callback summary lets a human answer three questions instantly:

who called
why they called
how to reach them back

If the summary does not do that, tighten the prompt.

Append collected facts¶

Enable Append collected facts when you want the stored conversation facts added as a separate section after the generated summary.

This is useful when:

the generated summary should stay short,
reviewers still need the raw fact list,
a downstream process scans structured facts separately from the narrative summary.

Append conversation history¶

Enable Append conversation history when reviewers need the full conversation transcript after the generated summary. Nuvoca appends the transcript as a separate section to the final summary.

This is useful when:

a team needs to compare the summary with the original conversation,
QA or audit needs the exact wording,
a handoff needs more context than the summary alone provides.

Leave it off for normal inbox delivery if a concise summary is enough. The full conversation history can contain personal data and can make summary emails or webhook payloads much longer.

Append invoked tools¶

Enable Append invoked tools when reviewers need to see which tools the agent used during the conversation. Nuvoca appends an Invoked tools section after the generated summary.

The section is meant for operational review. It includes tool name, tool kind, status, timestamp, and duration.

It does not include tool arguments, request payloads, API responses, email content, SMS content, credentials, or authorization tokens.

Use it when:

your team wants to confirm whether a handoff, API request, SMS, email, or internal tool ran,
QA needs to compare the final summary with the agent's actions,
a downstream process needs a safe tool-use summary without storing tool payloads.

Leave it off when the summary should stay as short as possible.

Remove PII later

If a stored summary or appended conversation history contains personal data, use Remove PII in Call History. This redacts phone numbers and generated notes; billing and timing data remain available.

Summary Email¶

The Summary Email tab sends the final call summary automatically after post-processing.

The product supports:

enable or disable summary email delivery
multiple To recipients
optional CC recipients
custom subject and body templates
skipping the summary email when the caller did not say anything after the greeting

Use it when:

a team inbox should always receive the stored final summary
you want tenant-level delivery without depending on live tool execution
operational staff review summaries outside the agent tool flow

Email subject and body templates¶

Use custom templates when the default summary email format does not match how your team scans or routes incoming work.

Common examples:

include the caller name or company in the subject,
add a fixed team instruction above the summary,
include selected facts in a consistent format,
include timestamps or duration for triage.

For example:

Callback request - {fact_company}

Missing {fact_<key>} values render as blank. Other unknown variables are rejected when the configuration is saved, so typos are easier to catch.

Keep subjects low-risk

Email subjects are visible in inbox lists, notifications, and logs outside Nuvoca. Avoid putting sensitive details such as phone numbers, account IDs, financial context, medical context, or urgent private notes in the subject. Put detailed information in the email body when the recipient list is appropriate.

Skip silent-caller emails¶

Enable Skip summary email when the caller did not say anything when your team does not need an inbox message for calls where the caller never speaks after the greeting.

The final call summary is still saved in Call History. This setting only controls Summary Email delivery. Summary Webhook delivery has its own separate setting.

When this setting is off, emails for calls with no caller speech may contain minimal values for conversation-dependent variables such as {summary} or {conversation_history}.

CC recipients¶

Use CC recipients when another address should receive a copy of every summary email without being the primary team inbox.

Good CC uses include:

a team lead who wants visibility,
an archive or audit inbox,
a shared QA mailbox during rollout.

When to use Summary Email vs Email Tool¶

Use Summary Email when:

you want a post-call tenant-level delivery rule
the final stored summary is the source of truth

Use the Email Tool when:

the assistant should decide during the call when the handoff is complete
the handoff should be driven by the live conversation logic

Some teams use the Email Tool for the live callback handoff and Summary Email for a secondary audit or archive inbox. Keep the recipient lists intentional so the same summary is not sent to more people than needed.

Summary Webhook¶

The Summary Webhook tab sends the final stored summary to an external API after post-processing.

The UI supports:

Enable webhook delivery
skipping the webhook when the caller did not say anything after the greeting
Target URL
Timeout (ms)
Content type
OAuth configuration
headers
query parameters
JSON, form, or text request bodies
Send Test

This is the operational path when a final summary should go into another system automatically.

Skip silent-caller webhooks¶

Enable Skip webhook when the caller did not say anything when the receiving system should not get empty-call events.

The final call summary is still saved in Call History. This setting only controls Summary Webhook delivery. Summary Email delivery has its own separate setting.

When this setting is off, webhooks for calls with no caller speech may contain minimal values for conversation-dependent variables such as {summary} or {conversation_history}.

When to use it¶

Use Summary Webhook when:

a CRM, workflow engine, or backend should receive the final call summary
you need tenant-level delivery independent of live tool decisions
you want a normalized summary payload after the call is fully processed

What the webhook is good for¶

For the callback assistant, a webhook is useful when the final result should create or enrich:

a lead
a support ticket
a callback queue
an internal workflow run

Important distinction¶

The API Tool sends structured data from the live assistant flow.

The Summary Webhook sends the final stored summary after post-processing.

Use the API Tool when the assistant must create the system record as part of the live callback sequence. Use Summary Webhook when the final summary itself is the output you want to deliver.

Available variables¶

The UI provides backend-supported variables for the summary prompt, Summary Email templates, and webhook configuration.

Summary Email templates and webhook templates can use post-call variables such as:

Variable	Meaning
`{summary}`	Final generated call summary
`{conversation_history}`	Conversation transcript/history available to post-processing
`{conversation_fact_summary}`	Collected conversation facts as a summary
`{tool_invocation_summary}`	Human-readable list of invoked tools
`{tool_invocations}`	JSON-style tool invocation metadata
`{from_number}`	Caller/source number when available
`{to_number}`	Called/destination number when available
`{started_at}`	Call start timestamp when available
`{ended_at}`	Call end timestamp when available
`{duration_seconds}`	Call duration in seconds when available
`{fact_<key>}`	A collected conversation fact, for example `{fact_company}`

Missing {fact_<key>} variables render blank. Unknown non-fact variables are rejected when saving the configuration.

Fact variables only resolve when the agent collected the corresponding fact during the call. If the agent never stored a fact named company, {fact_company} will be blank even if the caller mentioned a company name.

Use those variables for:

query parameters
non-sensitive headers
JSON body values
form fields
plain-text bodies

The product also lets you test the webhook with unsaved values, which makes this page safer to configure than guessing in production.

Tool invocation variables¶

When tool-invocation tracking is available, Summary Webhook templates can use:

Variable	Meaning	Best use
`{tool_invocation_summary}`	Plain-text list of invoked tools with name, kind, status, timestamp, and duration	Human-readable notifications or ticket notes
`{tool_invocations}`	JSON array of invoked tool metadata	Systems that should parse tool-use metadata

Only include these variables when the destination system needs them. Tool-use metadata is safer than raw tool payloads, but it can still reveal how a call was handled.

Recommended callback-assistant webhook pattern¶

If your team wants the final summary sent to another system, start with:

application/json
a short timeout
a simple target URL
a body that includes the final summary, source number, destination number, and timestamps

Keep the first version small. Avoid building a giant payload until the stored summary itself is stable.

How to review this area¶

For the callback assistant, use this sequence:

make sure the live callback flow works
make sure the stored summary in Call History is correct
customize the Summary Prompt only if the default format is not good enough
enable Summary Email or Summary Webhook
send a test where available
confirm the downstream inbox or system receives the expected output

Common mistakes¶

Fixing post-processing before the live call works¶

If the assistant is still missing the callback number during the live call, post-processing will not rescue that. Fix the call flow first.

Over-formatting the summary prompt¶

If the prompt is too elaborate, the summary becomes harder to scan. Keep it operational and short.

Confusing Email Tool with Summary Email¶

These are not the same feature. If the team expects a tenant-level post-call delivery rule, use Summary Email here, not only the live Email Tool.

Sending full history to every recipient¶

Conversation history can be helpful for QA, but it is often too much for a normal team inbox. Enable it only when the recipients actually need the transcript.

Confusing PII removal with summary prompt changes¶

Remove PII in Call History removes personal data from the stored call record and redacts generated notes. It is a post-call privacy action, not the same as changing the Summary Prompt.

Sending too much data to the webhook too early¶

Start with a small payload and expand only after the summary structure is proven stable.

Read this next¶

Call History to inspect the final stored summary
Built-in Tools if you want the live Email Tool instead of tenant-level post-call delivery
API Tools if the live assistant should create structured records during the conversation