Super Magic Skills & Use Cases

Updated 4 days ago by Jake Gipson

New to Skills? Check out everything you need to know about creating Super Magic Skills here:

More Skills & Use Cases Are Coming 🚀

We’re just getting started. More tested Skills and real-world use cases will be added over time, so check back regularly for new additions.

In the meantime, don’t hesitate to ask Super Magic to help you create a Skill for your own workflow. Whether you’re automating repetitive tasks, preparing for meetings, or streamlining your day-to-day, Super Magic can help you build a custom Skill tailored to your needs.

The Skills below have been tested against real ticket data and are ready to use.

Ten full Skills you can copy in right now

These ten are Skills built for service desk. They've been tested against real ticket data and are designed to be pasted into Super Magic as-is, with a couple of bracketed values swapped in.

Skill 1 — Client Health Scan: Early Churn Warning

Surfaces the accounts sliding toward trouble before they become a save-or-lose situation.

Who runs it: service delivery leadership, monthly, across all service boards.

What it gives you: a ranked list of 5 clients (up to 10 with genuine ties) showing the strongest combination of risk signals, each with a "why flagged," "evidence," and "suggested next step." Designed to anchor the first 10 minutes of a monthly service delivery meeting.

"Run a client health scan across the [Board 1], [Board 2], and [Board 3] boards, covering the past 30 days. This feeds our monthly service delivery meeting, so the goal is to surface clients who may be at risk before it becomes a bigger problem, not to review every client in detail.

To avoid missing activity from earlier in the 30-day window due to result caps, run separate targeted searches per board for each of the four warning signs below, rather than one general pull of recent activity:

1. Low or declining sentiment scores
2. Aging or 'no response' tickets
3. Recurring issues without an identified root cause
4. Unresolved Priority 1 or critical-severity tickets, regardless of age or whether they're part of a recurring pattern. A single unassigned or unresolved P1 is a risk signal on its own, even as an isolated event.

If any individual search still hits a result cap, say so explicitly in your methodology note rather than presenting the data as complete.

Rank and select the 5 clients showing the strongest combination of these signals across all boards. A client with an unresolved P1/critical ticket should be flagged even if it doesn't show up as a recurring pattern or in the other three signals. If there are genuine ties or borderline cases at the cutoff, extend the list up to 10 rather than forcing an arbitrary cut. Don't flag a client based on ticket volume alone — the concern here is risk signals, not raw activity level.

Open with a brief summary: how many clients were reviewed across the boards, and how many were flagged this month. Then for each flagged client, provide three separate labeled parts:

• Why flagged: which of the four warning signs applied and a brief explanation
• Evidence: a short narrative summary of the supporting tickets or pattern, with a representative example or two. Ticket IDs aren't necessary — describe the issue in plain language.
• Suggested next step: a brief, concrete recommendation the team can use as a starting point for discussion (e.g. account manager outreach, a technical review, a proactive fix).

Keep each client's entry concise — this is meant to guide a live discussion, not replace it. Close with a brief methodology note: how many threads were reviewed per board, and whether any search hit a result cap that may have limited coverage of the full 30-day window."

Skill 2 — QBR Prep: QBR Blind-Spot Brief

The account manager shows up knowing the things the client won't raise themselves.

Who runs it: account managers, quarterly, per client.

What it gives you: a 600-word, section-headed internal brief covering ticket volume, top recurring issues, long or high-effort tickets, sentiment trends, and opportunities for a project or training engagement. It's tuned to surface the things a client won't bring up themselves.

"Prepare the QBR (quarterly business review) prep report for [Client Name], covering the past 3 months. This is for the account manager's use in preparing meeting notes and talking points ahead of the client check-in, not something to hand to the client directly.

Open with a brief overview: total ticket volume for the period, opened vs closed, and a general sense of the client's overall support activity level. If the true ticket count can't be determined precisely because the volume exceeds what a single query can return, say so plainly and give your best order-of-magnitude estimate rather than presenting a specific number as exact, and don't try to reconcile it against a prior run.

