Slackbot Rocks Part 1: Why a 5-Person Team Migrated to Enterprise Grid
Let me tell you how a five person company ended up on Slack Enterprise Grid.
About a month ago, we were on Pro. Happy as clams. Back when I set up the instance for BrightHelm, I looked at Business+ and shrugged. The big differences fell into two general categories: either they were some extra AI spice, or they were focused on identity management. We had Claude hooked up to Slack and hadn’t yet adopted an IdP, so the former felt redundant and the latter felt unnecessary. Bottom line: we were five people with tight governance and a Slack workspace that genuinely hummed. We just didn't need what Business+ was selling.
For context: BrightHelm isn't a new company so much as a reinvention. We were Navigators before we became BrightHelm Partners, and when we made that transition, I went through a full Slack migration totally manually. Every channel, every integration, every setting — eyes on it. What surprised me was how little I had to change. The channel model we'd built as Navigators survived the migration almost entirely intact. That was validation we'd gotten the architecture right.
A hot new bombshell enters the villa!
When Slackbot launched in January, I wanted it immediately. Not because I'd fully thought through what it would do — I hadn't. I just knew intuitively that an AI assistant that lived inside the tool where my team already talked, and that could read the context of our actual business conversations, was qualitatively different from what we'd been using. We had Claude. We used Claude. But adoption was uneven, and Claude requires genuine skill to use well and responsibly. Slackbot seemed different.
We have five users and some guests. It felt so extravagant. But I gritted my teeth and upgraded to Business+.
Seventeen minutes later, I had already consumed my entire week's allowance of Slackbot messages. I wish I were exaggerating.
The 15-Message Problem
If you don’t know already, Business+ gates you to 15 messages to Slackbot a week. That’s it.
Look… 15 messages a week is a genuinely dumb limit. It's not enough to automate anything. It's not enough to conversationally build a skill. It's not enough for Slackbot to begin to understand your voice and adjust. It's just not enough to do anything real with.
Yes, this was in the documentation, but it’s not exactly featured prominently, and it’s nowhere in any of the materials you view when you’re upgrading. Real talk time: it felt like a bait and switch. I was furious.
But here again, we’ve all seen this story before. When Salesforce expands through acquisition, the new thing tends to enter the ecosystem at a ridiculously high price point, and diffuse from there. This also often happens with critical new features, but not always. The question here was if this limit was a true hard technical limit or an administrative one. In Salesforce there are hard technical limits and there are administrative ones – 150 DML statements per Apex transactions? Hard limit. You aren’t bypassing that. Number of Customer Community users logging in this month? Administrative limit. You’ll get away with it for a month or so, but eventually you’ll get an email from your Account Executive.
I spent the next several months of Salesforce events badgering every Slack employee, solution architect, sales person, and product person I could find, trying to understand one thing: is this a technical limit or an administrative one?
Nobody could tell me. At every kiosk, I watched Slack people ask Slackbot — and Slackbot didn't know either.
I eventually stood up at a True to the Core session at TDX and said my piece. It seemed to resonate — Parker Harris was on the panel and admitted that Salesforce had probably missed the mark on this one. The rest of the panel appeared genuinely surprised that this was even a limitation. Which tells you something. (It tells you that a limit of 15 messages is dumb. That’s what it tells you.)
I still don't know if the limit is technical or administrative. But I do know it's the wrong call, and I think the people closest to the product are starting to feel that too.
Why Enterprise? Honestly, Just Slackbot.
After pressing for months, I finally bit the bullet and upgraded to Enterprise.
I want to be honest about why: it wasn't for the enterprise features. It wasn't for the multi-workspace architecture or the admin console or the org-level controls. It was because Enterprise Grid came with unlimited Slackbot, and I was done rationing conversations.
That's it. That was the whole pitch.
What I want to flag, though — and I feel this genuinely — is that Enterprise Grid is a qualitatively different product than anything below it. It's not just bigger, better, faster. It's a dedicated instance (as opposed to shared tenancy) designed for a fundamentally different kind of organization than mine. I'm five people. Enterprise Grid is built for enterprises with IT departments and compliance teams and thousands of users. There's a real mismatch there, and I think it's worth naming.
I'll also be transparent: I'm fuzzy on exactly where the line is between Enterprise Grid and Enterprise+. My understanding is that the difference is mostly Slackbot access — but I've been unable to nail down a definitive answer, and I'm not sure you can even purchase them separately anymore. The fact that this is so hard to clarify is itself content. If you know the answer, I'd genuinely love to hear it.
What We Actually Got (Beyond Slackbot)
Before I gush about Slackbot (that’s the second post in this series, hang tight), it’s worth checking in on the fundamental difference between an Enterprise instance of Slack, and all other instances. Here's what surprised me: the features I didn't migrate for turned out to be not entirely un-useful.
The multi-workspace capability sounds like overhead for a five-person team. It's not. The ability to separate workspaces by context — client work in one place, internal operations in another — does something meaningful to the signal-to-noise ratio. Notifications get saner. Context stops bleeding across conversations. The org-level view gives you a cleaner picture of what's actually happening.
The second was being forced to set up SSO. If you don’t know already, Slack Enterprise requires SSO – it’s not optional. We used Google, but genuinely this got me started thinking about the benefits of managing all our systems and tools through a single IdP. That’s a sweater to unravel on another day, so let’s not pull on that yarn right now. It’s enough to say that it was a good experience and I’m glad I was forced to go through the setup.
Why a 5-Person Team Has So Many Channels
Meet me at Camera Three. I have to address something.
Here's the thing about BrightHelm that surprises people: we're five people, and we have a lot of channels. Like… I’m kinda afraid to tell you how many channels. You will TOTALLY judge me. Let’s just say it’s more than most teams our size would think to create, let alone maintain.
This is intentional, and it's worth explaining because I think people misread it as a quirk or an obsession. It's neither. Channels are how we organize context — by client, by project, by workstream, by product, by ad hoc team, by type of conversation. Keeping them separated means discussions don't bleed together, there's always a clear home for any given topic, and when you need to find something later, you can.
But here's the more important reason, and it's one we only came to fully appreciate after Enterprise Grid: your channel model is Slackbot's map of your business. When you have clean, well-named channels with clear purposes, Slackbot can navigate your workspace intelligently. It understands what's a client conversation versus an internal one, what's a project thread versus a billing question. When your channels are a mess, Slackbot gets confused — because your workspace is a mess.
Think of channel governance not as a chore but as an ordering principle. It's the organizational logic that makes your workspace make sense — to you, to your team, and to Slackbot. Get it right and you're building on solid ground. Get it wrong and you'll feel it. This is intentional. Keeping things separated and hierarchically organized – and then cleaving to that model mercilessly – means Slackbot can find its way around, utterly unbothered by the number of channels.
It's a practice that looked a little obsessive before Enterprise Grid. After Enterprise Grid, with Slackbot surfacing the right channel at the right time? It looks like foresight.
I just had to get that out of the way. Back to Camera One.
The Migration Itself
We migrated last week. I'd done this once before — manually, when Navigators became BrightHelm — so I knew what I was walking into. This time was easier.
Slack's migration path from Business+ to Enterprise Grid is well-documented and, for a team our size, manageable. Your messages and files come with you; guests also move automatically. You can opt to enforce SSO for your guests or leave them as-is. Your integrations need attention — give yourself time for that part specifically. Your app authorizations need to be reviewed and in some cases re-done. Go in with eyes open on that.
The bigger adjustment isn't technical. It's conceptual: understanding the org-workspace hierarchy and deciding, with intention, what lives where. If you do that thinking before you migrate, the rest follows. If you try to figure it out after, you'll be retrofitting, and that's no fun.
My practical advice:
Audit your apps and integrations before you start, not after.
Have a workspace structure in mind before day one. If it’s a single workspace, then great. But give it some intentional thought at least.
Don't wait until you have 500 users to think about channel governance. Do it with five people. Do it now.
Step 1: SSO
Once you’re ready to set up your new instance, you will be prompted first to configure SSO. This is straightforward and well documented, and you have a lot of choices. We opted to use Google as our IdP, but you can also use Okta, LastPass, MS Entra, and a number of others.
Step 2: Actual Migration
Here’s the good news: It was not painful. It’s totally automated – you schedule a time window, and wait. . Your existing channels, messages, and files come with you. We went for a Friday at 0200; when I logged on that morning, everything was there.
What Happened Next
Finally, coffee at my elbow, I typed “Cmd-K S-l-a-c-k-b-o-t.”
Things got interesting very fast. I'll tell you about that in Part 2.
Part 2: What actually happened when we let Slackbot loose — and why we burned through half our automation backlog in a week.
This is Part 1 of BrightHelm's series on our move to Slack Enterprise Grid. Small team, lots of channels, one very specific reason — and a handful of surprises along the way.
