Operaciones y Legal

Cómo redactar un SOP (Standard Operating Procedure) que todos sigan

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

Cuando un equipo remoto en Estados Unidos empieza a crecer, el cuello de botella casi nunca es la falta de talento: es la falta de procesos que se ejecuten igual aunque cambie la persona. He revisado scorecards de contratación, auditorías de operaciones y post-mortems de empresas que pagan en dólares a independent contractors de Latinoamérica. El patrón se repite: el fundador o el operations lead documenta “a su manera”, el nuevo VA o el specialist sigue otra lógica, y en tres semanas aparecen errores de facturación en Stripe, tickets mal cerrados en HubSpot o datos inconsistentes en Salesforce. Un SOP bien escrito no es un manual bonito para archivar en Notion. Es el artefacto que permite que un reclutador de Greenhouse o Ashby confíe en que puedes escalar sin supervision constante, y que un cliente estadounidense sepa que el trabajo se hará igual si estás de vacaciones o si se suma otro contractor. En roles de Operations Coordinator, Executive Assistant, Customer Success o Revenue Operations, saber redactar SOPs que la gente realmente use se traduce en rangos de USD 2.800 a 5.500 mensuales para perfiles mid-level, y más si demuestras ownership de procesos críticos. Lo que sigue no es teoría: es el método que usan los equipos que dejan de depender de la memoria de una sola persona.

¿Cómo se redacta un SOP que todos sigan de verdad?

Se redacta partiendo del resultado final que el proceso debe producir, no de la lista de tareas que “siempre se han hecho”. Luego se descompone en pasos numerados, verificables y con evidencia (captura, Loom o checklist), se prueba con alguien que no conoce el proceso y se ajusta hasta que esa persona lo ejecute sin preguntar. El SOP que se sigue es corto, visual, con dueño claro y con un criterio de “listo” explícito. Todo lo demás (textos eternos, jerga interna sin glosario, pasos ambiguos) se ignora o se interpreta mal, especialmente en equipos distribuidos que trabajan con Deel, QuickBooks, Xero o Stripe.

La diferencia entre un documento que vive y uno que muere es simple: el primero se escribe para el ejecutor del próximo martes a las 9 a.m., no para impresionar al manager. Empiezas por el “por qué existe este proceso” en dos líneas, defines el trigger (qué lo dispara), el owner, las herramientas exactas y el output esperado. Después viene la secuencia. Si un paso requiere abrir Slack, Loom, Notion o el admin de HubSpot, lo dices con el nombre real de la pantalla y el botón. Si hay decisión (¿cliente enterprise o SMB?), usas una bifurcación clara. Y cierras con la prueba de calidad: qué se revisa antes de marcar el ticket como done.

¿Por qué la mayoría de los SOPs fallan en equipos remotos con empresas de EE. UU.?

Porque se escriben como diarios personales del experto, no como instrucciones operativas. El expert conoce los atajos de Salesforce, sabe cuándo un pago en Stripe necesita nota en el W-8BEN del contractor y recuerda de memoria el SLA de respuesta. El nuevo hire o el VA no. Resultado: el SOP se lee una vez, se archiva y la gente vuelve a preguntar por Slack o a inventar su propio flujo.

Hay tres fallas estructurales que veo una y otra vez:

1. Ambigüedad de verbs. “Revisar el lead” no dice nada. “Abrir el record en HubSpot, verificar que el campo Lifecycle Stage = MQL, y si el score es ≥ 70 mover a SQL con nota de 1 línea” sí.
2. Falta de evidencia visual. Un párrafo de 120 palabras sobre cómo exportar un reporte de QuickBooks se reemplaza por un Loom de 90 segundos + 3 capturas anotadas. El tiempo de onboarding cae a la mitad.
3. Ausencia de ownership y de “definition of done”. Si nadie firma el SOP y no hay checklist final, cada persona decide cuándo está “suficientemente bien”. En operaciones que tocan dinero (reembolsos, invoices, payroll con Deel) eso genera riesgo real y fricción con el cliente estadounidense.

Además, muchos SOPs se escriben en un vacío legal y de herramientas. Si el proceso involucra datos de clientes, background checks (Checkr o HireRight) o información financiera, el documento debe indicar qué se puede compartir y qué no. No necesitas un tratado de compliance; necesitas una línea clara: “Nunca copies PII completa a un Google Doc personal. Usa solo el workspace de la empresa.”

¿Qué estructura y herramientas convierten un SOP en algo que se ejecuta sin fricción?

La estructura mínima que funciona en la práctica (y que los operations leads de startups y scale-ups de EE. UU. reconocen al instante) es esta:

