Stack de suporte B2B no Slack — o workspace do cliente é a interface, nunca o registro

Suporte em canais compartilhados ganha por um motivo: o cliente nunca sai do lugar onde já trabalha. E falha pelo mesmo motivo. Uma mensagem de Slack não tem fila, não tem dono, não tem relógio e — se o workspace do cliente está no plano gratuito do Slack — não tem memória além de 90 dias de histórico de mensagens. A thread onde você prometeu a correção expira antes da conversa de renovação em que isso importa.

Este stack é construído sobre uma regra só: o Slack é a interface, e nada além disso. O registro, o relógio, o rastro de engenharia e o conhecimento ficam em um lugar que você controla. Cada componente abaixo existe para tirar um desses quatro de dentro do canal.

Duas travas para checar antes de precificar qualquer coisa. O Slack Connect exige que cada organização participante esteja em um plano pago — o plano do seu cliente é problema dele até virar seu, e no Enterprise+ parceiros em plano gratuito entram sem precisar fazer upgrade. Um único canal de Slack Connect comporta até 250 organizações, muito além de qualquer conta que você vá operar assim.

O formato

• Slack é a superfície que seu cliente já tem aberta. Nada neste stack pede que ele entre em um portal, e esse é o argumento comercial inteiro. Da Europa, slack.com/pricing cota em EUR: Pro a €6,75 por usuário/mês no anual (€8,25 no mensal), Business+ a €15 no anual (€18 no mensal). Você paga por assento interno, não importa quantos convidados externos estejam nos canais.
• Pylon é o registro e o relógio. Ele observa os canais de cliente conectados — públicos, privados e canais de Slack Connect iniciados pelo seu cliente —, agrupa as mensagens relacionadas e abre um issue rastreado sem ninguém digitar comando nenhum. Os Internal Threads dão a quem não tem assento no Pylon um lugar para trabalhar aquele issue dentro do Slack, sincronizado nas duas direções. São três SLAs de issue (primeira resposta, próxima resposta, resolução) mais Team SLAs, que começam quando o issue é atribuído àquele time e não na criação — assim um solutions engineer que segura a thread por uma semana não queima o número do suporte. O Support Hours impede que noites e fins de semana inflem as violações, e cada violação dispara uma notificação de Slack no canal que você escolher.
• Linear fica com a metade do ticket que o suporte não consegue fechar. Pelo módulo lateral do Pylon ou pelo botão Create Ticket 📦 no canal de triagem, um issue de cliente vira um issue no Linear com título redigido por IA. Comentários do Linear voltam como notas internas no Pylon e respostas do Pylon seguem como comentários no Linear. O Pylon embute um módulo no issue do Linear para que engenharia leia qual conta está travada sem abrir uma ferramenta de suporte. Ligue a configuração de Customer Requests: o pedido gruda em um registro de cliente no Linear com revenue, tier, tamanho e status, que é como “três contas enterprise querem isso” vira um número na reunião de priorização em vez de anedota.
• Notion é o runbook interno, não a KB voltada ao cliente. A knowledge base do próprio Pylon e os issues passados são reindexados ao vivo; conteúdo externo adicionado como Training Data é uma URL pública ou uma URL base rastreada, reindexada a cada 7 ou 30 dias conforme o plano, e o Notion não aparece como fonte documentada. Os dois fatos apontam para o mesmo lado. Uma página privada do Notion nunca chega ao agente, e um Notion Site publicado para crawling responde com a política de reembolso que você mudou três semanas atrás. As respostas voltadas ao cliente ficam na KB do Pylon; o Notion guarda os runbooks internos, as árvores de escalonamento e o contexto de conta que seu time lê e seus clientes não.
• O agente de IA é uma bifurcação, não um default. O Support Agent, o Slack Agent e os Connectors do Pylon estão marcados como beta, com acesso limitado a quem participa da beta na documentação do próprio Pylon. Planeje uma de duas rotas: entrar na beta, ou trazer o seu. A rota de trazer o seu é documentada — webhooks para eventos de issue e mensagem, a API REST para respostas e escrita de campos, e um servidor MCP hospedado em mcp.usepylon.com (OAuth 2.0 via AuthKit, condicionado a um papel MCP Access para usuários Member ou Admin) que expõe search_issues, get_issue, get_issue_messages, create_issue, update_issue, search_accounts, get_account, update_account, get_contact, get_user e get_me, com rate limits por ferramenta e por organização que devolvem 429. Aponte o Claude para essa superfície para redigir a resposta e juntar contexto; quem publica no canal do cliente continua sendo uma pessoa.

Handoffs nomeados

