De Scrapy a Escalado: Finalmente Conseguistes Recursos para Hacer Crecer tus Operaciones No-Code. ¿Y Ahora Qué?

Hola, mi nombre es Phil Blayken. Soy el jefe de Innovación Empresarial en Zapier, y estoy muy emocionado hoy de hablar con ustedes sobre cómo pasar de improvisado a escalado en operaciones sin código aquí en ProductivityConf.

Vamos a sumergirnos de lleno. Así que antes de entrar en toda esta historia, solo quiero contarles un poco sobre mi historia. Así que, como muchos no-coders, no vengo del mundo de todo lo técnico, TI y ciencias de la computación. De hecho, era actor antes de estar en tecnología, haciendo de todo, desde Law and Order y Gossip Girl hasta películas y latas y el Tribeca Film Festival. Y luego, eventualmente, comencé mi propio negocio porque era un camarero súper mediocre cuando vivía en la ciudad de Nueva York. Y me enamoré de la chica marketing y promociones, que es lo que están viendo aquí en su concierge de NYC. Y ese negocio fue adquirido por Get, que es un competidor de Uber con sede en Israel, donde querían que pasara de la gestión del equipo de calle a construir una operación que pudiera incorporar conductores en el campo usando tácticas de marketing de equipo de calle y de campo. Y querían que construyera una forma completa de incorporar conductores en el campo con una aplicación. Y no teníamos soporte de desarrolladores en mi equipo, así que yo era el desarrollador y lo construí. Y eso fue lo que me reclutó en Compass para hacer mucho trabajo sin código allí, donde construí el flujo de trabajo de incorporación sin código para miles de agentes inmobiliarios en todo EE.UU., hasta que Compass se hizo pública. Y luego, eventualmente, comencé No-Code Ops, que fue la primera comunidad para profesionales de operaciones en sin código. Construimos un producto de observabilidad llamado Operator, y eventualmente fuimos adquiridos por Zapier, donde estoy hoy como el jefe de Innovación Empresarial. Así que ha sido un viaje realmente accidentado. He aprendido un montón sobre escalar sin código. He cometido casi todos los errores. Creo que puedes cometer en el libro.

El ascenso del héroe de ops. Esta es la historia que escuché una y otra vez cuando hablaba con miembros de la comunidad No-Code Ops. Típicamente comienza cuando te piden automatizar algo como el enrutamiento de leads. Nunca has hecho esto antes, así que comienzas a leer cómo hacerlo, qué sistemas puedes usar para hacerlo. No tienes apoyo de desarrollo de tu equipo de desarrollo porque ¿cuándo recibe ops apoyo de los desarrolladores?

¿Y entonces qué haces? Encuentras una herramienta como Zapier o Airtable o Typeform para ayudarte en ese proceso. Hemos visto a muchas personas usar Zapier para cosas como el enrutamiento de leads cuando se trata de, oye, si es este tipo de lead que dicen en el formulario, enrútalos a esta persona. Si es este tipo de lead, enrútalos a esta persona. Y flujos de trabajo súper complejos también con gestión de territorios y cosas así. Así que no tienes que ser técnico para saber cómo configurar esas cosas en Zapier y eso es típicamente cómo muchas personas se introducen en No-Code. Solo tenían que resolver algo y no tenían apoyo de desarrollo.

Pero aquí está el problema. Tú como la persona en tu equipo, tal vez no estás en ventas ops o rev ops todavía. Estás en el equipo de ventas, estás en el equipo de CX, tal vez eres jefe de personal. No has hecho algo como esto antes, pero la palabra se difunde. Y ahora todos quieren no tener que esperar a que los desarrolladores desarrollen algo para moverse súper rápido. Así que el equipo de marketing podría querer participar y tienen sus propias ideas. Y luego tu equipo de liderazgo de ventas dice, bueno, tal vez tengamos algunas de estas solicitudes rápidas, pero ahora tienes que comenzar a entrenar a otros y construir más cosas, anotando tu propia hoja de ruta. Y se sale de control muy rápido cuando la gente descubre que hay una manera más rápida de hacer las cosas que ir a los desarrolladores. ¿Y en qué se convierte eso? Caos.

