Intermediación interfuncional: cuando Ops se convierte en el tejido conectivo
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Son las 4:47 PM de un jueves. Llega el DM de Slack de su VP de Sales: "oye, ¿puedes entrar a una llamada rápida? Sales y CS están peleando otra vez por el crédito de cuota por el upgrade".
Usted no está en el equipo de Sales. No está en el equipo de CS. No es dueño del plan de compensación ni del motor de renovaciones. Va a estar en esa llamada durante 90 minutos, y en el minuto 87 alguien va a decir "okay, ¿puede Ops simplemente idear una solución y enviarla a todos?".
Bienvenido al trabajo para el que nadie lo contrató.
La descripción de puesto de Operations Manager habla de diseño de procesos, gestión de proveedores, KPI, dashboards. Lo que no dice, pero que todos en el equipo de liderazgo esperan en silencio, es que usted es el tejido conectivo entre cada función que no se habla directamente. Sales y CS. Finance y Sales. IT y Marketing. Product y CS. Lo arrastrarán a cada pelea entre equipos que no tenga un dueño claro, y su evaluación de desempeño incluirá en silencio "¿logró que la empresa dejara de sangrar por estas heridas?".
Este playbook trata de cómo desempeñar ese rol sin convertirse en el vertedero permanente del trabajo sin dueño de todos los demás.
The Broker Mindset
Aquí está el cambio mental que me tomó tres años interiorizar de verdad: usted no es quien decide. Usted es el traductor.
Sales habla en cobertura de pipeline y cumplimiento de cuota. CS habla en NRR, GRR y cuentas en riesgo. Finance habla en GAAP, ingresos diferidos y rastros de auditoría. IT habla en tickets, ventanas de cambio y "¿alguien probó esto en staging?". Product habla en peso de roadmap y capacidad de ingeniería.
Cinco tribus, cinco vocabularios, cinco conjuntos de incentivos. La mayoría de las peleas interfuncionales no son en realidad desacuerdos sobre hechos. Son dos funciones hablando sin escucharse porque nadie está convirtiendo un dialecto en otro.
Esa conversión es su trabajo. Y en el segundo en que toma partido, pierde el trabajo.
Si se pone del lado de Sales en la pelea del crédito de cuota, CS dejará de confiar en sus grupos de trabajo. Si se pone del lado de Finance en un asunto de reconocimiento de ingresos, Sales lo esquivará. La influencia del intermediario viene de la neutralidad. Tiene que ser la persona en quien cada función confía para representar su posición de forma justa ante las demás, incluso cuando usted en privado piensa que un lado está siendo ridículo.
Hay una versión táctica de esto: absorba el proceso, nunca la decisión. Usted dirigirá la reunión. Usted construirá el documento. Usted escribirá el resumen. Usted no será dueño del resultado. El resultado pertenece a los dos VP que de verdad tienen un P&L en juego. Su trabajo es asegurarse de que tengan un camino lo bastante despejado hacia una decisión que no puedan evitar tomar.
The "Who Owns This?" Mapping
Antes de poder intermediar en nada, necesita una respuesta brutalmente específica a una pregunta: ¿quién es dueño de cada flujo de trabajo recurrente que cruza las líneas de equipo?
Construya un RACI por flujo de trabajo. Una página. Cinco columnas. Sin ambigüedad. Si dos equipos creen ambos que son Accountable del mismo flujo de trabajo, acaba de encontrar el verdadero problema, y lo encontró antes del próximo DM de Slack de las 4:47 PM.
Aquí tiene un ejemplo real para el traspaso de lead a oportunidad:
| Paso | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Umbral de lead scoring alcanzado | Marketing Ops | VP Marketing | SDR Manager | Sales Ops |
| Enrutamiento MQL → SQL | SDR | SDR Manager | AE Manager | Marketing Ops |
| SLA de primer contacto (15 min) | SDR | SDR Manager | (ninguno) | RevOps |
| Motivo de descalificación codificado | SDR | SDR Manager | Marketing Ops | RevOps |
| Reciclaje a nutrición | Marketing Ops | VP Marketing | SDR Manager | (ninguno) |
| Conversión a oportunidad | AE | AE Manager | SDR Manager | RevOps |
Un solo Accountable por fila. Siempre. Si tiene dos nombres en la columna Accountable, tiene una pelea esperando a estallar. Sáquela a la luz antes del incendio, no durante.
Construya uno de estos para cada flujo de trabajo recurrente entre equipos:
- Traspaso de leads (Marketing → SDR → AE)
- Pronóstico de renovaciones (CS → Finance → Sales)
- Rescate de churn (CS → Sales → Product)
- Disputa de facturación (Finance → CS → Sales)
- Solicitud de cambio de sistema (IT → funciones afectadas)
- Incorporación de nuevas contrataciones (HR → IT → manager → Ops)
- Traspaso de incorporación de clientes (Sales → CS, ver abajo, este es el clásico)
Una empresa típica de tamaño mediano tiene entre 8 y 12 de estos. Puede resolver todo el conjunto en un trimestre si lo convierte en su proyecto paralelo. Nadie más lo hará, y el día que tenga los 12 mapeados es el día en que su trabajo cambia.
Running a Cross-Functional Working Group
Cuando algo entre equipos está activamente roto, lo arrastrarán a una reunión. Esa reunión, por defecto, será:
- 60 minutos, recurrente semanalmente
- De 8 a 12 personas, incluidas 4 que nunca ha conocido
- Actualizaciones de estado de cada función
- Ninguna decisión
- Una reunión de seguimiento programada para el próximo jueves
Este es el formato que asegura que nada se arregle. Recháchelo.
Aquí está el formato que de verdad funciona:
60 minutos como máximo. Si no puede llegar a una decisión en 60 minutos con las personas adecuadas en la sala, no tiene un grupo de trabajo, tiene una reunión de estado. El estado va en documentos asíncronos, no en los calendarios.
Tres personas como máximo. Una persona por función afectada. Cualquiera que deba ser Consulted recibe el documento antes y el resumen después. Cualquiera que deba ser Informed recibe el resumen. No reciben la reunión.
Regla de decisión-o-cancelar. Si no se llega a una decisión para el minuto 55, la reunión se cancela y el asunto escala a los VP. Nada de "volvamos a reunirnos". Nada de "déjame consultarlo con mi equipo". Cancelada. Escalada. La amenaza de la escalada es lo que fuerza la decisión.
Sin espacio recurrente hasta que se tome la decisión. Los grupos de trabajo existen para resolver un asunto específico y luego disolverse. En el minuto en que entran al calendario semanalmente, se convierten en teatro de actualización de estado.
Una agenda de grupo de trabajo que cabe en una nota adhesiva:
Grupo de trabajo: crédito de cuota en upgrades a mitad de ciclo
Fecha: 2026-05-02
Asistentes: VP Sales, VP CS, RevOps (intermediario)
1. (10 min) Enuncie el problema en una frase. Confirme que estamos de acuerdo.
2. (15 min) Cada función presenta su posición. 5 min cada una. Sin interrupciones.
3. (20 min) Tres opciones sobre la mesa. Pros, contras, quién paga qué.
4. (10 min) Elija una. O escale.
5. (5 min) Resumen, dueño, fecha límite. Listo.
Aplica la regla de decisión-o-cancelar. Minuto 55, o tenemos una decisión o esto va al CRO y al CCO mañana.
Ese formato ahorra unas 4 horas de tiempo de reunión por asunto interfuncional frente al formato por defecto. A lo largo de un año, con entre 8 y 12 de estos asuntos, le ahorrará a su equipo de liderazgo de 32 a 48 horas de reuniones, y reducirá el tiempo de ciclo de decisión de 3 semanas a unos 4 días.
Escalation Triage
No todo incendio es su incendio. La forma más rápida de perder este trabajo es absorber cada fallo entre equipos que aterriza en sus DM. La segunda forma más rápida es devolverlo todo y volverse conocido como la persona de Ops que no quiere ayudar.
La regla de clasificación: absorba el proceso, nunca la decisión.
Cuando llega el DM de Slack, hágase dos preguntas:
- ¿Hay una sola función que sea claramente Accountable de esta decisión?
- ¿Tiene la información que necesita para tomarla?
Si la respuesta a ambas es sí, devuélvalo. Con cortesía, con una razón específica y con un camino a seguir.
"Esta es una decisión de Sales y CS sobre el plan de compensación. Yo no soy dueño de la política de cuotas. ¿Pueden tú y Mike (VP CS) tomar 15 minutos mañana? Les enviaré un documento con los tres escenarios para que entren listos para decidir."
No se está negando a ayudar. Se está negando a ser dueño de la decisión. Se está ofreciendo a hacer el trabajo de preparación, que es el verdadero valor agregado del intermediario.
Si la respuesta a la pregunta 1 es no (si genuinamente no tiene dueño, o si dos funciones reclaman la propiedad), ahí es cuando absorbe. Pero absorba solo el proceso.
"Está bien, yo dirijo el grupo de trabajo. Lo haremos el jueves a las 2 PM, 60 minutos, tú y Sarah, decisión-o-cancelar. Enviaré el documento de preparación el martes. La decisión es de ustedes dos. Yo solo conduzco la agenda."
El patrón: usted les facilita decidir. Usted no decide en su nombre. El día que empieza a decidir en nombre de los VP es el día en que se convierte en el chivo expiatorio conveniente de cada mal resultado entre equipos.
The "Nobody Owns Customer Onboarding Handoff" Classic
Este es el agujero negro interfuncional más común que he visto, y apostaría 100 dólares a que está roto en su empresa ahora mismo.
La forma del problema:
- El AE cierra el trato el viernes a las 5:30 PM. Choca los cinco.
- El cliente espera una llamada de kickoff "la próxima semana".
- CS toma la cuenta... ¿cuándo, exactamente? ¿Cuando el AE actualiza la etapa en el CRM? ¿Cuando Finance emite la primera factura? ¿Cuando el cliente escribe a soporte preguntando cuándo es su kickoff?
- Las 72 horas entre "trato cerrado" y "el CSM es dueño" no pertenecen a nadie.
En esas 72 horas, el entusiasmo del cliente llega a su punto máximo y empieza a decaer. Estaban emocionados el viernes a las 5:30 PM. Para el miércoles, ya han pasado a otras prioridades. La llamada de kickoff cae en una sala más fría de lo que tenía que estar.
Las empresas que arreglan este traspaso ven un aumento del 8 al 15% en la retención a 90 días y una mejora medible en el tiempo hasta el primer valor. Esa no es una estadística de marketing que saco del aire. Es el rango que he visto personalmente desarrollarse en cuatro empresas SaaS de tamaño mediano que mapearon este flujo de trabajo y asignaron una propiedad de hilo único.
Aquí está cómo arreglarlo:
Paso 1: mapee el traspaso en incrementos de 90 minutos. Desde la hora 0 (se firma el trato) hasta la hora 168 (una semana después del cierre). Para cada ventana, ¿quién es Accountable? ¿Qué artefacto tiene que existir? ¿Qué experimenta el cliente? La mayoría de las empresas descubren que las horas 12 a 60 no tienen dueño en absoluto.
Paso 2: asigne una propiedad de hilo único. Un nombre. Normalmente un Customer Onboarding Manager si tiene uno, de lo contrario un CSM designado. Son Accountable desde el momento en que el AE marca la oportunidad como Closed-Won hasta que ocurre la llamada de kickoff.
Paso 3: instrumente el SLA. Llamada de kickoff programada dentro de las 48 horas del cierre. Primer correo de cara al cliente dentro de las 4 horas. Sincronización del CRM y la herramienta de incorporación dentro de 1 hora. Construya un dashboard. Revíselo semanalmente con el liderazgo de Sales y CS. El dashboard, no la reunión, es lo que hace real al SLA.
Paso 4: ejecute el grupo de trabajo para fijar el diseño. 60 minutos, 3 personas (VP Sales, VP CS, usted), decisión-o-cancelar. Entre con el mapa y tres opciones de propiedad. Salga con una.
Esta es la solución interfuncional de mayor influencia en la mayoría de las empresas SaaS B2B. Si no hace nada más de este playbook, haga esta.
The Post-Mortem Playbook
Los fallos entre equipos van a ocurrir. Un lanzamiento de producto fallido. Una renovación perdida que todos asumieron que alguien más vigilaba. Una actualización de Salesforce que rompió el enrutamiento de leads durante seis días. La pregunta no es si ocurren. Es si aprende algo de ellos.
Ejecute un post-mortem sin culpas dentro de los 5 días hábiles. No 30. No "el próximo trimestre". Cinco días hábiles, mientras el recuerdo esté fresco y a las personas involucradas todavía les importe.
Tres preguntas, en este orden:
- ¿Cuál fue el camino de la decisión? ¿Quién decidió qué, cuándo y con base en qué información? Reconstruya la línea de tiempo. Sea específico.
- ¿Dónde se rompió? ¿Fue una decisión faltante, una decisión equivocada o una decisión correcta mal ejecutada? Distintas roturas necesitan distintas correcciones.
- ¿Quién es dueño de la corrección? Un nombre, una fecha límite, un artefacto específico (RACI actualizado, nuevo SLA, cambio de sistema, capacitación).
Una plantilla esqueleto:
Post-Mortem: {nombre del incidente}
Fecha del incidente: 2026-04-12
Fecha del post-mortem: 2026-04-17
Dueño (intermediario): Camellia (Ops)
Asistentes: {3-5 personas directamente involucradas}
Línea de tiempo (sea específico, use marcas de tiempo cuando sea posible):
- 04-12 09:14: ...
- 04-12 11:30: ...
- 04-12 14:02: ...
¿Cuál fue el camino de la decisión?
{2-3 párrafos reconstruyendo quién decidió qué.}
¿Dónde se rompió?
- ¿Decisión faltante? Sí/No. Detalle.
- ¿Decisión equivocada? Sí/No. Detalle.
- ¿Fallo de ejecución? Sí/No. Detalle.
Qué estamos cambiando:
1. {Corrección específica}, Dueño: {nombre}, Fecha límite: {fecha}
2. {Corrección específica}, Dueño: {nombre}, Fecha límite: {fecha}
Qué NO estamos cambiando (y por qué):
{Cosas sobre las que la gente preguntará y que deliberadamente dejamos intactas.}
Regla sin culpas: este documento nombra decisiones, no personas. Los nombres aparecen en la línea de tiempo por claridad, no en la sección de "qué se rompió".
El documento vive en una carpeta compartida. No en los DM de alguien. No en un hilo de Slack. Una carpeta, con una convención de nomenclatura de archivos consistente, que cualquiera en el equipo de liderazgo pueda encontrar seis meses después, cuando el mismo asunto esté a punto de volver a ocurrir.
El encuadre sin culpas importa. En el minuto en que un post-mortem se convierte en una cacería de brujas, la gente deja de ser honesta y usted deja de aprender nada. El objetivo no es averiguar quién la regó. El objetivo es averiguar qué de su proceso permitió que un error causara tanto daño.
Brokering Is a Real Job
Aquí está lo que nadie me dijo cuando empecé a hacer este trabajo: intermediar es un trabajo de verdad. No es gasto general. No es "lo blando". Es el rol de mayor influencia en las empresas de tamaño mediano, y casi siempre queda sin reconocimiento porque el trabajo es invisible cuando se hace bien.
Bien hecho, intermediar no parece nada. Las reuniones son cortas. Las decisiones se toman. Las peleas entre equipos no se repiten. Los traspasos de incorporación son fluidos. El pronóstico de renovaciones no tiene ningún momento de "espera, ¿quién es dueño de esta cuenta?". Todos asumen que la empresa simplemente funciona así.
Mal hecho, intermediar parece DM de Slack a las 4:47 PM del jueves cada semana, ciclos de decisión de tres meses y un equipo de liderazgo que en silencio se guarda rencor.
El Ops IC que domina esto se convierte en la persona en quien cada VP confía. Lo arrastrarán a la sala de estrategia, no porque tenga un título que diga que pertenece ahí, sino porque es la única persona que puede ver todo el sistema y explicarlo en cinco dialectos distintos. Ese es el camino de Operations Manager a Director of Operations. Pasa directamente por el rol de intermediación, y la mayoría de la gente lo pasa por alto porque cree que no es su trabajo.
Sí es su trabajo. Ahora tiene un playbook para hacerlo.
Learn More
