Stack de soporte B2B en Slack — el workspace del cliente es la interfaz, nunca el registro

El soporte en canales compartidos gana por una razón: el cliente nunca sale del lugar donde ya trabaja. Y falla por esa misma razón. Un mensaje de Slack no tiene fila, no tiene responsable, no tiene reloj y — si el workspace del cliente está en el plan gratuito de Slack — no tiene memoria más allá de 90 días de historial de mensajes. El hilo donde prometiste un arreglo expira antes de la conversación de renovación donde eso importa.

Este stack se construye sobre una sola regla: Slack es la interfaz, y nada más. El registro, el reloj, el rastro de ingeniería y el conocimiento viven en un lugar que tú controlas. Cada componente de abajo existe para sacar uno de esos cuatro fuera del canal.

Hay dos condiciones que revisar antes de calcular cualquier precio. Slack Connect exige que cada organización participante esté en un plan de pago — el plan de tu cliente es problema suyo hasta que se vuelve tuyo, y en Enterprise+ los partners en plan gratuito pueden entrar sin actualizar. Un solo canal de Slack Connect admite hasta 250 organizaciones, muy por encima de cualquier cuenta que vayas a operar así.

La forma

• Slack es la superficie que tu cliente ya tiene abierta. Nada en este stack le pide entrar a un portal, y ese es todo el argumento comercial. Desde Europa, slack.com/pricing cotiza en EUR: Pro a €6,75 por usuario/mes con pago anual (€8,25 mensual), Business+ a €15 anual (€18 mensual). Pagas por asiento interno sin importar cuántos invitados externos estén en los canales.
• Pylon es el registro y el reloj. Observa los canales de cliente conectados — públicos, privados y canales de Slack Connect iniciados por tu cliente —, agrupa los mensajes relacionados y abre un issue rastreado sin que nadie escriba un comando. Los Internal Threads le dan a quienes no tienen asiento en Pylon un lugar para trabajar ese issue dentro de Slack, sincronizado en ambas direcciones. Trae tres SLA de issue (primera respuesta, siguiente respuesta, resolución) más Team SLAs, que arrancan cuando el issue se asigna a ese equipo y no cuando se creó — así un solutions engineer que retiene un hilo una semana no quema el número de soporte. Support Hours evita que noches y fines de semana inflen los incumplimientos, y cada incumplimiento dispara una notificación de Slack al canal que elijas.
• Linear se queda con la mitad del ticket que soporte no puede cerrar. Desde el módulo lateral de Pylon o el botón Create Ticket 📦 en el canal de triage, un issue de cliente se convierte en un issue de Linear con título redactado por IA. Los comentarios de Linear vuelven como notas internas en Pylon y las respuestas de Pylon avanzan como comentarios en Linear. Pylon incrusta un módulo en el issue de Linear para que ingeniería lea qué cuenta está bloqueada sin abrir una herramienta de soporte. Activa la configuración de Customer Requests: la solicitud queda pegada a un registro de cliente en Linear con revenue, tier, tamaño y estado, que es como “tres cuentas enterprise quieren esto” se vuelve un número en la reunión de priorización en lugar de una anécdota.
• Notion es el runbook interno, no la KB de cara al cliente. La knowledge base propia de Pylon y sus issues pasados se reindexan en vivo; el contenido externo agregado como Training Data es una URL pública o una URL base rastreada, reindexada cada 7 o 30 días según el plan, y Notion no figura como fuente documentada. Ambos hechos apuntan al mismo lado. Una página privada de Notion nunca llega al agente, y un Notion Site publicado para rastreo puede responder con una política de reembolsos que cambiaste hace tres semanas. Las respuestas de cara al cliente van en la KB de Pylon; Notion guarda los runbooks internos, los árboles de escalamiento y el contexto de cuenta que lee tu equipo y no tus clientes.
• El agente de IA es una bifurcación, no un default. El Support Agent, el Slack Agent y los Connectors de Pylon están marcados como beta, con acceso limitado a quienes participan en la beta en la documentación del propio Pylon. Planifica una de dos rutas: entrar a la beta, o traer el tuyo. La ruta de traer el tuyo está documentada — webhooks para eventos de issues y mensajes, la API REST para respuestas y escritura de campos, y un servidor MCP alojado en mcp.usepylon.com (OAuth 2.0 vía AuthKit, condicionado a un rol MCP Access para usuarios Member o Admin) que expone search_issues, get_issue, get_issue_messages, create_issue, update_issue, search_accounts, get_account, update_account, get_contact, get_user y get_me, con límites de tasa por herramienta y por organización que devuelven 429. Apunta Claude a esa superficie para redactar la respuesta y juntar contexto; el que publica en el canal del cliente sigue siendo una persona.

Handoffs con nombre