Así que es la paradoja del éxito. Y tienes que equilibrar la construcción de cosas y también al mismo tiempo mantenerlas. Y si aún no estás haciendo esto a tiempo completo, porque no estás a tiempo completo en ventas ops, rev ops, también tienes tu trabajo diario que considerar y cuidar. Así que esto es lo que me gusta decirle a las personas que están en este punto de su carrera donde están comenzando a recibir todas estas solicitudes entrantes, comenzando a convertirse en la persona popular en la empresa para estos tipos de sistemas. Me gusta decir que lo que te trajo aquí no te llevará allí. Así que vamos a profundizar en esa idea. Entonces, ¿qué te trajo aquí? Tenías esta mentalidad de construir primero, preguntar después. Simplemente lo resolviste. La documentación, estaba mayormente en tu cabeza. Probablemente no existe. Eras la única persona haciendo las cosas.

Así que realmente no tenías que documentar mucho. Ignoraste errores hasta que realmente impactaron a otros o sistemas masivamente críticos. Y no había necesidad de demostrar el ROI porque probablemente había poca o ninguna inversión en estas cosas. Pero una vez que comienzas este viaje, te das cuenta de que, bueno, algunas cosas tienen que cambiar ahora que estás obteniendo más reconocimiento y trabajos más críticos dentro de la empresa.

Así que cambiar a preguntar primero, construir después. Así que muchas veces nosotros en Nocode, nos emocionamos mucho con las soluciones. De hecho, a veces hasta el día de hoy cuando la gente me habla sobre sus problemas, están teniendo en el trabajo o las cosas manuales que están haciendo, literalmente estoy construyendo el zap en mi cabeza y pensando en la solución o estoy pensando en ese software que vi en Product Hunt que sé que resolvería esto. Así que me encantan las soluciones. A los Nocoders les encantan las soluciones. Pero cuando comenzamos a recibir tareas más grandes y más grandes que involucran múltiples departamentos o áreas más críticas, tenemos que comenzar con los problemas.

Profundizar y aprender los problemas antes de recomendar cualquier solución. Como siempre digo a la gente, nunca confiarías en un médico que si fueras al médico y comenzaras a hablar y a los 30 segundos de que estás hablando, el médico dijera, tengo la receta para ti. Probablemente no confiarías en ese médico. Pero si el médico se sentara y te hiciera un montón de preguntas y te escuchara y realmente entendiera lo que estaba pasando, y luego tuviera una recomendación, probablemente confiarías más en ese médico. Y cuando se trata de las áreas de negocio de otras personas que les importan mucho, sienten lo mismo. Así que es realmente bueno escuchar para conocer íntimamente los problemas.

El producto final que terminas creando a través de múltiples departamentos, no debería ser una sorpresa. Deberías haber involucrado a las personas temprano y con frecuencia, para que al final de las cuatro o cinco semanas de construcción, no estés entregando algo donde la gente esté totalmente sorprendida. Deberían sentir que, oh sí, estuve involucrado en esto. Di mi opinión sobre esto. Sabía exactamente lo que venía. Así que no quieres que nadie se sorprenda al final. Y luego, idealmente, también hay algo llamado el ciclo de vida del desarrollo de automatización, que es algo que nos importa profundamente aquí en Zapier.

Pensamos mucho en ello en NoCodeOps también. Pero cuando los desarrolladores de software construyen cosas, tienen el ciclo de vida del desarrollo de software. Y cuantas más automatizaciones estás creando, o cuantos más sistemas Nocode estás creando, es bueno pensarlos en diferentes etapas, ¿verdad? ¿Está esto en la etapa de idea de la construcción? ¿Está esto en la etapa de implementación de la construcción? ¿Está esto en la etapa de pruebas? ¿Estamos en la etapa de mantenimiento? ¿Estamos en la etapa de observación y mantenimiento? ¿Está esto en la etapa de deprecación? Hay un ciclo de vida completo. Y poder identificar claramente en qué ciclo de vida se encuentran diferentes automatizaciones y diferentes construcciones que tienes, es realmente, solo una muy buena manera de comunicar a otros cuál es tu capacidad para lo que puedes manejar en cualquier momento dado. Así que una muy buena manera de gestionar el recurso que es tu tiempo cuando estás trabajando con toneladas de otras personas.

