Customer Support

Cómo crear un glosario de términos y jerga de soporte para nuevos agentes

5 de octubre de 2026 · Equipo Talento Bilingüe · 15 min de lectura

Son las 8:14 a. m. en tu habitación. La laptop ya está abierta, el café a medio enfriar y el canal de Slack del equipo de soporte de la empresa de Estados Unidos no para de parpadear. Llevas tres días como agente nuevo y acabas de leer un mensaje que dice: “Escalé el ticket al L2, revisa el CSAT del last touch, el error es E-4402 en el billing engine y el customer está en plan Pro con flag de churn risk. Actualiza el macro en Zendesk y avisa en #support-ops”. Cierras los ojos un segundo. Entiendes el inglés… pero no el idioma interno. Anotas en un bloc de notas lo que crees que significa cada cosa y sientes ese nudo familiar: no quieres preguntar otra vez para no parecer lento, pero tampoco quieres responder mal y dañar la métrica del equipo.

Esa escena se repite en decenas de onboarding remotos cada mes. No falla el inglés. Falla la falta de un mapa compartido: acrónimos, nombres de sistemas, códigos de error y jerga que solo existe dentro de esa compañía. Cuando ese mapa no existe, los agentes nuevos tardan semanas en ganar velocidad, los managers pierden tiempo corrigiendo y la experiencia del cliente se resiente. La buena noticia es que puedes construir ese glosario de forma simple, humana y útil desde el día uno, aunque seas contractor o estés en tus primeras semanas.

¿Cómo crear un glosario de términos y jerga de soporte para nuevos agentes?

Un glosario de soporte efectivo se crea en tres capas claras: (1) acrónimos y métricas que se usan todos los días, (2) nombres exactos de sistemas internos y dónde viven, y (3) códigos de error o estados con su significado, impacto y siguiente acción. Se documenta en un lugar vivo (casi siempre Notion o un doc compartido enlazado desde Slack), se escribe en lenguaje sencillo en inglés y español cuando hace falta, y se actualiza con dueño responsable cada vez que aparece un término nuevo en un ticket o en una stand-up. No es un diccionario infinito: es una herramienta de onboarding que reduce la curva de las primeras cuatro a seis semanas y evita que el agente nuevo dependa solo de preguntar en el canal. Si lo haces bien, el equipo gana consistencia, el CSAT se estabiliza más rápido y tú demuestras proactividad que los managers de soporte de EE. UU. notan en las primeras revisiones de performance.

El resto de esta guía te muestra cómo armarlo sin burocracia, qué incluir de verdad, qué errores te hacen quedar mal y cómo presentarlo para que se use.

¿Qué debe incluir un glosario de soporte para que realmente sirva en el día a día?

Empieza por lo que aparece en los primeros siete días de un agente. Si el glosario no resuelve esas dudas inmediatas, nadie lo abre.

1. Acrónimos y métricas de soporte Lista solo los que se usan en conversaciones reales. Ejemplos típicos en equipos que trabajan con Zendesk, Intercom, Gorgias o HubSpot Service Hub:

• CSAT: Customer Satisfaction Score (encuesta post-ticket, suele ser 1-5 o 1-10).
• FCR: First Contact Resolution (ticket resuelto en el primer contacto sin reopen).
• AHT: Average Handle Time.
• SLA: Service Level Agreement (tiempo de primera respuesta o de resolución).
• L1 / L2 / L3: niveles de escalamiento.
• TTR / TTV: Time to Resolution / Time to Value.
• NPS o CES cuando el equipo los menciona en retrospectivas.
• Macro, trigger, automation, view, side conversation (términos nativos de la herramienta de tickets).

Al lado de cada acrónimo pon: definición en una frase, por qué importa para el cliente o para el equipo, y un ejemplo de uso en Slack o en una nota interna.

2. Nombres de sistemas internos y “dónde vive cada cosa” Los agentes nuevos se pierden no por el producto del cliente, sino por el stack interno. Documenta:

