Catching the Catchall: How AI Tames Your Spam-Filled Inbox Board
Every MSP has that one board. The catchall inbox — support@, help@, info@ — where everything lands before it gets sorted. Client requests, vendor marketing, automated notifications from every SaaS product your clients use, phishing attempts, invoice spam, newsletter subscriptions, and the occasional legitimate emergency buried under 50 emails that nobody needs to see.
Your technicians know the pain. They open the board in the morning and see 80 new tickets. Maybe 15 of them are real. The other 65 are automated alerts from monitoring tools (that have their own dashboards), marketing emails from vendors, auto-replies, calendar notifications, and outright spam. But someone still has to look at each one to determine whether it’s real — because the one time you ignore the catchall board, the one real ticket in there is a client with a down server.
It’s a tax on your help desk. Not a huge one per ticket, but at volume, it adds up to hours of wasted technician time every week.
The Anatomy of a Noisy Catchall
The catchall inbox is noisy by design. It’s the safety net — the address that catches everything that doesn’t match a more specific routing rule. That’s a good thing, because it means legitimate requests never fall through the cracks. But it also means every piece of noise that doesn’t get filtered upstream ends up in your ticket queue.
Here’s what typically fills a catchall board on a Monday morning:
Automated System Notifications
Your clients’ cloud services generate a constant stream of notifications. Microsoft 365 sends service health updates. Azure sends billing alerts. Google Workspace sends admin notifications. Security tools send scan summaries. Backup tools send success/failure reports. Each one creates a ticket.
Most of these are informational — no action required. But they look like tickets in your queue, and someone has to verify that before closing them.
Vendor Marketing and Sales Emails
Vendors who have your support email on a list. Product announcements, webinar invitations, case studies, “just checking in” emails from sales reps. They create tickets that have no business being tickets.
Auto-Replies and Bounces
When your team sends a response to a ticket and the recipient has an out-of-office reply enabled, that auto-reply comes back to your catchall and creates a new ticket. Bounced emails do the same. These create phantom tickets that bloat your queue metrics and waste dispatcher time.
Spam and Phishing
Despite email filtering, spam still gets through. Nigerian prince emails, fake invoices, credential phishing — they all create tickets that someone has to identify and close. And the phishing emails are particularly problematic because they require enough attention to recognize that they’re malicious, not just irrelevant.
Legitimate Client Requests
Mixed in with all of the above: real tickets from real clients who emailed the catchall address instead of using the portal, or whose issue didn’t match an existing routing rule. These are the emails you actually need to act on — and they’re the hardest to find in the noise.
The Manual Approach Doesn’t Scale
Most MSPs handle catchall noise one of three ways, and none of them work well at scale.
Dedicated dispatcher. One person spends the first hour of every morning triaging the catchall board — closing junk, routing real tickets, and flagging ambiguous ones. This works until ticket volume grows past what one person can handle in an hour, and it’s a terrible use of a skilled technician’s time.
Ignore and hope. The board gets checked when someone has time, which means real tickets sit for hours or days. Clients notice. SLAs suffer.
ConnectWise/Autotask rules. Keyword-based automation rules that close tickets matching certain patterns. These help with the most obvious spam but break constantly — a rule that closes tickets containing “unsubscribe” will eventually close a real ticket where a client mentions unsubscribing from a compromised mailing list.
How AI Solves the Catchall Problem
Junto’s Catchall Ticket Router processor is specifically designed for this problem. It’s one of the 11 processors in the triage pipeline, and it operates on every ticket that enters through a catchall-designated inbox.
Intelligent Classification, Not Keyword Matching
The processor reads the full content of each email — subject, body, sender, headers — and classifies it into categories:
- Spam/Marketing — Vendor emails, newsletters, unsolicited sales outreach. Auto-closed with a log entry.
- Automated Notifications — System-generated alerts that are informational only. Auto-closed or routed to a monitoring board, depending on your configuration.
- Auto-Replies/Bounces — Out-of-office replies, delivery failures, read receipts. Auto-closed and linked to the original ticket if applicable.
- Phishing/Malicious — Suspicious emails flagged for security review rather than auto-closed.
- Legitimate Requests — Real client emails that need to be triaged and routed as normal tickets.
- Ambiguous — Emails the processor isn’t confident about, flagged for human review rather than acted on automatically.
This isn’t keyword matching. The processor understands that a Microsoft 365 service health notification is different from a client reporting that Microsoft 365 is down for their office, even though both emails mention “Microsoft 365” and “service issue.”
Configurable Confidence Thresholds
Not every MSP is comfortable with the same level of automation. The processor lets you set confidence thresholds for each action:
- High confidence — Auto-close spam and automated notifications without human review. Most MSPs set this for obvious noise after seeing the processor’s accuracy over a few days.
- Medium confidence — Flag for quick human review before closing. A dispatcher glances at a summary rather than reading 50 individual emails.
- Low confidence — Route to the catchall board for full human triage, same as today. The processor adds its classification as context, so even manual review is faster.
You start conservative and open up as you trust the system.
What Happens to the Noise
Auto-closed tickets aren’t deleted. They’re closed with a classification tag and a log entry explaining why the processor closed them. You can audit these at any time — and if the processor made a mistake, you can reopen the ticket and adjust the confidence thresholds.
This matters for MSPs that need to demonstrate to clients that nothing falls through the cracks. You can show that 65 automated notifications were received and acknowledged, rather than having them sit as open tickets cluttering your metrics.
The Numbers
Here’s what a typical MSP sees after deploying the catchall processor:
- 60-80% of catchall tickets are auto-closed as noise (spam, auto-replies, informational notifications)
- 5-10% are flagged as ambiguous for quick human review
- 10-30% are genuine requests that get routed into the normal triage pipeline
For an MSP receiving 100 catchall tickets per day, that means technicians go from triaging 100 tickets to reviewing 5-10 flagged items and working 10-30 real tickets. The other 60-80 tickets are handled in seconds, not minutes.
Over a month, that’s hundreds of hours of technician time redirected from closing junk tickets to solving real problems.
A Cleaner Board, A Calmer Team
Beyond the time savings, there’s a psychological benefit to a clean board. When technicians open their queue and see 30 real tickets instead of 100 mixed tickets, the day feels more manageable. They can focus on actual client issues instead of wading through noise to find them.
Dispatchers make better routing decisions because the board reflects genuine workload. Metrics become meaningful — your open ticket count, average response time, and SLA compliance all become more accurate when the denominator isn’t inflated by 70% noise.
The catchall inbox is always going to receive everything. That’s its job. But your technicians shouldn’t have to sort through everything. That’s the processor’s job.
Stop wasting time on catchall noise. Deploy Junto’s Catchall Ticket Router and see a cleaner board by tomorrow morning. See the processor documentation for configuration options.