Fomentar una cultura de documentación. Así que lo número uno con la documentación es comenzar a documentar lo que desearías haber tenido.

Así que no sé ustedes, pero he construido algunos sistemas NoCode bastante complejos en Zaps donde regreso un año después y me pregunto, ¿en qué estaba pensando cuando creé esta cosa? Y luego paso horas tratando de rastrear dependencias o viendo, ya sabes, análisis de impacto. Si cambio esto, ¿qué más sucedería? Y así me gusta decir que si había algo que desearías haber tenido cuando estabas arreglando tu depuración o cambiando algo, simplemente comienza con eso. Simplemente comienza con algo súper simple sobre lo que puedas escribir acerca de cada automatización o sistema NoCode que comiences a desarrollar. Siempre me gusta centrarme en la consistencia sobre la extensividad. Y una de las formas en que me gusta hacer eso es acordar con otras personas, oye, ¿cuál es el formato rápido y el lugar donde vamos a documentar las cosas? Así que digamos que es Notion. Cada vez que creo una automatización, simplemente voy a crear un rápido por qué, qué sistemas están involucrados, qué equipo posee esto, ¿a qué sistemas está relacionado? Cuantos más tipos de plantillas puedas hacer para la documentación, más natural será completarlas. Y un consejo profesional, si te grabas hablando en voz alta sobre la documentación y luego alimentas tu plantilla en ChakGPT, también puedes hacer que ChakGPT templatice tus construcciones en documentación escrita para ti según cómo hablas de ellas. Un truco divertido y pequeño ahí.

Así que hay algunos tipos de documentación. Está la arquitectura, el recorrido del usuario y cómo usar esto. Todos son importantes. La arquitectura es realmente buena si tienes múltiples constructores. Así que piensa en cómo se hizo esto, por qué se hizo esto, qué decisiones se tomaron detrás de esto, qué sistemas estuvieron involucrados, qué aplicaciones SaaS estuvieron involucradas, qué compensaciones se hicieron. El recorrido del usuario es más bien, oye, a medida que un usuario pasa por este proceso o esta automatización, así es como se ve su recorrido. Comienza con este formulario, y luego los datos fluyen por aquí y llegan a este mensaje de Slack y también llegan a esta parte del CRM con imágenes. Así que eso es como el recorrido del usuario. A veces también la gente lo hace como el recorrido de datos. ¿Cuál es el rastro de datos a través de esta automatización o sistema no-code? Y luego está el cómo usar esto. Esto es típicamente cuando la gente escucha documentación, piensan en este. Dato curioso, si nunca has usado la herramienta de documentación de cómo usar esto, te recomiendo mucho tango. us, mi herramienta favorita en ese frente. Pero eso es cuando estás enseñando a la gente cómo usar el sistema que has construido. Y luego, cuando se trata de documentación de arquitectura, es realmente importante cubrir el cómo y el por qué. Por qué construiste algo y por qué tomaste ciertas decisiones, realmente bueno para otras personas que vienen en tus zapatos en el futuro a medida que creces y progresas en tu carrera. Oh, y lo siento, última parte. Casi me pierdo esta, lo cual es gracioso. Pero si la gente no puede encontrarla, no es real. Así que si se crea documentación y nadie la lee o no puede encontrarla, la documentación no existe. Así que pon tu documentación en lugares donde la gente la encuentre fácilmente. Mi esposa es realmente increíble en esto y es gracioso porque solía trabajar para una empresa de documentación llamada Guru. Pero cada vez que quiero saber dónde está algo en la casa que ella guardó, siempre me dice, Phil, ¿dónde querrías que estuviera? Ahí es donde está. Y así piensa de esa manera, ¿verdad? ¿Dónde querrían tus usuarios tu documentación si estuvieran en medio de algo que estaban construyendo? Así que a menudo me gusta ver notas adhesivas viviendo justo en los diagramas o notas justo en los zaps o si hay diferentes campos, ¿puedes poner pequeños íconos en esos campos que signifiquen algo para la gente? Así que pon la documentación donde la gente la encuentre fácilmente.