Then cover, with light section headers so this can be scanned quickly:

1. Recurring issues: identify the top 4–5 recurring patterns only, ranked by how much they matter (frequency, client impact, or technician time consumed), not every pattern that exists. For each, state how often it occurred, describe it in one to two sentences, and give exactly one representative example described in plain language (no ticket IDs). Do not list every affected user or asset.
2. Long or high-priority tickets: identify the top 5 tickets from the period that either took a long time to resolve or consumed significant time/effort, regardless of current status. Present as a short prose list, one line each, no tables, no ticket IDs. Note whether each is a 'sat open a long time' case or a 'high effort' case.
3. Client sentiment: overview of sentiment trends across the client's tickets this period, including any notably low scores and what drove them, described in plain language without ticket IDs.
4. Opportunities: flag areas where a project, infrastructure update, or user training could reduce ticket volume or improve client experience, including recurring requests that suggest the client is hitting a limitation of their current setup.

Throughout, pay particular attention to issues or patterns the client is unlikely to bring up themselves. This report has a hard limit of 600 words. Prioritize signal over completeness — if you have to choose between covering all four sections briefly or covering fewer sections in depth, cover all four. Do not include ticket ID numbers anywhere in the report. Format this as a report the account manager can scan quickly before the meeting, not a compressed narrative summary."

Skill 3 — Escalation Risk Detector: Escalation Early Warning System

Spot the threads about to blow up while there's still time for a senior tech to step in.

Who runs it: Service desk Admins, Teams Leads, Senior Technicians

What it gives you: Scan open threads for sentiment signals, SLA proximity, and stalled replies — flags threads likely to escalate before they do, so a senior tech can intervene early.

1. Gather scope — Ask the technician if they want to scan all open threads or narrow by client, board, or assigned member. Note any preferences before proceeding.
2. Pull open threads — Use search_tickets with state="open" and any filters from step 1. Fetch up to 100 tickets. If scoping to a client, resolve client_company_id via search_clients first.
3. Flag negative sentiment — From the results, identify any threads with sentiment of negative or very_negative. Mark these as Sentiment Risk.
4. Flag stalled threads — Identify threads with no update in 3+ days using updated_to set to 3 days before today. Mark these as Stalled.
5. Flag SLA proximity — For any thread where the SLA breach time appears close (within 4 hours) based on ticket detail, mark as SLA Risk. Fetch individual ticket detail via search_tickets with a single internal_ticket_id to read SLA timer fields when needed.
6. Score and rank — Assign each flagged thread a risk score:

• Negative sentiment → +2
• Very negative sentiment → +3
• Stalled (3–5 days) → +1
• Stalled (5+ days) → +2
• SLA breach within 4 hours → +3
• Multiple flags → scores stack

1. Present the report — Display a ranked table of at-risk threads, highest score first. For each, show: thread link, client, assignee, risk flags, score, and last updated date. Group into tiers: 🔴 Critical (5+), 🟠 High (3–4), 🟡 Watch (1–2).
2. Recommend actions — For each 🔴 Critical thread, suggest a specific next step (e.g. "Add an update note", "Escalate to senior tech", "Check SLA breach time"). Offer to add an internal note or reassign directly.
3. Offer to save — Ask if the technician wants to run this scan on a schedule or save any flagged threads for follow-up.

Skill 4 — Daily Triage Routine: Morning Control Tower

Start the day knowing exactly what's unassigned, stale, or about to breach.

Who runs it: Service Desk Managers

What it gives you: Daily checks of unassigned threads, reviews P1s, scans SLA timers, and dispatches work across the team.

Step 1 — Unassigned Threads

1. Call search_tickets with assigned=false and state="open".
2. List all unassigned threads, grouped by priority (highest first).
3. For each thread, note the client, summary, and how long it has been open.
4. Recommend an assignee based on the thread type or ask the technician who should own each one.
5. Assign threads using update_ticket (assigned_member_id) once the technician confirms.

