Marco para el diseño de soluciones Salesforce para equipos empresariales de comercialización

Introducirse en una nueva organización por primera vez puede ser casi como embarcarse en un viaje a través del mar oscuro durante la temporada de tormentas. Esto es especialmente cierto en un entorno empresarial que tiene cientos o miles de usuarios utilizados por múltiples grupos de accionistas que tienen su propia pila tecnológica integrada en Salesforce.

He trabajado en múltiples entornos empresariales y hay varios principios que he desarrollado basándome en los patrones que he encontrado a lo largo de mi carrera. Estos principios combinan partes de desarrollo ágil y gestión de cambios para garantizar un despliegue eficaz y sin problemas de su solución.

Mi objetivo es hacer que este viaje sea menos desalentador para que su conjunto de habilidades pueda brillar, sin importar lo compleja que pueda ser una organización. Independientemente del problema que esté tratando de abordar, este es mi proceso de cuatro pasos que utilizo al diseñar y desarrollar una solución para los equipos de salida al mercado de la empresa.

Paso 1: Identificar en qué se está metiendo (aka. Descubrimiento)

Antes de invertir cualquier cantidad de tiempo haciendo el trabajo de configuración, el primer paso es entender qué tipo de procesos existentes están siendo utilizados diariamente por los usuarios finales. Cuando se empieza a tratar con instancias que tienen múltiples grupos de interesados fuera de ventas y marketing, como finanzas y atención al cliente, tratar de descubrir cada pequeño proceso es una forma segura de no producir ningún impacto significativo (especialmente si su org tiene cientos o incluso miles de usuarios finales).

Así es como empiezo mi descubrimiento y me aseguro de no perder demasiado tiempo yendo por un agujero de conejo sin fin..

Descubrimiento de datos

Opinión controvertida: la mayoría de lo que hacemos los profesionales de ops es por algún tipo de requerimiento de reporting.

No puedo decirle cuántas veces he oído a alguien decir: «tenemos un problema para realizar un seguimiento coherente de los puntos de dolor de los clientes potenciales» con un campo llamado algo así como «Problemas autoidentificados» – junto con otras cinco variaciones del mismo campo.

En toda mi experiencia, creo que nunca me he encontrado con una instancia de Salesforce en la que no hubiera deuda técnica. Por este motivo, la forma más rápida de encontrar la fuente de la verdad al iniciar su proceso de descubrimiento es obtener acceso a cualquier informe o cuadro de mando actuales que los equipos utilicen de forma habitual. Los simples filtros y columnas de un informe pueden proporcionarle mucha información en muy poco tiempo.

Descubrimiento de la integración

Para esta pieza, vamos a asumir que el objetivo del CRM es actuar como una única fuente de verdad.

Una vez que tenga los puntos de datos que son más importantes para la organización, ahora quiere saber cómo los datos se están pasando entre los sistemas. Hay cuatro cosas que hago durante este proceso:

1. Enumere todas las herramientas utilizadas para las operaciones diarias que están integradas en su CRM.
2. Identifique qué herramientas están integradas en su CRM
3. Identifique qué objetos utiliza cada herramienta. La forma más sencilla de conseguirlo es buscar el nombre de la herramienta y añadir «se requieren permisos de integración de Salesforce» al final de la consulta de búsqueda.
4. Catalogar todos los campos clave que se utilizan en el CRM
5. Mapee cualquier campo clave y cómo se transfieren los datos entre cada sistema.
6. Audite cualquier automatización en estos sistemas que esté vinculada a estos campos.

Para este paso, me gusta utilizar una herramienta como Miro y diagramas de Salesforce de referencia para mapear los objetos a los que está vinculada una integración y cómo esos objetos están vinculados dentro de Salesforce.

Preferencia personal: Siempre empiezo combinando los diagramas de Sales Cloud y de tareas y eventos en un único diagrama.

Descubrimiento de procesos

Esta es posiblemente la parte más difícil de hacer, en mi opinión – así que siéntate y toma notas.

Hay dos pasos clave en cómo realizo el descubrimiento de procesos:

1. Cómo se supone que deben hacerse las cosas
2. Cómo se hacen las cosas en realidad.

Casi siempre existe una discrepancia entre ambos.

Para identificar cómo se supone que deben hacerse las cosas, me gusta asistir a algún tipo de proceso de incorporación de nuevos empleados y tomar notas detalladas que describan los pasos para realizar las tareas cotidianas.

Aprender cómo se hacen las cosas en realidad es probablemente mi parte favorita de todo este proceso. La forma en la que saco la verdad de los usuarios es prefiriendo que no me importa si no siguen el proceso ideal – es más importante para mí aprender cómo están haciendo actualmente su trabajo.

Consejo: Para futuros proyectos, me gusta comparar el proceso ideal con el proceso real y encontrar el término medio entre ambos para crear una versión actualizada que haga a todos más felices.

Paso 2: Empezar a construir un Producto Mínimo Viable (MVP)

Ahora que ha descubierto los puntos de datos específicos que son más importantes para la organización y cómo se están aprovechando a través de los sistemas, las partes interesadas internas y las unidades de negocio, finalmente podemos llegar a la configuración.

Dado que la construcción de un producto mínimo viable (MVP) puede ser muy diferente para todos, no voy a pasar mucho tiempo hablando de todo esto. El objetivo con nuestro MVP es relativamente simple:

