B2B Slack support stack — the customer's workspace is the interface, never the record

Shared-channel support wins for one reason: the customer never leaves the place they already work. It fails for the same reason. A Slack message has no queue, no owner, no clock, and — if the customer’s workspace is on Slack’s free plan — no memory past 90 days of message history. The thread where you promised a fix expires before the renewal conversation where it matters.

This stack is built on one rule: Slack is the interface, and nothing else. The record, the clock, the engineering trail, and the knowledge all live somewhere you control. Every component below exists to move one of those four out of the channel.

Two gates to check before pricing anything. Slack Connect requires each participating organization to be on a paid plan — your customer’s plan is their problem until it is yours, and on Enterprise+ free-plan partners can join without upgrading. A single Slack Connect channel holds up to 250 organizations, which is far past any account you will run this way.

The shape

• Slack is the surface your customer already has open. Nothing in this stack asks them to log into a portal, and that is the entire commercial argument for it. From Europe slack.com/pricing serves EUR: Pro at €6.75 per user/month paid annually (€8.25 monthly), Business+ at €15 annually (€18 monthly). You pay per internal seat regardless of how many external guests sit in the channels.
• Pylon is the record and the clock. It watches connected customer channels — public, private, and Slack Connect channels initiated by your customer — bundles the related messages, and opens a tracked issue without anyone typing a command. Internal Threads give teammates who hold no Pylon seat a place to work that issue inside Slack, synced both directions. It carries three issue SLAs (first response, next response, resolution) plus Team SLAs, which start when the issue is assigned to that team rather than at creation — so a solutions engineer sitting on a thread for a week does not burn support’s number. Support Hours stops evenings and weekends from inflating breach counts, and a breach fires a Slack notification into a channel you pick.
• Linear owns the half of the ticket that support cannot close. From the Pylon sidebar module or the Create Ticket 📦 button in the triage channel, a customer issue becomes a Linear issue with an AI-drafted title. Linear comments sync back as Pylon internal notes and Pylon replies sync forward as Linear comments. Pylon embeds a module on the Linear issue so an engineer reads which account is blocked without opening a support tool. Turn on the Customer Requests configuration: the request attaches to a Linear customer record carrying revenue, tier, size, and status, which is how “three enterprise accounts want this” becomes a number in the prioritization meeting instead of an anecdote.
• Notion is the internal runbook, not the customer-facing KB. Pylon’s own knowledge base and past issues reindex live; external content added as Training Data is a public URL or crawled base URL, reindexed every 7 or 30 days depending on plan, and Notion is not a documented source. Both facts point the same way. A private Notion page never reaches the agent at all, and a Notion Site published for crawling can answer with a refund policy you changed three weeks ago. Customer-facing answers belong in Pylon’s KB; Notion holds the internal runbooks, escalation trees, and account context your team reads and your customers do not.
• The AI agent is a fork, not a default. Pylon’s Support Agent, Slack Agent, and Connectors are each marked beta, with access limited to beta participants in Pylon’s own documentation. Plan for one of two routes: get into the beta, or bring your own. The bring-your-own path is documented — webhooks for issue and message events, the REST API for replies and field writes, and a hosted MCP server at mcp.usepylon.com (OAuth 2.0 via AuthKit, gated on an MCP Access role for Member or Admin users) exposing search_issues, get_issue, get_issue_messages, create_issue, update_issue, search_accounts, get_account, update_account, get_contact, get_user, and get_me, with per-tool per-organization rate limits that return 429. Point Claude at that surface to draft the reply and gather context; a human still posts into the customer’s channel.

Named handoffs