Step 2 — P1 / Critical Priority Review

1. Call search_tickets with priority="Priority 1" (or the MSP's equivalent critical label) and state="open".
2. List all open P1 threads with their current status, assignee, and last-update timestamp.
3. Flag any P1 that has had no update in the last 2 hours as STALE — surface these first.
4. For stale P1s, suggest adding an internal note or escalating to a senior tech.

Step 3 — SLA Timer Scan

1. For each open P1 and P2 thread returned above, fetch the full ticket detail (single internal_ticket_id lookup) to read the SLA timers.
2. Identify threads where the SLA respond or resolve deadline is within 2 hours or already breached.
3. Present a prioritised list: BREACHED → AT RISK (< 2 hrs) → HEALTHY.
4. For any BREACHED or AT RISK thread, recommend an immediate action (assign, escalate, update status).

Step 4 — Dispatch Summary

1. Compile a morning dispatch summary:
   • Total open threads (all priorities)
   • Unassigned count (before and after Step 1)
   • P1 count and stale P1 count
   • SLA breached count / at-risk count
   • Top 3 threads needing immediate attention (with links)
2. Present the summary in a clean, scannable format.
3. Ask the technician if they want to act on any flagged threads before closing the routine.

Skill 5 — Quality Assurance: Clean Ticket Close Gate

nothing substandard closes; anything failing bounces back with the exact fix.

Who runs it: Service desk technicians, team leads, or anyone responsible for ticket quality before closure.

What it gives you: An automated QA review of the ticket against four closure requirements. If all checks pass, the ticket is closed automatically. If any check fails, the ticket is re-opened and an internal note is added detailing exactly which checks passed or failed and what needs to be corrected.

Review the ticket's full conversation and notes. Check all 4 criteria:

1. Customer issue was genuinely resolved (dismissive/hostile responses don't count)
2. Ticket type, subtype, and item are set
3. A technician is assigned as owner
4. A time entry was submitted

**QA Passed (all 4 met):** Set status to >Closed.

**QA Failed (any missed):** Do both steps in order:

- Set status to Re-Opened

- Add an internal note in plain text only (no Markdown, tables, bold, emojis, or symbols) using this exact format:

QA Failed - Action Required:

- PASS/FAIL: Customer issue resolved: [explanation]

- PASS/FAIL: Ticket type, subtype and item set: [explanation]

- PASS/FAIL: Technician assigned: [explanation]

- PASS/FAIL: Time entry submitted: [explanation]

Skill 6 — 🔀 Duplicate & Similar Ticket Merge Detector: Duplicate Ticket Hunting & Remediation (Connectwise Only)

You stop working the same issue twice - two tickets become one with the full history intact

Who runs it: Service desk technicians, team leads, or anyone responsible for working and closing tickets

What it gives you: Detects open tickets from the same contact or company that are duplicates or closely related, and flags them for merging with a technician-facing internal note.

You are a duplicate ticket detection agent. When this skill runs on a ticket, follow these steps:

1. **Identify the ticket context**: Note the contact name, company, and the issue described in the ticket title and description.
2. **Search for similar open tickets**: Search for other open tickets from the same contact (and same company) using keywords from the ticket title (e.g. "printer", "VPN", "email", "password"). Look for tickets created in the last 30 days.
3. **Evaluate for merge candidates**: A ticket is a merge candidate if:

- It is from the same contact OR same company

- It describes the same or very similar issue (e.g. both are printer issues, both are login problems)

- It is currently open (not closed)

- It has not already been merged into another ticket

1. **If merge candidates are found**:

- Add an **internal note** to the current ticket listing the candidate tickets with their IDs, summaries, contacts, and statuses.

- Format the note clearly, e.g.:

"🔀 **Possible Duplicate/Similar Tickets Detected**

The following open tickets may be duplicates or closely related and could be merged:

- [Ticket #XXXX] – [Summary] – Contact: [Name] – Status: [Status]

- [Ticket #XXXX] – [Summary] – Contact: [Name] – Status: [Status]

Please review and confirm before merging. To merge, reply to this note with 'merge [child ticket ID] into [parent ticket ID]'."

1. **If no merge candidates are found**:

- Do nothing (no note needed).

1. **Do NOT auto-merge under any circumstances.** The internal note added in Step 4 is the only action taken. The technician must review the flagged tickets and explicitly confirm the merge. This ensures no tickets are merged incorrectly due to superficial similarity.

Skill 7 — 🔀Autotask Duplicate & Similar Ticket Merge Detector: Duplicate Ticket Hunting & Remediation (Autotask Only)

You stop working the same issue twice - two tickets become one with the full history intact

Who runs it: Service desk technicians, team leads, or anyone responsible for working and closing tickets

What it gives you: Use this skill when a technician needs to merge two AutoTask tickets. AutoTask's API does not support native ticket merging, so this multi-step process simulates a merge manually.

Before starting, confirm with the technician:

• Source ticket — the ticket to be merged away and closed.
• Destination ticket — the ticket that will survive and carry all history.

1. — Set source ticket status to Complete Call update_ticket on the source ticket with the "Complete" status_id. If you do not already have the status_id, call list_ticket_statuses first to resolve it.
2. — Set source ticket Queue to match the destination ticket's Queue Fetch the destination ticket via search_tickets (single internal_ticket_id lookup) to get its board_id. Call update_ticket on the source ticket with that board_id.
3. — Add an internal note to the source ticket Call add_ticket_note on the source ticket with is_internal=true. Note text (adapt as needed): "This ticket has been merged into ticket [DESTINATION_TICKET_ID]. Please refer to that ticket for all further updates."
4. — Add an internal note to the destination ticket Call add_ticket_note on the destination ticket with is_internal=true. Note text (adapt as needed): "Ticket [SOURCE_TICKET_ID] has been merged into this ticket. All history from the source ticket has been carried over below."
5. — Query all content from the source ticket Call search_tickets with internal_ticket_id = source ticket and include_messages=true. Review the full detail view for:

• All notes/messages (internal and external)
• Schedule entries
• Any other linked data visible on the ticket

1. — Recreate all content on the destination ticket For each note/message retrieved from the source ticket:

• Call add_ticket_note on the destination ticket with is_internal=true.
• Preserve the original author name, date context, and internal/external flag where possible.
• Prefix each recreated note with: "[Merged from ticket SOURCE_TICKET_ID — originally posted DATE]"

For any schedule entries found on the source ticket:

• Call schedule_ticket on the destination ticket to recreate them with the same member, date, and time block.

1. — Confirm completion Summarise what was transferred to the technician:

• Confirm status and queue were updated on the source ticket.
• List how many notes were recreated on the destination ticket.
• List any schedule entries recreated.
• Confirm the merge is complete.

Skill 8 — Technician One-on-One Prep: Coaching-Ready 1:1 Brief

The manager walks into the meeting already knowing the real story, ready to coach instead of open with "how's it going."

Who runs it: service managers, monthly, per engineer.

What it gives you: a five-paragraph, under-300-word candid brief on ticket load, response and resolution patterns, and client sentiment — the kind of read that anchors a real conversation instead of a "how's it going."

"Prepare a one-on-one prep summary for [Engineer Name] covering the past month (last 30 days). This is for the service manager's use only, ahead of a status check-in meeting, so be direct and candid. Review:

1. Ticket load and completion: how many tickets they worked, opened vs closed, and note anything still open or aging that's worth flagging. This is a holistic look, not a strict volume target. If a query hits a result cap and the true count is uncertain, say so explicitly rather than presenting an estimate as exact.
2. Response and resolution time: how they're tracking on time-to-first-response and time-to-resolution across their tickets this month, and call out any pattern of slow response or resolution if one exists.
3. Client sentiment: pull Thread's sentiment analysis across their tickets this month and note anything notably positive or negative.

Close with two short sections: a couple of standout highlights (can come from any of the above, including technical approach or client communication even if not explicitly listed), and a couple of areas to improve.

Write in tight narrative prose, 5 paragraphs total, no more than 300 words combined. Synthesize and summarize rather than enumerating every ticket. Only name a specific client or ticket if it genuinely needs the manager's attention or action; everything else should be described in aggregate (e.g. 'the rest closed within a day or two with no issues'). Skip ticket links and IDs entirely."

Skill 9 — Board & Status Configuration Guide: Board Routing & Setup QA

Ensures tickets land in the right place with the right status, priority, and SLA every time.

Who runs it: Service desk Admins

What it gives you: Verifies boards are correctly configured with the right statuses, priorities, and default settings in the PSA.

1. Identify the board to audit — Ask the technician which board they want to verify, or call list_boards to list all active boards and let them pick one.
2. Review statuses — Call list_ticket_statuses for the board. Verify:

• There is at least one open/active status (e.g. "New", "In Progress", "Waiting on Client")
• There is at least one closed status (e.g. "Resolved", "Closed", "Completed")
• No duplicate or ambiguously named statuses exist
• A sensible default status is set for new tickets landing on this board

1. Review priorities — Call list_ticket_priorities. Verify:

• All expected priority tiers are present (e.g. Low, Medium, High, Critical)
• A default priority is configured so tickets aren't created without one
• Priority names are consistent with SLA agreements in use

1. Check default settings — Confirm with the technician:

• Is the correct default board set for inbound tickets (email, Thread Messenger, phone)?
• Are SLA timers attached to the right priority/status combinations?
• Are auto-assignment rules or round-robin settings configured if needed?

1. Spot-check live tickets — Call search_tickets with board_id and state="open" (limit 5–10). Verify tickets are landing with the expected status and priority — flag any with missing/null values.
2. Flag issues found — Summarise any gaps (missing statuses, no default priority, tickets with null status, etc.) and recommend corrective actions. If the technician wants to fix a ticket's status or priority, use update_ticket.
3. Document findings — Offer to add an internal note to a relevant thread or save a summary for the technician's records.

Skill 10 — Flow Builder Quick-Start: Live Automation in Minutes

Go from "I wish this happened automatically" to a running flow without deep admin know-how.

Who runs it: Service Desk Admins, Service Desk Managers

What it gives you: Builds a common automation flow step-by-step — e.g. auto-assign by keyword, escalate by priority, change status on condition, or notify a member.

1. Clarify the goal — Ask the technician what the flow should do. Common examples:
   • Auto-assign tickets by keyword
   • Escalate tickets by priority
   • Change status when a condition is met
   • Notify a member when a ticket is created/updated
2. Discover filter attributes — Call list_flow_filter_attributes to find available filter fields (board, priority, status, keywords, contact type, etc.) and note their attribute_id and type.
3. Resolve filter values — For each attribute the flow will filter on, call list_flow_filter_attribute_values with the attribute_id to get valid values. Note the value (ID) and display_value (human-readable name) for each.
4. Discover available actions — Call list_flow_actions to see what the flow can do (assign member, change status, send notification, run skill, etc.). Note the action structure required.
5. Confirm the plan with the technician — Before building, summarise:
   • Trigger condition(s) (filters)
   • Action(s) to take
   • Any notifications to send Ask the technician to confirm before proceeding.
6. Build the flow — Call create_flow with:
   • A clear name and description
   • rules: each rule needs attribute_id, value, value_type, and display_value (required for object types)
   • For OR logic across multiple values of the same attribute, use a group with group_combinator: 'or'
   • actions: structured per the action list results
   • notifications: optional member/team alerts
7. Share the flow URL — Always include the flow_url link in your response so the technician can review and edit it in the admin panel.
8. Offer to save as a skill — If the technician built something reusable (e.g. "escalate Priority 1 tickets"), offer to save the pattern as a named skill for future use.

How did we do?