Prepárate para el impacto de errores. Así que cuantos más sistemas crees sin código, más grandes sean, más errores vas a tener. Lamento decirlo, pero sucederá. Así que implementa herramientas de monitoreo y flujos de trabajo. Sabes, hay algunas herramientas realmente buenas por ahí para monitorear. Una de ellas se llama Log Snag. También puedes construir tus propios flujos de trabajo de monitoreo cuando podrías decir, si ciertos campos o cosas cambian en esto, envía webhooks a Zapier o Log Snag para que pueda recibir una alerta cada vez que algo cambie. Así que puedes recibir alertas sobre cambios críticos del sistema que podrían afectar tus flujos de trabajo.

Si el control de acceso basado en roles no es realmente suficiente, mencioné esto un poco antes cuando se trata de documentación, pero como poner pequeños emojis que signifiquen algo para tu equipo. Como entrenar a tu equipo sobre lo que significan diferentes emojis en diferentes campos. Y sabes, ese emoji de candado puede ser no edites este campo, ¿verdad? Sin hablar conmigo. Así que una forma realmente fácil, sabes, de hacer saber a otros qué es tocable, no tocable, rompible, cambiable, etcétera.

Cada automatización debería tener un SPOA, un único punto de responsabilidad. Cuantas más personas en una empresa, más automatizaciones suceden, ¿verdad? Puedes tener un formulario en tu sitio web que tenga 10 automatizaciones diferentes ejecutándose después de que alguien lo envíe a través de tres departamentos diferentes que se preocupan por esos. Y así cuando nadie posee una automatización, cuando no hay un nombre diciendo, yo poseo esta automatización, entonces es fácil para alguien entrar y cambiar algo y no saber a quién va a impactar o con quién necesitan hablar. Así que cada automatización teniendo un único punto de responsabilidad es realmente importante. Y cuando esos únicos puntos de responsabilidad dejan la empresa, es realmente importante tener las conversaciones sobre quién debería hacerse cargo de esos y qué necesita aprenderse. Y luego vincular las resoluciones de errores a la documentación relevante. Así que mira, si tienes un gran problema que acabas de depurar, una de las mejores cosas que puedes hacer es hacer un breve informe sobre ello y adjuntarlo a la documentación de esa automatización. De esa manera, si alguien enfrenta ese problema nuevamente, puede ver qué se hizo con ese problema y quién lo resolvió y qué se hizo para resolverlo.

Así que A, B, C, D, me gustó siempre estar comunicando y me hubiera gustado algo sobre como resultados o algo, pero no fluía tan bien como A, B, C, D. Así que siempre estar comunicando dividendos. Nosotros, los de operaciones que automatizamos cosas y que estamos creciendo nuestras carreras haciendo estas automatizaciones y construyendo operaciones complejas a través de múltiples equipos, es realmente fácil pensar, sabes, si hago el trabajo y es lo suficientemente bueno, la gente lo notará y eso será suficiente para hablar por sí mismo. El trabajo es lo suficientemente bueno. Pero eso simplemente no es cierto porque cuando las automatizaciones funcionan, son bastante invisibles. Y así es realmente bueno mostrar tu trabajo a la gente y los resultados de este y mencionar el trabajo que estás haciendo y las hojas de ruta que estás construyendo. Si estás comenzando a recopilar trabajo de muchas otras personas, muestra una hoja de ruta en diferentes reuniones diciendo aquí están las solicitudes que estoy recibiendo. Y si la gente te da solicitudes, sigue con ellas si las completas diciendo, oye, realmente me encantó tu idea de agregar un nuevo campo en el formulario que, sabes, daría más información a esta parte de nuestro CRM. Aquí implementé eso. Gracias por los comentarios.

Celebremos a esa persona que me dio ese comentario y cerremos ese ciclo. Obtener historias de éxito específicas. Hombre, si estás haciendo un trabajo realmente genial, nadie va a destacar esas cosas por ti. Una de las cosas que hicimos en Compass, una de las empresas en las que trabajé, fue que hicimos una prueba de tiempo de alguien haciendo las cosas a la antigua y alguien haciendo las cosas con la automatización. Terminamos ahorrando en promedio, ya sabes, cuatro horas a la semana por persona en ese departamento, lo que resultó ser un gran ahorro de costos. Pero nadie iba a ir y hacer ese estudio por nosotros. Tuvimos que construir eso y realizar ese estudio. Eso fue realmente útil. Pero a veces a la gente también le gustan los ejemplos cualitativos de estas cosas. Así que, ya sabes, obtener algunas citas de usuarios internos sobre cómo solía ser un proceso antes de que te involucraras y cómo se ve después o, ya sabes, mostrar como una historia de un cliente que recibió un mejor servicio debido a algo que implementaste en términos que, ya sabes, ganaron eficiencias de velocidad en el back end, ¿verdad? Así que, como historias específicas podrían hablarle a la gente también, no solo números.