1. Customer posts in the shared channel → Pylon opens a tracked issue → the SLA clock starts. No /ticket command, no portal, no behavior change asked of the customer.
2. Issue routed to a team → the Team SLA starts there. The overall SLA still runs from creation, so you can see the customer’s experience and the team’s performance as two separate numbers.
3. Support cannot fix it → Create Ticket 📦 → a Linear issue plus a Customer Request on the account record. The engineer gets the account context embedded; the product manager gets a revenue-weighted request list.
4. Linear issue completed → the Pylon issue is notified and moves to “On You.” Somebody goes back to the channel and tells the customer their bug shipped. This is the step that dies in every homegrown Slack-plus-Jira version, and it is the one customers remember.
5. Issue closed with no article behind it → mark it as needing one → it lands in the Gaps queue → Copilot drafts it → publishing to the Pylon KB reindexes live. Pylon also autogenerates topics for recurring questions your connected documentation does not cover, which is the backlog you actually work.
6. A champion leaves the channel → Pylon posts to that account’s triage channel and reports whether they are still at the company. The alternative is discovering it during a renewal call.

Cost baseline

An 8-seat support and CS team covering roughly 60 customer channels:

• Slack: Business+ at €15 per user/month annually. For 8 support seats that is about €1,440/year, though in practice Slack is a company-wide line you already pay.
• Pylon: quote-gated. usepylon.com/pricing redirects to demo booking, so treat every figure as a negotiating anchor rather than a quote. Last published: Starter $59, Professional $89, Enterprise $139 per seat/month billed annually, with a 3-seat minimum (7 on Enterprise). AI Assistants added $50/seat/month, AI Agents started at $100/month and scaled with 30-day issue volume, and Account Intelligence ran $10 per customer account/month on a 50-account minimum. Eight Professional seats anchor near $8,500/year; add Assistants and it is closer to $13,300; 60 accounts of Account Intelligence adds roughly $7,200 on top.
• Linear: Free covers 2 teams and 250 issues, which a real engineering org clears in a quarter. Basic is $10 per user/month billed yearly; Business is $16 and is the tier that carries Linear Asks, private teams and guests, and the Zendesk and Intercom connectors. Customer Requests exists on every plan, including Free, but on Free you can only create them manually or from Slack.
• Notion: Free, Plus at €9.50, or Business at €19.50 per member/month. If you publish part of the workspace as a Notion Site on your own domain, that is $8 per month per domain paid annually.

All-in for eight support seats lands roughly $16K–$26K a year, and Pylon is 60–80% of it. The load-bearing budget question is not which tools — it is which Pylon add-ons you actually switch on.

Variations and when to swap

• Jira instead of Linear when engineering already runs Jira and will not move. You keep handoffs 3 and 4 through Pylon’s ticketing integration, and you give up the Linear customer record, so the revenue-weighted request list has to be rebuilt in Jira fields or a spreadsheet. Do not migrate engineering to win a support feature.
• Microsoft Teams instead of Slack Connect when your customers are Microsoft shops. Pylon treats Teams as a first-class channel, and the rest of the stack is unchanged. The swap is decided by where your customers live, not by preference.
• Fin (Intercom) as the resolution layer when you want a metered agent today rather than a Pylon beta seat. Fin bills per outcome and brings its own knowledge-source model; the full argument on auditing that meter is in the AI support agent stack, which is the right page if deflection economics are your actual question.
• Drop Notion if your runbooks already live in the Pylon KB as internal collections. A second knowledge home earns its keep only when non-support teams write in it.

What this stack does not replace

It is not a CS platform. Health scores, renewal forecasting, and playbook automation are a separate buy — see the CS retention stack. It is not incident communication: a Slack Connect channel is the wrong place to announce an outage to 60 accounts, and a status page is still required. It is not a QA program — grading the conversations these channels produce is support quality assurance. And it is not product analytics; nothing here tells you whether the customer who went quiet is still using the feature.

Match rules

Right pick when support is B2B and named-account, more than half of inbound arrives in shared Slack or Teams channels, you run somewhere between 20 and 300 customer channels, and engineering is already in Linear. The economics work because you are paying per support seat, not per contact.

Wrong pick in three cases. Anonymous or consumer volume through a web widget — an account-centric model prices badly against traffic with no account. Fewer than about 10 customer channels, where Slack plus Linear’s free tier plus a shared email alias costs nothing and loses nothing. And contractual SLAs that a customer’s legal team audits: confirm Pylon’s SLA definitions and reporting match the words in your MSA before you cancel the incumbent helpdesk, because “first response” in a contract and “first response” in a support tool are not always the same event.