• Herramienta de tickets (Zendesk, Intercom, Freshdesk, Salesforce Service Cloud).
• CRM de clientes (HubSpot, Salesforce).
• Billing / suscripciones (Stripe, Chargebee, Recurly, o el “billing engine” interno).
• Base de conocimiento interna y externa.
• Canal de escalamiento (Slack #support-escalations, #tier2, Jira Service Management).
• Herramientas de calidad y coaching (Gong, Chorus, o grabaciones en Loom).
• Admin panels o backoffice con nombres propios de la empresa (por ejemplo “Admin v2”, “Legacy Console”, “Feature Flags dashboard”).

Para cada sistema indica: para qué se usa, quién tiene acceso, enlace (si es posible), y qué NO se debe hacer ahí (por ejemplo, “nunca edites el plan del customer directo en Stripe sin aprobación de Billing”).

3. Códigos de error, estados y flags Esta es la parte que más tiempo ahorra. En lugar de “el error de siempre”, escribe:

• Código o nombre exacto (E-4402, payment_failed_3ds, subscription_past_due, feature_gate_blocked).
• Qué ve el customer.
• Qué significa en el backend o en billing.
• Impacto (¿puede seguir usando el producto? ¿hay riesgo de churn?).
• Pasos de troubleshooting en orden.
• Cuándo escalar y a quién (con el canal de Slack o el formulario interno).

4. Jerga de producto y de equipo Términos que solo existen en esa compañía: nombres de planes, nombres internos de features, apodos de flujos (“the golden path”, “self-serve motion”, “high-touch renewal”), y abreviaturas de segmentos de clientes (SMB, MM, ENT).

5. Capa de “cómo lo decimos al customer” Un glosario solo interno no basta. Agrega la versión customer-facing cuando el término sea sensible (cobros, bugs, outages). Así el agente nuevo no improvisa un mensaje que suene técnico o alarmista.

Guarda todo en Notion (la opción más común en startups y scale-ups de EE. UU.), con una base de datos simple o una página con toggles. Enlázalo en el canal de Slack #support o #new-agents y en el checklist de onboarding del ATS o del wiki. Si el equipo ya usa Confluence o un Google Doc, respeta ese hogar; la herramienta importa menos que el hábito de abrirlo.

¿Cómo documentar acrónimos, sistemas y códigos de error sin abrumar al equipo nuevo?

La tentación es escribir un tratado. Resiste. Un glosario que se usa cabe en la cabeza de alguien que lleva 10 días.

Usa este formato mínimo por entrada (en inglés, porque el equipo y los tickets viven en inglés; puedes añadir una línea en español solo si tu cohorte de agentes lo necesita al inicio):

• Term / Code:
• Plain-English meaning:
• Where it appears: (Zendesk field, Slack, customer email, admin panel)
• Why it matters:
• What to do / What to say:
• Owner / Last updated:

Ejemplo realista de entrada de código de error:

Term / Code: E-4402
Plain-English meaning: The customer’s card was declined on a recurring charge after 3DS authentication failed.
Where it appears: Billing engine logs + Zendesk ticket tag “billing_e4402”
Why it matters: Account stays active for 3 days (grace), then features lock. High churn risk if not contacted same day.
What to do: 
1. Confirm last 4 digits and expiry in the billing tool (read-only).
2. Send macro “card_update_3ds”.
3. If customer replies with new card, update and note “E-4402 cleared”.
4. Escalate to #billing-support only if charge already retried 3 times.
What to say (customer): “It looks like the payment method needs a quick update for security verification. Here’s a secure link…”
Owner: @maria.billing | Updated: 2025-03-12

Ese nivel de concreción es lo que separa un wiki decorativo de una herramienta que un agente abre a las 11 p. m. mientras tiene al customer en vivo.

Cómo construirlo en la práctica (sin pedir permiso eterno):

1. Durante tu primera semana, crea una página privada en Notion o un Google Doc llamado “Support Glossary – working draft”.
2. Cada vez que alguien use un término que no conoces, agrégalo en el momento (aunque quede a medias).
3. En la daily o en un mensaje corto de Slack pide: “Estoy armando el glosario de onboarding. ¿Me confirman si esta definición de E-4402 está correcta?”. Los seniors suelen corregir con gusto porque les ahorra preguntas repetidas.
4. Cuando tengas 25–40 entradas sólidas, muévelo al espacio compartido y pide que lo enlacen en el onboarding checklist (Greenhouse, Ashby o el Notion de People/HR suelen tener un lugar para “New Support Hire”).
5. Graba un Loom de 4–6 minutos recorriendo las 10 entradas más críticas. Los managers de soporte de EE. UU. valoran enormemente el material async; demuestra que piensas en el equipo, no solo en tu cola de tickets.

Si eres contractor (lo más frecuente vía Deel, Remote.com o similar, con W-8BEN), esto además te posiciona como alguien que mejora el sistema, no solo como alguien que cierra tickets. Eso pesa en las renovaciones de contrato y en las conversaciones de rate.

¿Qué errores te descartan o te hacen perder credibilidad cuando intentas ordenar la jerga interna?

Los managers y los agentes senior notan rápido quién entiende el oficio y quién solo copia términos.

Evitar estas trampas no requiere ser el más antiguo del equipo. Requiere disciplina de documentación y respeto por el tiempo ajeno.

¿Cómo mantener el glosario vivo cuando el producto y las herramientas cambian cada mes?

Un glosario muerto es peor que no tenerlo: genera falsa confianza. La cadencia que funciona en equipos remotos de soporte (sobre todo en SaaS de EE. UU.) es simple:

• Dueño rotativo o fijo liviano: una persona de L2 o un team lead dedica 20 minutos cada dos semanas. Si eres nuevo y te ofreces, suele aceptarse.
• Regla de “término nuevo = entrada nueva”: cualquier acrónimo o código que aparezca dos veces en una semana entra al doc el mismo día.
• Revisión con Engineering/Billing: un hilo mensual en Slack o 15 minutos en la retros de soporte: “Estos 5 códigos cambiaron de comportamiento; confirmen definición”.
• Señal de vida visible: fecha “Last reviewed” arriba del todo y un canal o thread #glossary-updates.
• Conexión con control de calidad: cuando el QA o el manager revise tickets (con scorecards en Gorgias, Zendesk QA o una hoja simple), una de las preguntas puede ser “¿Usó la definición y el macro correctos del glosario?”. Eso cierra el círculo.

Herramientas reales que ya están en la mayoría de stacks:

• Notion o Coda como fuente de verdad.
• Slack para captura rápida y anuncios.
• Loom para explicar entradas complejas sin reunión.
• Zendesk/Intercom macros que enlazan al glosario o que ya traen el lenguaje aprobado.
• HubSpot o Salesforce solo para la parte de contexto de customer (segmento, plan, ARR), no para redefinir términos de soporte.

Si la empresa usa Ashby o Greenhouse para onboarding, pide que el link del glosario quede como task obligatoria del primer día junto con la firma del contractor agreement y el W-8BEN. Suena menor; cambia la tasa de adopción.

¿Qué miran los managers de soporte de EE. UU. cuando evalúan si un agente ya domina el lenguaje interno?

No miran si memorizaste cincuenta siglas. Miran comportamiento observable en las primeras 30–45 días:

• ¿Resuelves sin preguntar lo mismo dos veces?
• ¿Tus notas internas en el ticket son claras para el siguiente agente (handoff limpio)?
• ¿Usas el macro y el tono correctos cuando hay código de error de billing o de auth?
• ¿Escala con contexto (“E-4402, ya envié macro de update, customer en grace day 2, ARR 8k”) en lugar de “ayuda con este billing”?
• ¿Contribuyes a que el siguiente nuevo sufra menos (un Loom, tres entradas nuevas, una corrección de definición)?

En muchos equipos el quality score o el coaching score incluye “product and internal process knowledge”. Dominar el glosario te sube ahí sin necesidad de ser el más rápido en AHT el primer mes. Y cuando llega la conversación de aumento de rate (común en contratos de $18–35 USD/hora para L1 bilingües según stack y vertical, y más alto en L2 o specialized support), poder mostrar “reduje tiempo de ramp de nuevos agentes” es una prueba concreta de impacto, no solo de esfuerzo.

Si todavía estás aplicando a roles, mencionar en la entrevista que en tu experiencia anterior (o en tu preparación) construiste o mejoraste un internal glossary de acrónimos, sistemas y error codes te diferencia. Los hiring managers de soporte están cansados de candidatos que solo dicen “soy bueno con el customer”. Quieren gente que entienda operaciones.

---

Artefacto copiable: plantilla de glosario + mensaje de lanzamiento

Copia esto en Notion, Coda o Google Docs y ajústalo con tu stack real. Está en inglés porque es el idioma de trabajo del equipo y de los tickets.

Last reviewed: YYYY-MM-DD | Owner: @name
Link this doc in #support channel description + new-hire checklist.

## How to use
1. Search before asking in Slack.
2. If a term is missing, add a row and tag the owner.
3. Customer-facing language lives in the "What to say" column — do not improvise on billing/auth/outages.

## 1. Acronyms & Metrics
| Term | Meaning | Target / Why it matters | Example in Slack or ticket |
|------|---------|-------------------------|----------------------------|
| CSAT | Customer Satisfaction score after ticket | ≥ 4.6 | "CSAT drop on billing macros — review?" |
| FCR | First Contact Resolution | Track weekly | "FCR low on password resets" |
| AHT | Average Handle Time | Context only, not vanity | — |
| SLA | First reply or resolution time | First reply < 2h (business) | — |
| L1/L2 | Support tiers | L2 = billing + bugs with repro | "Escalating to L2 with logs" |

## 2. Internal Systems
| System | What we use it for | Access | Rules |
|--------|--------------------|--------|-------|
| Zendesk | All customer tickets | All agents | Never delete tickets; use macros |
| Stripe / Billing engine | Subscriptions, invoices, taxes | Read for L1; write with approval | No plan changes without Billing |
| HubSpot | Customer context, ARR, owner | Read | Don’t edit lifecycle stage |
| Slack #support-ops | Escalations & incidents | All | Use thread + tag severity |
| Admin / Feature flags | Account state, gates | L2+ | Screenshot before/after |

## 3. Error codes & states (priority)
| Code / State | What customer sees | Meaning | Steps | Escalate when | What to say (customer) |
|--------------|--------------------|---------|-------|----------------|------------------------|
| E-4402 | “Payment failed” or silent fail | 3DS / card decline on renew | 1) Check grace days 2) Macro card_update_3ds 3) Note ticket | 3 failed retries or enterprise account | “Your payment method needs a quick security update. Secure link: {link}” |
| payment_past_due | Banner or email | Invoice open > X days | … | … | … |
| feature_gate_blocked | Feature missing | Plan or flag off | … | … | … |

