Slack is connected per project, and each connected channel is set up separately. That matters more than it sounds: Slack has no per-person permissions we can see. Everyone in the channel receives everything sent there, and can run anything you enable — including people invited months after you set it up, and including your client if it is a shared channel.
So the question is never "can this person do this". It is "can anyone who is, or ever will be, in this room".
Who this is for
Agencies who live in Slack and would rather type there than open another tab. If your team already runs client work in per-client channels, this fits that shape: one channel, one project.
The three things you can turn on
Each is separate, because they go wrong in different ways.
Notifications
Alerts posted into the channel — content changes and task updates today.
What it exposes: everyone in the channel sees them. In a shared client channel, that means the client learns about a problem at the same moment you do, before you have read it or decided what it means. Fine for a "post published" note. Less fine for a ranking drop.
Leave off for client-facing channels unless you are comfortable with unreviewed news reaching them.
Actions
Running work from Slack: /xavier audit starts a real site crawl.
What it exposes: anyone in the channel can spend your credits. A crawl is billed work, and Slack does not tell us who is allowed to start one — only who typed it.
Leave off for any channel a client or contractor is in.
Asking Xavier
Free-form questions to the agent from inside Slack.
Off by default, and the only one that starts that way. The other two do a fixed thing; this one answers whatever is asked, and spends credits doing it. A stray question in a busy channel is a real charge.
What it can and cannot do. It answers from data already stored — rankings, the last audit, Search Console, AI visibility. It cannot run, publish, or change anything, and it will say so if asked to. Starting work stays behind /xavier audit, which has its own switch, because a message written by whoever is in the channel is a question to answer and never an instruction to follow.
Setting a channel up
- Connect Slack from the project's integrations page
- In the channel, run
/xavier use project Acmeto map it - Choose which of the three to enable for that channel
Commands for finding and mapping projects — /xavier projects, /xavier use project — always work. Otherwise a channel with everything switched off would have no way to fix its own configuration from Slack.
Commands
| Command | What it does |
|---|---|
/xavier help | Lists what is available |
/xavier projects | Your projects |
/xavier use project Acme | Maps this channel to a project |
/xavier create project Acme domain acme.com | Creates and maps in one step |
/xavier audit | Site audit for this channel's project — spends credits |
/xavier audit acme.com 500 pages | A specific target and crawl size |
@Xavier how did rankings move? | Answers from stored data — spends credits |
Slack does not autocomplete these. Typing /xavier shows the usage hint from the app, and /xavier help lists everything.
A rule worth adopting
One channel per client, and decide before you invite them. Changing the setting later does not unsend anything, and a client who has seen the alerts will ask why they stopped.
Internal channels are where actions belong. Client channels are where a curated client portal belongs — it shows exactly what you chose, and nothing arrives there unreviewed.
Turning it off
Switch any capability off on the project's integrations page and it stops immediately. Removing the channel mapping stops everything for that channel at once.
Next
- Sharing a client portal
- Credit budgets
- People and access