• Título + versión + fecha + owner
• Objetivo en una frase (qué resultado de negocio produce)
• Cuándo se usa (trigger)
• Quién lo ejecuta y quién lo aprueba
• Herramientas exactas (Slack canal #ops, Loom, Notion página X, HubSpot pipeline Y, Stripe dashboard, Deel, etc.)
• Pasos numerados con subtareas si hace falta
• Evidencia (captura, link a Loom, o checklist)
• Criterio de terminado
• Excepciones y escalamiento
• Historial de cambios

Herramientas reales que aparecen en los stacks que pagan bien:

• Notion o Confluence para el repositorio vivo del SOP.
• Loom para grabar el walkthrough (ideal 1–3 minutos por proceso crítico).
• Slack para notificar cambios de versión y para el canal de dudas.
• HubSpot / Salesforce cuando el proceso toca CRM.
• Stripe, QuickBooks o Xero para flujos de dinero.
• Deel para onboarding y pagos de contractors.
• Google Drive o Notion embeds para las capturas organizadas.
• Checklists nativas de Notion o un simple Markdown que se copie a cada ticket.

No hace falta un software de “SOP management” caro al inicio. Lo que sí hace falta es disciplina de versión: cada cambio material sube el número de versión y se anuncia en el canal correcto. Si el proceso impacta compliance o dinero, el owner lo revisa con el manager antes de publicar.

Tabla comparativa: cómo se percibe cada forma de documentar

¿Cómo se documenta paso a paso con capturas, Loom y checklists sin volver loco al equipo?

Empieza por elegir un proceso que duela hoy: onboarding de un contractor en Deel, calificación de un lead en HubSpot, cierre de mes en QuickBooks, o respuesta a un ticket de churn risk. No empieces por el proceso más complejo ni por el más “bonito”.

Paso 1 – Graba el estado actual (as-is) Abre Loom y ejecuta el proceso tú mismo o pide al expert que lo ejecute pensando en voz alta. No edites todavía. El objetivo es capturar la realidad, incluidos los atajos y las confusiones.

Paso 2 – Extrae los pasos y limpia Transcribe solo lo esencial. Elimina divagaciones. Cada paso debe empezar con un verbo de acción y, cuando aplique, el nombre de la pantalla o del botón.

Paso 3 – Añade evidencia visual

• Capturas: usa flechas o números (1, 2, 3) sobre la imagen. Una captura por decisión crítica o por pantalla confusa.
• Loom: graba de nuevo la versión limpia. Habla despacio, nombra lo que haces (“Now I click on ‘Create invoice’ in the top right”). Sube el video a un drive o a Notion y pega el link en el SOP.
• Checklist: al final del SOP, o como bloque separado que se copia a cada ejecución.

Paso 4 – Prueba con alguien limpio Dale el SOP a una persona que no conoce el proceso. Observa (o pídele que grabe su propia pantalla). Cada vez que se trabe, anota el punto exacto y corrige el documento. Esta prueba es no negociable si quieres que “todos lo sigan”.

Paso 5 – Publica con dueño y versión Owner = la persona que puede autorizar cambios. Versión 1.0. Fecha. Link en el canal de Slack correspondiente. Si el proceso es crítico, agenda una revisión en 30 o 90 días.

Aquí tienes un artefacto listo para copiar y adaptar. Es un checklist operativo + esqueleto de SOP que puedes pegar directo en Notion:

SOP TITLE: [Nombre del proceso] 
Version: 1.0 | Date: YYYY-MM-DD | Owner: [Nombre + rol]
Last reviewed: 

OBJECTIVE
One sentence: what business result this process produces.

TRIGGER
When does this process start? (e.g. “New contractor signed in Deel” / “Deal stage moved to Closed Won in HubSpot”)

ROLES
- Executor: 
- Approver / Escalation: 
- Tools: Slack #[channel], Notion [page], HubSpot, Stripe, Loom, Deel, etc.

STEPS
1. ...
2. ...
3. ...
   - Screenshot or Loom timestamp: 
4. ...

DEFINITION OF DONE
- [ ] All fields completed in [tool]
- [ ] Loom / note left in the record
- [ ] Notification sent to #[channel] if required
- [ ] No PII stored outside approved tools

EXCEPTIONS
If X happens → do Y and notify Z within N hours.

CHANGELOG
v1.0 – Initial version – [date] – [author]

¿Cómo hablas de tus SOPs en inglés cuando te entrevistan o cuando entregas trabajo a un cliente estadounidense?

Los managers y reclutadores de EE. UU. no quieren oír “me gusta documentar”. Quieren oír ownership, reducción de tiempo de ramp-up y menor dependencia de personas clave. Aquí van dos guiones verbatim que puedes adaptar. Úsalos en llamadas de screening, en entrevistas con el hiring manager o cuando un cliente te pida que “dejes todo documentado”.

Guion 1 – Screening o primera llamada con reclutador (Greenhouse/Ashby flow)

Recruiter: Tell me about a time you created or improved a process documentation.
You: Sure. In my last role I owned the contractor onboarding flow. We were using Deel and Slack, and every new hire took almost a week to become productive because the steps lived only in one person’s head. I mapped the as-is process, recorded a 2-minute Loom for each critical path, added annotated screenshots, and built a short checklist in Notion. Then I had two new contractors run it without help. We cut ramp-up from five days to about two. I also added a clear escalation path so people knew exactly when to ping finance or the ops lead. Happy to walk you through the structure I use if useful.
Recruiter: How do you make sure people actually follow the SOP?
You: Three things. Keep it short and visual, assign a clear owner who updates the version, and tie it to the definition of done on the ticket or the task. If the checklist isn’t completed, the work isn’t done. I also drop a quick note in Slack when a new version goes live so nobody works off an old link.

Guion 2 – Conversación con hiring manager o cliente que necesita que documentes un proceso crítico (ops / EA / CS)

Manager: We need this billing handoff documented so it doesn’t break when someone is out.
You: Understood. I’ll start by shadowing the current process end-to-end and recording a Loom of the live workflow in Stripe and QuickBooks. Then I’ll turn it into a one-page SOP with numbered steps, screenshots on the decision points, and a checklist that can be copied into every ticket. I’ll include the exact escalation path if a payment fails or if the amount is over our threshold. Once the draft is ready I’ll have someone who hasn’t done the process before run it so we catch any gaps. I’ll send you version 1.0 by [day] and we can review it together for 15 minutes. Does that match what you need?
Manager: Yes. Also make sure it covers the W-8BEN piece for contractors.
You: Got it. I’ll add a specific step that flags when we need an updated W-8BEN on file before the first payout, and I’ll note that we never store tax forms outside the approved drive. I’ll also link the Deel section so the executor knows where to check the status.

Fíjate en los phrasal verbs y el tono directo: “cut ramp-up”, “walk you through”, “tie it to the definition of done”, “shadowing the current process”, “flag that”. Así hablan los operations people que contratan.

¿Qué errores te descartan (o te hacen perder la confianza del cliente) y cómo los evitas?

• Escribir novelas. Nadie lee 2.000 palabras de proceso. Máximo 1–2 páginas + media.
• Olvidar el trigger y el owner. Sin eso el SOP es huérfano.
• No probarlo con alguien nuevo. El expert siempre cree que está claro.
• Mezclar herramientas personales con las de la empresa (Drive personal, Notion free personal). En empresas que usan Checkr/HireRight y manejan datos de clientes esto es red flag.
• No versionar. Cuando HubSpot o Stripe cambian la UI, el SOP viejo genera errores y la gente deja de confiar en la base de conocimiento.
• Documentar solo lo fácil y dejar los edge cases en la cabeza de una persona. Los edge cases son exactamente lo que rompe el fin de semana o el cierre de mes.
• Usar jerga local sin glosario cuando el equipo es mixto (EE. UU. + LATAM). Mejor inglés simple y consistente, o bilingüe si el equipo lo acordó, pero nunca ambiguo.

En el background check y en las referencias, lo que pesa es si dejaste procesos que otros pudieron ejecutar. Un portfolio anónimo con 2 SOPs bien hechos (antes/después de tiempo de ejecución o de error rate) vale más que diez afirmaciones genéricas en el CV.

Si estás evaluando qué roles de operaciones, customer success, revenue operations o executive assistance encajan con tu experiencia y qué rangos salariales en USD son realistas para tu perfil hoy, puedes hacer el diagnóstico gratuito de 2 minutos en el portal (/diagnostico/). Te da una lectura clara de encaje y de siguiente paso sin compromiso.

Un SOP que todos siguen no es un monumento a tu conocimiento. Es un contrato operativo corto, visual y probado que reduce fricción, protege el dinero y la data del cliente, y te posiciona como la persona que hace que el equipo remoto escale sin caos. Empieza por un solo proceso que hoy genera retrabajo, aplícale la estructura de arriba, graba el Loom, prueba con alguien limpio y publica con dueño. En dos semanas vas a notar la diferencia en la cantidad de pings de “¿cómo se hacía esto?”. Y eso, en el mercado de empresas de Estados Unidos que contratan talentos de Latinoamérica, es exactamente la señal de seniority que buscan.