1. Probar la viabilidad de la solución
2. Reducir el tiempo de despliegue
3. Sentar las bases para futuras iteraciones.

Hay un par de cosas que hago cuando construyo un MVP…

Configuración inicial

Cuando hago cualquier configuración, me gusta empezar intentando construirla con la menor intervención humana necesaria. Esto significa mapear las acciones clave en los sistemas a los datos creados o actualizados e intentar usar eso como parte de su proceso automatizado.

En el caso de que su proceso requiera algún proceso manual, lo más importante en mi opinión es garantizar que sea una experiencia positiva para el usuario y que el resultado sea algo más que «actualizar un campo por el bien de un informe». Si el proceso requiere que alguien actualice un campo/s, quiero asegurarme de que hay valor para todas las partes implicadas.

Pruebas Inclusivas

Una vez que haya construido su configuración inicial, aquí es donde me gusta reclutar a mi ‘campeón de usuario final’. En mi experiencia, el problema inicial que estamos abordando con nuestra solución vendrá de un Líder Senior, por lo que es probable que tenga algún tipo de compra ejecutiva y si no lo hace, vuelva al proceso de descubrimiento y muéstreles los datos para obtener la compra.

A menudo he visto que los profesionales de ops ejecutarán a través de sus flujos de trabajo para asegurarse de que los datos están siendo procesados como se esperaba y no hay errores en un silo. Personalmente, me gusta enseñar a un usuario final cómo hacer algunas pruebas básicas y hacer que participen en el proceso – a menudo referido como pruebas de aceptación del usuario (UAT). En lugar de simplemente lanzar un nuevo proceso y decir: «esta es la nueva forma de avanzar», estás invitando a las personas que utilizan el sistema día a día en el proceso de desarrollo que ayuda cuando finalmente lanzas tu solución al equipo más grande.

Paso 3: Crear documentación de principio a fin

Esta es probablemente la parte menos favorita de la mayoría de la gente de estar involucrado en el mundo de las operaciones – pero personalmente, ¡es una de mis cosas favoritas que hacer! Sin embargo, no empezó así.

Si no te gusta crear documentación, aquí tienes un par de razones egoístas por las que deberías hacerlo:

1. Si te sientes «incomprendido» o «infravalorado», la documentación es una oportunidad para mostrar cuánto trabajo conlleva la creación de una solución.
2. Si te sientes «incomprendido» o «infravalorado», la documentación es una oportunidad para mostrar cuánto trabajo conlleva la creación de una solución
3. Es una gran pieza de garantía para llevar a cualquier revisión de rendimiento interno con su manager.
4. Es una gran pieza de garantía para llevar a cualquier revisión de rendimiento interno con su manager
5. Hace que la incorporación o la formación de nuevos miembros del equipo de operaciones sea un proceso mucho más fácil.

Cuando escribo mi documentación, hay dos audiencias para las que escribo: no técnicos y interesados técnicos. Cada pieza de documentación que creo parte del objetivo empresarial y se vuelve cada vez más técnica.

A modo de ejemplo, si estuviera escribiendo documentación sobre un proceso de parámetros UTM, así es como podría estructurarse mi documentación:

1. Propósito: ¿Por qué deberíamos preocuparnos por los Parámetros UTM?
2. Por qué deberíamos preocuparnos por los Parámetros UTM?
3. Objetivo: ¿Cuál es el objetivo con este proceso?
4. Objetivos: ¿Qué hemos construido?
5. Información general: ¿Qué son los parámetros UTM?
6. Proceso del equipo de marketing: ¿Cómo va a participar el equipo de marketing más grande?
7. Documentación técnica: ¿Qué campos, flujos, integraciones, etc. hemos construido y cómo funcionan?
8. Resumen

Paso 4: Lanzamiento al Equipo Mayor

Aquí es donde realmente llegamos a probar nuestras habilidades blandas que es lo que te llevará al siguiente nivel en tu carrera.

Para hacer el lanzamiento inicial, me gusta preparar una breve presentación y demostración del proceso. En la presentación, así es como suelo estructurar el contenido:

1. Propósito
2. Información general
3. Revisión de alto nivel de los Entregables
4. Demostrar el proceso
5. Fijar las expectativas
6. Fechas clave (como cuándo este proceso se convertirá en parte del proceso estándar para el equipo)

Aquí tienes un par de consejos que he utilizado en el pasado a la hora de presentar y lanzar un nuevo proceso:

• Cuando demuestro el proceso, me gusta dejar que la persona con la que he trabajado durante la parte de pruebas, dirija esta parte de la presentación.
• Esté lo más preparado posible para cualquier objeción. Especialmente si este nuevo proceso requiere que el equipo añada un paso adicional en su flujo de trabajo actual, habrá cierta resistencia. Lo mejor que puede hacer es enmarcar la forma en que esta nueva solución o proceso les beneficiará a largo plazo.
• Cuando algo pasa de la fase de planificación a la de ejecución, es importante que esté preparado para cualquier objeción
• Cuando algo pasa de Sandbox a Producción – yo personalmente fijaré la fecha oficial de entrada en funcionamiento 1-2 semanas antes de eso.

Resumen

Este proceso es algo que me ha funcionado una y otra vez. Dependiendo de la solución que estés construyendo, puedes escoger los pasos que tengan más sentido para tu situación.

Si disfrutas de este contenido, no dudes en conectar conmigo en LinkedIn o visitar mi sitio web.