1. O cliente escreve no canal compartilhado → o Pylon abre um issue rastreado → o relógio do SLA começa. Sem comando /ticket, sem portal, sem pedir mudança de comportamento ao cliente.
2. O issue é roteado para um time → o Team SLA começa ali. O SLA geral continua correndo desde a criação, então você enxerga a experiência do cliente e a performance do time como dois números separados.
3. O suporte não resolve → Create Ticket 📦 → um issue no Linear mais um Customer Request no registro da conta. O engenheiro recebe o contexto da conta embutido; o product manager recebe uma lista de pedidos ponderada por revenue.
4. O issue do Linear é concluído → o issue do Pylon é notificado e vai para “On You”. Alguém volta ao canal e conta ao cliente que o bug dele subiu. Esse é o passo que morre em toda versão caseira de Slack mais Jira, e é o que os clientes lembram.
5. Um issue fecha sem artigo por trás → marque como precisando de um → ele cai na fila de Gaps → o Copilot redige → publicar na KB do Pylon reindexa ao vivo. O Pylon ainda autogera tópicos para perguntas recorrentes que sua documentação conectada não cobre, e esse é o backlog que de fato se trabalha.
6. Um champion sai do canal → o Pylon avisa no canal de triagem daquela conta e informa se a pessoa ainda está na empresa. A alternativa é descobrir durante uma call de renovação.

Base de custo

Um time de suporte e CS de 8 assentos cobrindo cerca de 60 canais de cliente:

• Slack: Business+ a €15 por usuário/mês no anual. Para 8 assentos de suporte são uns €1.440/ano, embora na prática o Slack já seja uma linha da empresa inteira.
• Pylon: preço sob cotação. usepylon.com/pricing redireciona para agendar demo, então trate cada valor como âncora de negociação e não como cotação. Último preço publicado: Starter $59, Professional $89, Enterprise $139 por assento/mês no anual, com mínimo de 3 assentos (7 no Enterprise). AI Assistants somava $50/assento/mês, AI Agents partia de $100/mês e escalava com o volume de issues de 30 dias, e Account Intelligence rodava a $10 por conta de cliente/mês com mínimo de 50 contas. Oito assentos Professional ancoram perto de $8.500/ano; com Assistants fica mais perto de $13.300; 60 contas de Account Intelligence acrescentam cerca de $7.200 em cima.
• Linear: o Free cobre 2 times e 250 issues, o que uma engenharia real supera em um trimestre. Basic custa $10 por usuário/mês no anual; Business custa $16 e é o tier que traz Linear Asks, times privados com convidados, e os conectores de Zendesk e Intercom. Customer Requests existe em todos os planos, inclusive no Free, mas no Free só dá para criar manualmente ou a partir do Slack.
• Notion: Free, Plus a €9,50 ou Business a €19,50 por membro/mês. Se você publicar parte do workspace como Notion Site no seu domínio, são $8 por mês por domínio no anual.

O total para oito assentos de suporte aterrissa entre $16K e $26K por ano, e o Pylon é 60-80% disso. A pergunta de orçamento que carrega o peso não é quais ferramentas — é quais add-ons do Pylon você liga de verdade.

Variações e quando trocar

• Jira em vez de Linear quando engenharia já roda Jira e não vai sair de lá. Você mantém os handoffs 3 e 4 pela integração de ticketing do Pylon, e perde o registro de cliente do Linear, então a lista de pedidos ponderada por revenue precisa ser remontada em campos do Jira ou numa planilha. Não migre engenharia para ganhar uma função de suporte.
• Microsoft Teams em vez de Slack Connect quando seus clientes são casas Microsoft. O Pylon trata Teams como canal de primeira classe e o resto do stack não muda. A troca é decidida por onde seus clientes vivem, não por preferência.
• Fin (Intercom) como camada de resolução quando você quer um agente medido hoje em vez de esperar um assento de beta no Pylon. O Fin cobra por outcome e traz o próprio modelo de fontes de conhecimento; o argumento completo sobre auditar esse medidor está no stack de agente de suporte com IA, que é a página certa se sua pergunta real é a economia da deflexão.
• Tire o Notion se seus runbooks já vivem na KB do Pylon como coleções internas. Uma segunda casa de conhecimento se justifica só quando times fora do suporte escrevem nela.

O que este stack não substitui

Não é uma plataforma de CS. Health scores, forecast de renovação e automação de playbooks são compra separada — veja o stack de retenção em CS. Não é comunicação de incidente: um canal de Slack Connect é o lugar errado para anunciar uma queda para 60 contas, e você continua precisando de status page. Não é programa de QA — avaliar as conversas que esses canais produzem é garantia de qualidade em suporte. E não é analytics de produto; nada aqui diz se o cliente que ficou quieto ainda usa a funcionalidade.

Regras de encaixe

É a escolha certa quando o suporte é B2B e por conta nomeada, mais da metade do inbound chega em canais compartilhados de Slack ou Teams, você opera entre 20 e 300 canais de cliente, e engenharia já está no Linear. A economia fecha porque você paga por assento de suporte, não por contato.

É a escolha errada em três casos. Volume anônimo ou de consumo por widget web — um modelo centrado em contas precifica mal contra tráfego sem conta. Menos de uns 10 canais de cliente, onde Slack mais o plano gratuito do Linear mais um alias de email compartilhado não custa nada e não perde nada. E SLAs contratuais auditados pelo jurídico do seu cliente: confirme que as definições e o relatório de SLA do Pylon batem com as palavras do seu MSA antes de cancelar o helpdesk atual, porque “primeira resposta” num contrato e “primeira resposta” numa ferramenta de suporte nem sempre são o mesmo evento.