/board-hygiene

name: "Board Hygiene"
description: >
  Board-wide ticket maintenance, distinct from working any single ticket:
  stale-ticket detection with per-status staleness thresholds, the
  Waiting-on-Client rot case and its three valid resolutions,
  duplicate/related-ticket detection signals and safe linking, and
  technician queue-balance assessment weighted by more than raw ticket count.
when_to_use: >-
  When performing recurring maintenance on the ticket board rather than
  working an individual ticket. Use when: stale tickets, tickets going cold,
  duplicate tickets, related tickets, waiting on client too long, queue
  balance, board cleanup, board audit, board maintenance.

Board Hygiene

Overview

A ticket board degrades quietly. Tickets go cold without anyone deciding to abandon them, duplicates get opened because nobody searched first, "Waiting on Client" becomes a place tickets go to be forgotten, and workload quietly piles onto whoever answers fastest. None of this shows up in a single-ticket view — it only shows up when you look at the board as a whole. This skill is that recurring sweep.

Anti-triggers

• **Working an individual ticket** — searching, updating, adding notes, or

closing one ticket is the PSA's surface; use `autotask-tickets`, `halopsa-tickets`, or `connectwise-psa-tickets`.

• **Correlating a ticket with device, asset, or change data** — pulling

cross-vendor context for one investigation is `shared-skills-incident-correlation`; this sweep reads the board's shape, not any single ticket's story.

Key Concepts

Stale-ticket detection

A ticket is stale when there has been no meaningful activity (status change, note, technician or client communication — not an automated system touch) for longer than a threshold appropriate to its current state:

| Ticket state | Suggested staleness threshold | |---|---| | Open / In Progress, assigned | 3–5 business days with no activity | | Unassigned | Shorter — see `dispatch-prioritization`; an unassigned ticket going stale is really a dispatch failure | | Waiting on Client | See the dedicated threshold below — this is a distinct case | | Waiting on Vendor / Waiting on Parts | Longer tolerance (5–10 business days), but still worth surfacing past that window |

Thresholds above are defaults to apply when the org hasn't documented its own norm — state which threshold you used, and prefer an org-documented value if one is available (e.g., in a connected documentation platform or prior instructions).

Pull the ticket's last-activity timestamp and current status from the connected PSA (discover the right tool via `conduit__search_tools` if unsure — see the `dispatch-prioritization` skill for the discovery pattern) rather than relying on the ticket's creation date, which tells you nothing about staleness.

Status-transition sanity: Waiting-on-Client

"Waiting on Client" is the status most likely to silently rot a ticket, because the technician has legitimately handed the ball to the client and has no natural trigger to check back. Treat a ticket in this status past a threshold (default: 5 business days, tune to org norm) as requiring one of:

• A client nudge (a follow-up note/email requesting the information or action still

needed)

• Reassignment back to internal ownership if the client's silence effectively means

"we'll pick this up when they respond, but someone should own watching for that"

• A close-as-resolved recommendation if enough time has passed that the client

issue is presumed resolved or abandoned (never do this automatically — recommend it, and require explicit confirmation before executing)

See the `stale-ticket-chaser` agent for the workflow that classifies *why* a ticket stalled and drafts the specific follow-up action.

Duplicate / related-ticket linking

Flag likely duplicates or related tickets using a combination of signals, since no PSA API reliably flags this on its own:

• Same client (and ideally same contact) with tickets opened within a short window

of each other (e.g., same day or overlapping)

• Overlapping keywords in subject/summary (fuzzy match, not exact string match —

"email down" and "can't send email" are the same incident)

• Tickets referencing the same asset/configuration item, if the PSA links tickets to

assets

When found, don't auto-merge — recommend linking (via the PSA's native ticket-linking/related-ticket feature if it has one) or consolidating into a single ticket with a note explaining the merge, and let a human confirm before executing anything destructive (closing one of the tickets).

Queue-balance across technicians

Pull each technician's current open-ticket count (and ideally a rough complexity/ priority weighting, not just raw count) from the PSA's resource/agent data. A 10-ticket queue of quick password resets is not equivalent load to a 4-ticket queue of active P1 outages. Where the PSA doesn't expose enough detail to weight by complexity, fall back to raw open-ticket count and say so explicitly rather than presenting a false precision.

Surface imbalance as an observation, not an automatic reassignment — board hygiene identifies the imbalance; the `dispatch-coordinator` agent (or a human dispatcher) decides what, if anything, to move.

If no PSA is connected

State plainly that board hygiene cannot run without a ticket source: "No PSA is connected through the gateway, so there's no board to audit." Do not fabricate ticket counts, staleness, or duplicates.

Common Workflows

Full board sweep

1. Discover the connected PSA's tools (`conduit__search_tools` if unsure of names). 2. Pull all open tickets with status, last-activity timestamp, assignee, and client. 3. Bucket into: stale (by the thresholds above), stuck-in-Waiting-on-Client, duplicate/related clusters, and per-technician load. 4. Report each bucket with the worst offenders first (oldest stale ticket, longest Waiting-on-Client, most load-imbalanced techni