Y luego aquí hay algunas formas realmente geniales de mostrar ROI. No voy a tomar crédito por esto. Esto vino de Mike Cardona, quien es uno de mis pensadores favoritos en el espacio de operaciones e IA. Lo publiqué en esta URL, tinyurl.com slash hidden levers AI, que es su boletín, que también recomiendo mucho. Pero ya sabes, a veces no siempre puedes mostrar dinero o ahorros de costos cuando se trata de automatizaciones. Eres genial cuando puedes hacerlos. Pero cuando no puedes, hay otras formas de mostrar ROI. Hay ahorros de tiempo, reducción de errores, aumento de la producción, mejora de la calidad de los datos y mayor satisfacción del cliente, como medir, ya sabes, el servicio CSAT antes y después de un proceso que implementaste.

Aquí hay un ejemplo de un rastreador de KPI. Y esto también viene de Mike. Así que, ya sabes, es el nombre de la automatización, una descripción de la misma, ya sabes, cuáles fueron los objetivos generales, así que un poco entrando en ese por qué.

Y en el lado derecho, ves algunos de los KPIs. Así que establece puntos de referencia, ya sabes, tienes algunos puntos de referencia sobre cómo está funcionando actualmente el proceso, qué está rindiendo actualmente, y luego cuáles son algunas de nuestras métricas que queremos alcanzar y objetivos y cómo lo estamos haciendo actualmente en comparación con ellos y cuánto tiempo se ha rastreado eso. Mostrar estas actualizaciones a la gente, como dije, nadie va a hacer este trabajo por ti. Así que es realmente importante hacerlo y hablar sobre tu trabajo. Y eso no es solo para, ya sabes, obtener oportunidades más grandes y mejores dentro de la empresa, sino también, ya sabes, si alguna vez quieres entrar en consultoría sin código, lo cual muchas personas de no-code y automatización hacen ya sea a tiempo parcial en una capacidad de luz de luna, o terminan haciéndolo a tiempo completo, este es el tipo de trabajo que tienes que hacer para los clientes de todos modos. Así que es realmente bueno acostumbrarse a esto.

Ahora, cuando tienes tu historia de ROI, diferentes equipos en tu empresa se preocuparán por diferentes cosas. IT se preocupará por una cosa, los desarrolladores se preocuparán por otra cosa, el liderazgo empresarial será totalmente diferente, y los usuarios finales se preocuparán por algo totalmente diferente también. Y cuando digo usuarios finales, me refiero a las personas internas de tu empresa que están usando estos sistemas sin código y automatizaciones. Y aquí hay un gran ejemplo de esto. Este es un zap que teníamos en no-code ops, que era nuestro formulario de usuario, nuestro formulario de entrada y enrutador. Así que una persona de IT podría decir, oye, ¿de quién es la autorización que envía correos electrónicos a través de Gmail? Porque puedes ver que se está usando Gmail aquí, y por cierto, consejo profesional, asegúrate de usar cuentas de servicio cuando puedas como automations en o hello en tu empresa.com, en lugar de tu correo electrónico, porque si alguna vez cambias de trabajo, todas esas autorizaciones no funcionarán más en sistemas de automatización como Zapier. Los desarrolladores podrían decir, oye, ¿qué versión de nuestro formulario de Webflow estaba conectada aquí? El liderazgo empresarial podría decir, hmm, me pregunto cuántos leads están calificados versus no calificados, me encantaría ver esos números. Y un usuario final podría mirar esto, que es como uno de tu equipo de operaciones y decir, espera, ¿caminos? ¿Las personas que son leads calificados aquí no están terminando en nuestra lista de boletines? Y dato curioso, cuando miras caminos en Zapier, no solo elige un camino, los datos pueden simplemente ir por uno, verifica las condiciones de cada camino. Así que en realidad, si estaban calificados, también recibirían el boletín si se inscribieron para ello, dato curioso.