1. El cliente escribe en el canal compartido → Pylon abre un issue rastreado → arranca el reloj del SLA. Sin comando /ticket, sin portal, sin pedirle al cliente que cambie de conducta.
2. El issue se enruta a un equipo → ahí arranca el Team SLA. El SLA general sigue corriendo desde la creación, así ves la experiencia del cliente y el desempeño del equipo como dos números distintos.
3. Soporte no puede resolverlo → Create Ticket 📦 → un issue de Linear más un Customer Request en el registro de la cuenta. El ingeniero recibe el contexto de cuenta incrustado; el product manager recibe una lista de solicitudes ponderada por revenue.
4. El issue de Linear se completa → el issue de Pylon recibe aviso y pasa a “On You”. Alguien vuelve al canal y le cuenta al cliente que su bug ya salió. Este es el paso que muere en toda versión casera de Slack más Jira, y es el que los clientes recuerdan.
5. Se cierra un issue sin artículo detrás → márcalo como que necesita uno → cae en la cola de Gaps → Copilot lo redacta → publicarlo en la KB de Pylon lo reindexa en vivo. Pylon además autogenera temas para preguntas recurrentes que tu documentación conectada no cubre, y ese es el backlog que de verdad se trabaja.
6. Un champion sale del canal → Pylon avisa en el canal de triage de esa cuenta e informa si esa persona sigue en la empresa. La alternativa es enterarte durante una llamada de renovación.

Base de costos

Un equipo de soporte y CS de 8 asientos que cubre unos 60 canales de cliente:

• Slack: Business+ a €15 por usuario/mes anual. Para 8 asientos de soporte son unos €1.440/año, aunque en la práctica Slack ya es una línea de toda la empresa.
• Pylon: con precio bajo cotización. usepylon.com/pricing redirige a agendar demo, así que trata cada cifra como ancla de negociación y no como cotización. Último precio publicado: Starter $59, Professional $89, Enterprise $139 por asiento/mes con pago anual, con mínimo de 3 asientos (7 en Enterprise). AI Assistants sumaba $50/asiento/mes, AI Agents arrancaba en $100/mes y escalaba con el volumen de issues de 30 días, y Account Intelligence corría a $10 por cuenta de cliente/mes con mínimo de 50 cuentas. Ocho asientos Professional anclan cerca de $8.500/año; con Assistants queda más cerca de $13.300; 60 cuentas de Account Intelligence agregan unos $7.200 encima.
• Linear: el plan Free cubre 2 equipos y 250 issues, que una organización de ingeniería real supera en un trimestre. Basic cuesta $10 por usuario/mes con pago anual; Business cuesta $16 y es el tier que trae Linear Asks, equipos privados con invitados, y los conectores de Zendesk e Intercom. Customer Requests existe en todos los planes, incluido Free, pero en Free solo puedes crearlos manualmente o desde Slack.
• Notion: Free, Plus a €9,50 o Business a €19,50 por miembro/mes. Si publicas parte del workspace como Notion Site en tu propio dominio, son $8 por mes por dominio con pago anual.

El total para ocho asientos de soporte aterriza aproximadamente entre $16K y $26K al año, y Pylon es el 60-80% de eso. La pregunta de presupuesto que carga el peso no es qué herramientas — es qué add-ons de Pylon enciendes de verdad.

Variantes y cuándo cambiar

• Jira en lugar de Linear cuando ingeniería ya corre Jira y no se va a mover. Conservas los handoffs 3 y 4 vía la integración de ticketing de Pylon, y pierdes el registro de cliente de Linear, así que la lista de solicitudes ponderada por revenue hay que rearmarla en campos de Jira o en una hoja de cálculo. No migres a ingeniería para ganar una función de soporte.
• Microsoft Teams en lugar de Slack Connect cuando tus clientes son casas Microsoft. Pylon trata a Teams como canal de primera clase y el resto del stack no cambia. El cambio lo decide dónde viven tus clientes, no tu preferencia.
• Fin (Intercom) como capa de resolución cuando quieres un agente medido hoy en vez de esperar un asiento de beta en Pylon. Fin cobra por outcome y trae su propio modelo de fuentes de conocimiento; el argumento completo sobre auditar ese medidor está en el stack de agente de soporte con IA, que es la página correcta si tu pregunta real es la economía de la deflexión.
• Saca Notion si tus runbooks ya viven en la KB de Pylon como colecciones internas. Un segundo hogar de conocimiento se justifica solo cuando equipos fuera de soporte escriben en él.

Lo que este stack no reemplaza

No es una plataforma de CS. Health scores, forecast de renovación y automatización de playbooks son una compra aparte — mira el stack de retención en CS. No es comunicación de incidentes: un canal de Slack Connect es el lugar equivocado para anunciar una caída a 60 cuentas, y sigues necesitando una status page. No es un programa de QA — calificar las conversaciones que producen estos canales es aseguramiento de calidad en soporte. Y no es analítica de producto; nada de esto te dice si el cliente que se quedó callado sigue usando la funcionalidad.

Reglas de encaje

Es la elección correcta cuando el soporte es B2B y por cuenta nombrada, más de la mitad del inbound llega en canales compartidos de Slack o Teams, operas entre 20 y 300 canales de cliente, e ingeniería ya está en Linear. La economía funciona porque pagas por asiento de soporte, no por contacto.

Es la elección equivocada en tres casos. Volumen anónimo o de consumo por un widget web — un modelo centrado en cuentas cotiza mal contra tráfico sin cuenta. Menos de unos 10 canales de cliente, donde Slack más el plan gratuito de Linear más un alias de correo compartido no cuesta nada y no pierde nada. Y SLA contractuales que audita el equipo legal de tu cliente: confirma que las definiciones y el reporte de SLA de Pylon coinciden con las palabras de tu MSA antes de cancelar el helpdesk que ya tienes, porque “primera respuesta” en un contrato y “primera respuesta” en una herramienta de soporte no siempre son el mismo evento.