Reporting & admin
The Reporting & admin tab contains settings related to post-conversation reporting and administration, such as how conversations are categorized and summarized and which actions should be execute. These settings shape the data available in your conversation reports and post-call workflows.
Conversation categorization
Topics
Topics help you categorize and analyze your conversations. After a conversation is completed, topics are automatically assigned based on analysis of the entire conversation. A conversation will be labeled with multiple topics if relevant.
Newly added topics apply to future conversations only — existing conversations are not retroactively labeled.
Conversation summaries
Customize how your agent generates summaries of conversations. Summaries are automatically created after each conversation and help you quickly understand what happened without reading full transcripts.
Language instructions
Define which language(s) should be used for summaries and when.
Example:
Use either Dutch (preferred) or English (if the transcript is in English).
Tips:
- Specify your preferred language first
- Include fallback languages for multilingual scenarios
- Keep it concise and clear
Summary content instructions
Define the structure and content of the summary. Specify what information should be included and in what format.
Example:
- one sentence describing the topic of the conversation with high specificity.
For example, "the customer called about a stolen card that they want to block"
- [if applicable] one sentence explaining if and how the customer was identified.
For example, "I identified the customer by their date of birth, address and name."
If you did not identify the customer, you can omit this sentence.
- one sentence describing the outcome of the conversation.
For example, "The customer was unable to block the card themselves because they
lost their phone with the card. I have blocked the card for them and requested
a new card to be sent to them."
Tips:
- Be specific about what information to include
- Provide example outputs for clarity
- Structure it as a bulleted list for easier reading
Information to exclude
List types of information that should never be included in summaries for privacy, security, and compliance reasons.
Example:
- any of the customer's personal information such as name, address, phone number, email, etc.
- any sensitive information such as account numbers, social security numbers, etc.
- any sensitive information such as religious topics, political topics, or health related information.
Even if the customer mentions it, you should not include it in the summary.
- try not to infer gender unless that is explicitly stated by the customer.
Instead, use "the customer" or "them" as appropriate.
Tips:
- Be comprehensive about excluded information types
- Consider privacy regulations (GDPR, HIPAA, etc.)
- Include both obvious (PII) and subtle (gender assumptions) exclusions
Good summary examples
Provide examples of well-written summaries that follow your guidelines. These help the AI understand your expectations.
Example:
The customer called about a stolen card that they want to block. I identified
the customer by their date of birth, address and name. The customer was unable
to block the card themselves because they lost their phone with the card. I have
therefore blocked the card for them and requested a new card to be sent to them.
Tips:
- Include 1-3 complete examples
- Make examples realistic and specific to your use case
- Show the desired tone and level of detail
Bad summary examples
Provide examples of poor summaries with explanations of what makes them inadequate. This helps the AI learn what to avoid.
Example:
The customer, Dave Mills, called about their card. I identified Dave according
to policy. It was stolen when he left his mosque. I blocked it and did the
usual follow up.
-> This is a bad summary because it includes the customer's name, the fact that
he left his mosque, it is not specific about the topic, it makes assumptions
about gender, and it did not specify that a new card was requested.
Tips:
- Include the bad example and an explanation of why it's bad
- Use the
->or similar marker to separate example from explanation - Cover different types of common mistakes
Post-conversation wrap-up
Instruct the agent about any additional tasks it should perform after each call has been completed, such as creating a support ticket or sending a follow-up email.
Wrap-up instructions
Common use cases:
- Create tickets for unresolved issues
- Send follow-up emails if information couldn't be collected
- Update records with conversation outcomes that couldn't be updated during the call
- Trigger escalation workflows for incomplete processes
- Log missing data points for manual follow-up
Example:
If you were unable to create a ticket during the call, create it now with any information that was collected.
If the customer requested a callback but you couldn't schedule it, create a task for the support team to follow up.
Actions used during wrap-up must have Post-call selected in their Conversation phases setting. Actions that are only available during the In call phase will be blocked during wrap-up.