Ganancias rápidas adicionales, así que algunas cosas súper accionables que puedes hacer de inmediato. Así que la primera ya te di un adelanto, que eran las autorizaciones de servicio versus autorizaciones personales. La siguiente son presentaciones regulares. Así que si otras personas están construyendo estas automatizaciones en tu empresa, reúnanse y hablen sobre lo que están haciendo entre sí. Algunas de las mejores ideas que tuve en mi trabajo como profesional de operaciones vinieron de otros departamentos y colaborando y siendo como, wow, ni siquiera sabía que podíamos usar las herramientas de esa manera. Así que reunir a la gente para hacer presentaciones con las cosas geniales que están haciendo, súper inspirador, realmente validante. Programas de certificación interna, si quieres que más personas usen herramientas como Zapier y Airtable y Formstack y Fillout, estas herramientas sin código complejas o poderosas, a veces es bueno simplemente tener un programa de certificación interna como, oye, así es como usamos esta herramienta aquí, así es generalmente cómo usar esta herramienta, pero así es como usamos esta herramienta aquí y estos son lo que significan estas cosas. Y simplemente tener algún tipo de certificación interna puede hacerte sentir realmente cómodo permitiendo que más personas usen la herramienta, no centralizando todo para que caiga en tu plato. Hacer visible el trabajo de mantenimiento a las partes interesadas. Mira, cuando estás construyendo muchas automatizaciones sin código, es fácil eventualmente tener, no sé, 30, 40% de tu trabajo no sea construir cosas nuevas, sino mantener cosas que ya existen o arreglar cosas. Si estás haciendo ese trabajo, hazlo visible para tus gerentes y tus partes interesadas en actualizaciones semanales o mensuales. Porque si no muestras que estás haciendo ese trabajo, solo van a querer que hagas más de las cosas nuevas todo el tiempo, pensando que, bueno, ¿qué está haciendo ese otro 30, 40% del tiempo? Es como, bueno, el software no se mantiene solo, ¿verdad? Así que vas a ser tú quien lo mantenga. Así que asegúrate de que estás abogando por ti mismo y expresando eso. Y por último, si necesitas más recursos, vende el dolor, no los beneficios. Muchas veces la gente verá un nuevo sistema por ahí o una nueva herramienta y dirán, oh Dios mío.

Los beneficios que vamos a obtener de esto van a ser increíbles. Y tratan de vender beneficios y son rechazados bastante fácilmente por el liderazgo ejecutivo o la gestión de su equipo, la gestión departamental. Me gusta decirle a la gente, vende el dolor en esos casos. Intenta decir que si no hacemos esto, esto es lo que podría pasar. Y cuando vendes el dolor, cuando trabajas en operaciones, generalmente es más tangible que vender los beneficios.

Así que eso es todo de mi parte. Espero que te lleves de esta charla cómo crecer más allá de lo que te has encontrado en, que eres la persona de operaciones que comenzó a hacer todas estas cosas con no-code y automatizaciones y ahora estás recibiendo cosas más y más grandes para hacer. Y ahora tienes algunas estrategias claras y concretas sobre cómo tomar este tipo de lugar en el que te has tal vez tropezado y convertirlo en una carrera completa con propósito. Esto se ha convertido en una carrera completa para mí. Conozco a cientos de otros para quienes se ha convertido en carreras completas. Y esas carreras, cuanto más propósito tengas con ellas, más esto puede convertirse en pasar de ser un vendedor que hace un poco de trabajo de sistemas a una persona de operaciones de ventas a tiempo completo o trabajando por las noches y consiguiendo algunos trabajos freelance en esto o eventualmente incluso comenzando tu propia agencia y haciendo esto a tiempo completo. Así que todas estas habilidades son útiles para avanzar en tu camino.

Si tienes alguna pregunta, no dudes en contactarme en LinkedIn o X o TikTok. Me encontrarás bajo Philip Lakin. No puedo esperar para hablar contigo y escuchar sobre tu viaje. Muchas gracias y que tengas un increíble resto de tu tiempo en ProductivityConf.