## 4. Product & team jargon
| Term | Meaning | Notes |
|------|---------|-------|
| Golden path | Happy self-serve activation flow | — |
| High-touch renewal | Enterprise renewal with CSM | Hand off, don’t close alone |

## 5. Update log
- YYYY-MM-DD — Added E-4402, updated billing macro link — @name

Mensaje corto para pegar en Slack cuando lo publiques:

Hey team — I put together a living Support Glossary for new agents (acronyms, internal tools, error codes + what to say to customers).
It’s in Notion: [link]
Loom walkthrough (4 min): [link]
If you see a missing term or a wrong definition, comment or edit directly. Goal: faster ramp, fewer repeat questions, cleaner handoffs.
Thanks for the corrections in advance.

Usa la plantilla tal cual el primer día. Mejórala con la realidad de tu cola. Ese gesto, más que cualquier curso genérico, muestra que entiendes cómo se opera el soporte remoto en empresas de Estados Unidos.

---

Si estás evaluando si roles de Customer Support, Success o Operations remotos encajan con tu nivel de inglés, tu experiencia y el rango en dólares que necesitas, puedes hacer el diagnóstico gratuito de 2 minutos en el portal de Talento Bilingüe (/diagnostico/). Te orienta con claridad sobre perfiles y bandas sin rodeos.

El glosario no es un documento bonito. Es la diferencia entre sobrevivir las primeras semanas y convertirte en la persona que el equipo quiere que esté en el siguiente turno difícil. Empieza hoy con diez términos. El resto se construye en público, en el mismo canal donde hace tres días no entendías nada.