The problem
Teams using Slack were still drowning in email. The workflow was broken: important emails landed in inboxes, people forwarded them manually to Slack channels, context got lost, things fell through the cracks.
The root issue wasn't email volume - it was routing. Every email had a natural destination (a Slack channel, a person, a workflow), but there was no intelligent layer to make that connection automatically.
"We're spending 2–3 hours a day just deciding where to send things. Half our Slack channels are ghost towns because nobody routes email there." - Typical user complaint before SlackBot AI
The opportunity
With LLMs becoming accessible via API, the routing problem was suddenly solvable without a large ML team. The question wasn't whether AI could categorise emails - it clearly could. The question was: how do you build a system that actually deploys in an organisation within minutes, not months?
That's where the product thinking mattered as much as the technology.
The solution
SlackBot AI is a zero-configuration email-to-Slack routing system. It connects to a team's email inbox, uses an LLM to categorise and triage each incoming email, then routes it to the correct Slack channel with full context - subject, sender, summary, and suggested action.
How it works
- Email arrives in the monitored inbox
- n8n workflow triggers on new email (polling or webhook depending on provider)
- Email body + metadata passed to OpenAI for categorisation and summarisation
- LLM returns: category, priority, suggested channel, one-line summary, suggested action
- Xano stores the log + handles routing rules per organisation
- Formatted Slack message posted to the correct channel with full context
- Team reacts or replies directly in Slack - email is a ghost from this point
Stack decisions
Why n8n over Make.com or Zapier?
Self-hosted n8n gave us the ability to process email content without routing sensitive data through third-party servers. For enterprise clients with data compliance requirements, this was non-negotiable. n8n's flexibility also let us build custom conditional logic that would have been impossible in Zapier without 50 separate Zaps.
Why Xano for the backend?
We needed per-organisation routing rules, a message log, and a simple API that n8n could call. Xano gave us a production-grade database + REST API layer without writing a single line of backend code. Each organisation had their own routing table - Xano's relational database structure made this trivial to implement.
Why not build a full web app?
The temptation was to build a dashboard for users to configure routing rules. We killed that scope in the first hour. The MVP question was: can an AI make routing decisions without user configuration? If yes, the dashboard is a nice-to-have for v2. If no, the product doesn't work at all. We validated the AI routing first - it worked - and shipped without the dashboard.
Results
Adoption was organic - teams shared it with each other. The 200+ organisation count came without any marketing spend. The routing accuracy was high enough that teams stopped double-checking the AI within the first week of use.
Key decisions and tradeoffs
Ship in 23 hours or spend 2 weeks building?
The 23-hour constraint was intentional. I set a hard deadline to force scope discipline. Every feature that wasn't essential to the core "email → categorise → route" loop was cut. The result was a product people could install and use in 10 minutes, not configure for a day.
LLM categorisation vs. rule-based routing
Rule-based routing (if subject contains X, send to channel Y) would have been faster to build. But it would have required every organisation to configure their own rules - a setup friction that kills adoption. LLM categorisation meant zero setup: the AI figures out where an email belongs without you telling it. That's the difference between 200 organisations adopting it vs. 20.
What I'd do differently
- Build the dashboard earlier for power users who wanted more control
- Add a feedback loop so routing accuracy improved per-org over time
- Support multi-inbox routing from v1 (most orgs have 3–4 relevant inboxes)
What this demonstrates
SlackBot AI was built in 23 hours and served 200+ organisations. That's not a lucky accident - it's what happens when you apply product thinking to no-code tooling. The constraint forces you to find the core of the product, and no-code lets you ship that core without a 6-month dev cycle.
This is what I bring to every project: the ability to identify what actually needs to be built, then build it - fast, clean, and production-ready.