Sentiment, Summaries, and Duplicates
Ticket sentiment
Section titled “Ticket sentiment”The Ticket Sentiment module analyzes the tone and emotional context of ticket communications to provide better insight into customer satisfaction and urgency. By applying sentiment analysis across boards, teams can proactively identify frustrated or dissatisfied clients and prioritize their cases for faster resolution.
Fields & options
Section titled “Fields & options”- Boards (comma-separated, empty for all boards) Defines which boards are monitored for sentiment analysis. If left empty, sentiment evaluation applies to all boards. Example: Professional Services, Help Desk, Escalations, SOC.
Behavior
Section titled “Behavior”Each incoming ticket message is scanned for sentiment indicators such as positive, neutral, or negative tone. The system then tags the ticket with the detected sentiment level. Negative or urgent sentiment can be escalated, while positive sentiment may feed into customer satisfaction metrics. This information helps engineers and managers adjust their response approach and prioritize client interactions effectively.
Best practices
Section titled “Best practices”- Apply sentiment analysis to client-facing boards where communication tone strongly impacts customer satisfaction.
- Review negative sentiment alerts regularly to prevent churn and improve client retention.
- Use sentiment data in performance reviews and customer experience KPIs.
- Combine with escalation policies to automatically raise priority for highly negative or urgent tickets.
- Keep sentiment evaluation enabled across multiple boards for a holistic view of customer mood trends.
Ticket summary rewrite
Section titled “Ticket summary rewrite”The Ticket Summary Rewrite module standardizes and improves the clarity of ticket summaries. By leveraging AI-driven rewriting, it ensures that ticket subjects are concise, accurate, and aligned with organizational naming conventions. This improves searchability, reporting, and collaboration across boards.
Fields & options
Section titled “Fields & options”- Boards (comma-separated, empty for all boards) Defines which boards the rewrite process applies to. If left empty, all boards are included. Example: Professional Services, HelpDesk, SOC.
- Enable Ticket Summary Rewrite Activates the summary rewriting process for tickets in the defined boards.
- Teams Chat/Conversation Id Specifies the Microsoft Teams channel ID where notifications of summary rewrites are posted.
- Keep “TAG” at the start of the summary if exists Preserves any existing tags at the beginning of the ticket summary while rewriting the remaining text.
- Add Internal Note to the ticket Appends an internal system note explaining when and how the summary was rewritten.
- Change The Ticket Summary Directly updates the ticket summary with the rewritten version.
- Send Notification to the Teams Chat Posts a notification to the configured Teams channel whenever a ticket summary is modified.
Behavior
Section titled “Behavior”When enabled, the system reviews ticket subjects, rewrites them for clarity and consistency, and updates the ticket record. If a summary contains a recognized tag (e.g., project code or SLA marker), it is preserved at the beginning. Internal notes provide an audit trail of changes, while Teams notifications ensure visibility of updates for stakeholders.
Best practices
Section titled “Best practices”- Enable rewriting across high-volume boards to improve readability and reduce ambiguity in reports.
- Preserve tags to maintain traceability with project or SLA identifiers.
- Use Teams notifications selectively to avoid notification fatigue.
- Periodically review rewritten summaries to confirm that AI-driven changes align with organizational standards.
- Keep internal notes enabled for compliance and historical tracking of ticket modifications.
Ticket duplicate detection
Section titled “Ticket duplicate detection”Ticket Duplicate Detection prevents duplicate workload, consolidates related requests, and identifies wider customer outages. The module monitors new and updated tickets on a target board, merges same-contact duplicates, and can build parent–child structures for incident swarms. Optional Teams notifications and internal notes provide full visibility and audit trails.
Fields & options
Section titled “Fields & options”- Ticket Duplicate Detection Enables the duplicate/outage logic for the selected board.
- Ticket Duplicate Detection Board Board where detection runs. Use this to scope processing to a specific queue.
- Ticket Duplicate Detection Teams Chat Microsoft Teams conversation ID to receive detection/merge notifications.
- Ticket Merge Duplicates For Same Contact Automatically merges new tickets from the same contact when content is substantially similar.
- Customer Outage Detection and Parent-Child Ticketing Detects multi-user/customer-wide incidents and links related tickets under a parent outage ticket.
- Ticket Detect Potential Service Outage (Optional) Predicts outages from anomaly signals before volume spikes. When disabled, only explicit swarms are processed.
- Ticket Detect Potential Service Outage Threshold In Minutes Time window for clustering tickets into an outage (e.g.,
60). - Ignore Tickets From Templates Skips tickets created by templates to avoid false positives.
- Ignore Companies (comma-separated) List of companies to exclude from detection (e.g., CatchAll (for email connector)).
- Ticket Duplicate Detection Add Note Adds an internal note describing the duplicate/outage action taken.
- Ticket Duplicate Detection Send Message Sends a summary message to the configured Teams channel for visibility.
Behavior
Section titled “Behavior”On ticket creation/update, the engine compares subject, body, requester, and recent ticket history within the configured board. If a same-contact duplicate is detected, it merges or links the ticket and posts an internal note. When multiple tickets across a company match within the threshold window, a parent outage ticket is created (or updated), and related tickets are attached as children. If Teams integration is set, concise notifications (action, parent link, impacted count) are posted. Ignored templates/companies are excluded from all checks.
Best practices
Section titled “Best practices”- Keep the threshold window aligned with your SLA response times (e.g., 30–90 minutes).
- Enable Ignore Tickets From Templates to reduce noise from auto-generated work items.
- Start with one high-volume board; validate merges before enabling across all queues.
- Use Teams messages sparingly—post only merge/outage summaries to avoid alert fatigue.
- Regularly review ignored companies and template rules as integrations evolve.
