Company profile
| Company | WatchTower IT Solutions |
| Profile | Managed Service Provider |
| Use case | Monitoring alert triage |
| Stack | Autotask, RMM |
Finding the opportunity
WatchTower IT runs a high-volume monitoring alert queue in Autotask. The queue is noisy by design — most alerts self-heal within minutes thanks to existing RMM automations — but the few that genuinely need attention get buried, and tickets routinely sat for days or a week before a technician picked them up.
Rather than scope a feature request, WatchTower used Bumblebee's AI assistant to explore the problem directly. The conversation surfaced a clear, bounded automation: a workflow that continuously scans the monitoring queue, distinguishes real issues from self-healed noise, and routes the exceptions to a human — applying WatchTower's own rules, not a generic template.
The build
The entire workflow was built self-serve, in conversation with the Bumblebee agent. WatchTower's real operating logic — the parts that normally live in a tech's head — became explicit workflow rules:
- Detect self-heal signals in ticket notes (service started, device healthy, disk cleanup completed) to recognize alerts that already resolved themselves
- Honor existing RMM automations — e.g. low-disk alerts only escalate if they sit in the queue for more than 24 hours, since a script normally clears them first
- Route escalations: escalate genuine issues to the triage queue with a triaged priority, flag self-healed alerts as auto-close candidates, and leave a clear note explaining the decision
- Post internal-only notes so neither external nor co-managed clients ever see the automation's reasoning
Critically, WatchTower drove the build. Tony unlocked the workflow, inspected individual nodes to verify the auto-close criteria, asked the agent to make changes in plain English, and reviewed run traces to confirm the logic was sound. The first runs happened in dry-run mode — no live changes — so the team could validate behavior against real tickets before trusting it. Once the escalations and notes looked right, a single instruction flipped both terminal nodes from dry run to production.
Before
- ×Scope a request, wait on a vendor backlog
- ×Generic rules that ignore in-house automations
- ×No way to validate before going live
- ×Changes require a developer round-trip
After
- Discover and build the workflow in-conversation
- WatchTower's own triage rules, encoded exactly
- Dry-run mode validated against real tickets first
- Edits, tuning, and scheduling done in plain English
The outcome
In two one-hour sessions, WatchTower went from an idea to a live, scheduled workflow — now running automatically every four hours during business hours, triaging and escalating tickets without anyone having to kick it off.
The operational impact was immediate: average first response time on alert tickets dropped from roughly a week to a day. Real issues now surface to the triage queue within hours instead of languishing behind self-healed noise, while the existing RMM automations are left untouched and technicians only review the exceptions that genuinely need judgment.
“It's going to start moving tickets for you, with or without you knowing — it just works in the background.”