No construya, integre: una guía para la integración de CRM

Supongamos que está trabajando para una empresa emergente que vende robots en todas las industrias. Recibe pedidos de una variedad de clientes y un equipo de operaciones evalúa los pedidos y trabaja con proveedores externos para que sus clientes tengan el robot adecuado.

Construir el MVP fue estresante pero también muy divertido. Tus inversores están emocionados y te colman de dinero. Comienza la siguiente fase. Necesita más visibilidad sobre la rentabilidad y quiere adquirir clientes más grandes que necesitan una facturación más sofisticada. Al mismo tiempo, tiene una hoja de ruta de productos bastante sofisticada para habilitar las ventas de robots de mayor margen. Los recursos son escasos, pero aún debe asegurarse de que la empresa siga funcionando.

Como suele predicarse para las empresas más pequeñas, centrarse en las cosas en las que es bueno es una gran regla general. Pero, ¿qué pasa con todas las áreas que mantienen en funcionamiento las operaciones diarias de su empresa? Ciertamente no desea crear un sistema de gestión de relaciones con los clientes (CRM) o un sistema de contabilidad. Después de todo, existen muchos productos que resuelven todos los problemas. Pero, ¿cómo funcionarán estos sistemas junto con su sistema de pedidos existente?

Aquí es donde la integración de terceros es útil. Entonces, profundicemos y veamos si podemos evitar algunas trampas comunes.

Integración CRM

Ya sea que esté realizando ventas de bajo contacto (marketing de contenido, anuncios en redes sociales o boletines informativos) o ventas de alto contacto (llamadas en frío, asistencia a conferencias o seguimiento con clientes existentes por teléfono), un sistema de CRM puede brindarle una gran cantidad de visibilidad sobre cómo le está yendo con los clientes existentes y qué tan exitoso es para convencer a nuevos clientes.

A menudo, la selección de un sistema CRM se deja principalmente en manos del departamento de ventas y marketing. En general, no hay nada de malo en eso. Después de todo, estas personas saben mejor cómo aumentar los ingresos y necesitan el mejor soporte disponible. Pero incluso el mejor software no vale nada si no funciona correctamente junto con el sistema de pedidos de su robot.

Incluya a su departamento de tecnología en la decisión

Ya sea el CTO o un ingeniero dedicado, manténgalos informados desde el principio. Es muy probable que le den más información sobre cómo los dos sistemas funcionarán juntos en el futuro.

Y una palabra para los ingenieros: mantengan la mente abierta hacia las soluciones de terceros. Es fácil descartarlos porque su API no es la mejor o su interfaz de usuario es fea. Sin embargo, puede ser muy gratificante encontrar soluciones elegantes alrededor de los sistemas existentes.

Sin embargo, hay un par de temas que pueden ser beneficiosos para hablar antes de tomar una decisión. Temas generales como "¿Necesitamos esto en absoluto?" deben abordarse. Pero también es una buena idea tener ya una idea de cuál es el alcance. ¿Existe la necesidad de una sincronización bidireccional o el sistema de terceros simplemente seguirá el sistema de pedidos? Una vez que el alcance está fuera del camino, también debe haber una discusión técnica sobre los detalles de implementación, como los webhooks o la evaluación de los límites de la API.

¿Necesita una integración personalizada?

Cuando se trata de integración, no sorprende que ya existan plataformas que prometen resolver algunos de los problemas que probablemente encuentre. Actualmente, Zapier e IFTTT son los más prometedores.

Dependiendo del problema que intente resolver, es posible que su sistema de pedidos de robots ni siquiera esté involucrado en la integración. Digamos que está administrando los suscriptores de su boletín informativo con un sistema CRM como Salesforce o HubSpot y solo desea una forma más conveniente de comunicarse con ellos a través de un proveedor de servicios de correo electrónico como Mailchimp, Zapier tiene toneladas de integraciones existentes para ayudarlo con eso. A partir de este punto, elegir un proveedor que tenga un conector Zapier es un buen camino a seguir.

E incluso si se trata de integrar datos personalizados (robots pedidos y su precio), Zapier Webhooks puede actuar como intermediario para su integración.

Por otro lado, si ya estás enviando datos a un tercero, ¿por qué no enviarlos directamente al sistema CRM? Cuantos más datos desee sincronizar, más útil será una integración directa.

Lo que me lleva a mi siguiente punto.

¿Necesita sincronización bidireccional?

Por lo general, una integración comienza con un requisito simple como ¿Podemos hacer que todos nuestros clientes ingresen a nuestro sistema CRM? , normalmente combinado con los valores de pedidos de robots individuales, lo que facilita el uso de herramientas de segmentación de clientes.

Sin embargo, tarde o temprano, podría darse el caso de que las personas deseen utilizar las herramientas de gestión de contactos que normalmente ofrece una suite de CRM. Estos incluyen funciones como la deduplicación, la modificación de los datos de contacto con los datos de las redes sociales, la normalización de las direcciones de envío o simplemente la eliminación de contactos antiguos.

Cambiar los contactos en un sistema de CRM probablemente signifique que necesitará cambiar los detalles de contacto en otro sistema, es decir, los cambios deben realizarse en ambos sentidos.

El esfuerzo de implementación para esto va mucho más allá de una simple sincronización unidireccional, por lo que este es un excelente punto para pensar en cómo desea usar un nuevo sistema estratégicamente.

¿Cómo se le notificarán los cambios del CRM?

Si decide tener una sincronización bidireccional, hay una pregunta de seguimiento: ¿Cómo sabe que algo cambió en el lado de CRM?

La mayoría de los proveedores de sistemas tienen herramientas para esto, pero la mejor para cambios inmediatos son los webhooks, básicamente, un sistema de notificación HTTP que se puede configurar para informarle sobre cambios relevantes (para algunos sistemas, incluso campo por campo). .

Si el sistema no ofrece webhooks, al menos verifique si puede obtener una lista de todas las entidades que se han actualizado recientemente. De esta manera, no tiene que revisar todos los contactos y tratos solo para actualizar sus propios datos. Pero tenga en cuenta que deberá sondear el sistema a intervalos regulares.

En este caso, su sistema de pedidos aún cambiaría y crearía datos a través de una llamada API en el sistema CRM. Pero todos los cambios del sistema CRM se sondearían en un intervalo definido.

Lo que vale la pena señalar es que las actualizaciones se limitarán a este intervalo y pueden generar inconsistencias temporales en los datos. Por ejemplo, cuando solo sincroniza una vez al día desde su sistema CRM a su sistema de pedidos, los datos que está viendo en su sistema de pedidos pueden tener hasta 24 horas de antigüedad.

Dependiendo de las características que ofrezca el sistema, la tarea de integración puede variar en complejidad y tiempo de implementación. Asegúrese de verificar lo que ofrece el sistema con anticipación y verifique dos veces el plan que desea comprar. Por ejemplo, algunos sistemas de CRM ofrecen webhooks en los niveles mejor pagados.

Un ejemplo aquí es el CRM de HubSpot, que ofrece webhooks en general, pero la función de webhook solo está disponible en su paquete Enterprise. Las herramientas de contabilidad Zoho Books ofrecerán cinco flujos de trabajo automatizados (que incluyen webhooks) en su nivel más bajo.

¿Están sus datos en buen estado?

Cuando se trata de crear conjuntos de datos en un sistema externo, es bueno saber cómo se ven los datos en su propio sistema. Afortunadamente, no hay muchas formas diferentes de presentar contactos y tratos, pero un campo que siempre causa problemas es el campo de correo electrónico.

Diferentes sistemas tienen diferentes ideas de lo que es una dirección de correo electrónico válida, y aquí hay una alerta de spoiler: es posible que sus clientes le hayan proporcionado direcciones de correo electrónico no válidas de todo tipo. Muchos sistemas de CRM rechazarán la creación de un contacto con una dirección de correo electrónico no válida (y, por supuesto, el proveedor de CRM define qué es válido y qué no).

Sugerencia: si es posible, solo sincronice las direcciones de correo electrónico confirmadas con su CRM. Esto le ahorrará mucho dolor a largo plazo.

Limitaciones de la API

Por último, las limitaciones de la API son algo que debe abordarse lo antes posible.

Suponiendo que haya una API (que es básicamente imprescindible para cualquier integración), es beneficioso observar las limitaciones de la API. La mayoría de las nuevas empresas pueden hacer frente a los límites básicos de la API de la mayoría de los sistemas de CRM. Como ejemplo, HubSpot ofrece 250 000 llamadas API por período de 24 horas, incluso en su nivel gratuito. Por otro lado, también limita las llamadas a 10 por segundo (100 si usas OAuth). El líder del mercado, Salesforce, solo permite 100 000 cada 24 horas, pero ofrece comprar más.

La mayoría de las veces, caerá fácilmente dentro de esas limitaciones, pero hay una cosa a considerar: ¿Qué pasa con su ejecución inicial? Al principio, enviará muchos contactos y tratos a su CRM (y posiblemente varias veces si hay problemas). Como resultado, es posible que alcance el límite diario de API.

Para mitigar esto, puede probar con un pequeño conjunto de datos y aumentar lentamente el número a lo largo de la implementación para permanecer dentro del límite de la API. Para la migración inicial, planifíquela durante varios días o en un fin de semana. Alternativamente, comuníquese con el proveedor y hágale saber sus intenciones. Cuando esté en la fase de evaluación (y aún no haya pagado por el sistema), es posible que estén dispuestos a aumentar un poco su asignación de API.

Implementación de CRM

Digamos que están todos de acuerdo. Escogió una excelente herramienta de CRM y los ingenieros confían en que se puede integrar con bastante facilidad. Decidió definir su alcance solo para enviar datos de clientes y aceptar pedidos de robots. Por lo tanto, la sincronización bidireccional no es necesaria y los cambios de dirección solo se manejarán en su propio sistema de pedidos.

Todavía hay un par de mejores prácticas a seguir durante la fase de implementación.

Pruébelo todo en un entorno de prueba

En la mayoría de los casos, el sistema CRM solo se utilizará después de que su integración esté completa y lista para usar. Para este caso de uso, puede parecer atractivo usar solo el sistema de producción durante el desarrollo. Después de todo, no hay datos de producción que pueda estar afectando. Una vez que finalice el desarrollo, simplemente eliminará todos los datos de prueba que creó, ejecutará una migración inicial y apuntará su sistema de pedidos a este entorno.

Hay un par de problemas con este enfoque:

1. Solo estás pateando la lata por el camino. Incluso si su puesta en marcha transcurre sin problemas, tarde o temprano, habrá una solicitud de función para cambiar parte de su integración. Dado que la solicitud de función es lo suficientemente grande, probablemente necesitará otra fase de prueba. En este punto, es inevitable un sistema de prueba separado; de lo contrario, podría terminar estropeando los datos de producción. Entonces, ¿por qué esperar con la configuración hasta que se le solicite implementar la primera función?

   

2. Terminas con una configuración desordenada. Es muy probable que su sistema CRM necesite algún tipo de configuración que se adapte a las necesidades de su sistema de pedidos. Es posible que sea necesario ajustar los nombres de los estados, por lo general es necesario crear campos personalizados, etc. Como la mayoría de los desarrolladores necesitarán acostumbrarse al sistema CRM, se agregará una configuración que no será necesaria a largo plazo. En realidad, esta configuración no utilizada no se elimina más tarde e incluso puede permanecer en su CRM para siempre. Al forzar el paso adicional de replicar la configuración del sistema de prueba a la producción, lo más probable es que termine con una configuración más delgada en su sistema de producción.
   
   Cabe señalar que esto también puede jugar en su contra si olvida copiar la configuración de su prueba a su sistema de producción, y terminará con errores de producción.
   
   Si bien existen algunos sistemas de CRM que lo ayudarán a comparar y copiar elementos de configuración, en general, será útil anotar sus configuraciones para no olvidar los elementos cruciales. La mayoría de los CRM proporcionan una API para su configuración, por lo que es posible automatizar este paso.

3. Corre un mayor riesgo de contaminar los datos de producción. Imagine por un segundo a dos desarrolladores trabajando en una integración. Ya tiene un sistema de preparación del sistema de pedidos del robot. Esta puesta en escena también está conectada a su CRM. Una vez que se envíe su integración, deberá recordar desconectar los tres sistemas o, de lo contrario, podría terminar creando datos de prueba en su (ahora) CRM de producción.

Todos estos problemas se pueden evitar desarrollando contra un sistema de prueba desde el principio. La producción solo se presenta al final, justo antes de que todo salga a la luz. De esta manera, terminará con una configuración limpia, no correrá el riesgo de olvidarse de desconectar los sistemas locales y tendrá un aviso cuando implemente nuevas funciones.

Definir ID para entidades coincidentes

Ahora, comencemos a escribir el código de integración real. Tomemos el ejemplo de sincronizar contactos con un sistema CRM. Presumiblemente, deberá crear nuevos contactos y actualizar los contactos existentes. Para distinguir una creación de una actualización, debe vincular las dos entidades. De esa forma, puede verificar si el contacto en su sistema existe en el sistema externo.

Si bien parece atractivo usar solo la dirección de correo electrónico (después de todo, es un identificador común para un registro de contacto), existe una solución más general: para cada registro, se sincroniza con una retención e identificación del sistema externo en su propia base de datos.

Por lo tanto, modifique su tabla de contactos con una columna llamada crm_id o external_id . Este enfoque tiene un par de ventajas:

• Debido a que es una identificación, no cambiará (a diferencia de una dirección de correo electrónico o un número de teléfono).
• Puede ver si necesita crear o actualizar la entidad sin hacer primero una llamada a la API (si el campo de identificación externa está vacío, puede suponer que el contacto no existe).

Antes:

Después:

Por ejemplo, supongamos que eres un desarrollador de Ruby on Rails que trabaja en una aplicación que necesita sincronizar clientes nuevos y existentes con HubSpot.

Un ejemplo de código simplificado podría verse así:

 class HubspotSync def sync(customer) hubspot_return = if customer.hubspot_id.present? update(customer, customer.hubspot_id) else create(customer) end customer.update(hubspot_id: hubspot_return['companyId']) end private def create(customer) response = HTTParpty.post("https://api.hubapi.com/companies/v2/companies", map(company)) handle_response(response) end def update(customer, hubspot_id) response = HTTParpty.put("https://api.hubapi.com/companies/v2/companies/#{hubspot_id}", map(company)) handle_response(response) end def handle_response(response) raise RuntimeError, "Unexpected Status code: #{response.code}" if response.code >= 500 JSON.parse(response.body) end def map(company) # mapping code goes here { properties: [ name: 'name', value: company.name ] } end end

Observe cómo aprovechamos guardar el companyId . de empresa que se devuelve desde HubSpot. No solo nos ayuda a determinar si queremos actualizar o crear una empresa en HubSpot, sino que también podemos ver en la tabla de la base de datos qué entidades ya están sincronizadas con HubSpot y cuáles aún faltan.

Cuando se trata de mapear campos, vaya al estilo libre

He visto proyectos en los que la implementación está precedida por la creación de una hoja de cálculo gigante de Excel que define qué columnas van a dónde en el sistema CRM, con anotaciones de cómo se deben transformar los datos.

En realidad, solo hay algunas formas de representar contactos y tratos. Entonces, en lugar de pasar mucho tiempo pensando en cómo quiere mapear exactamente, ¿por qué no comenzar con un experimento? Dé al desarrollador algo de espacio para descubrir el mapeo, pero también manténgase en contacto para que puedan surgir preguntas temprano.

Al menos para los campos generales de contacto (nombre, dirección de correo electrónico, número de teléfono, dirección), el mapeo será muy simple y las transformaciones suelen ser triviales.

Cuando se trata del mapeo de estado para tratos, es útil un poco más de comunicación (a veces, el primer estado se llama open , a veces new y, a veces, el modelo de estado no coincide al 100%, por lo que tendrá que agrupar estados juntos ). En lugar de encontrar la solución perfecta, mire sus datos actuales y vea cómo encajarían mejor en el modelo de datos del CRM. Después de todo, eres una empresa ágil, ¿verdad?

En el ejemplo anterior, puedes ver un método de mapa que convierte nuestro modelo de Rails en un hash regular que HubSpot entiende. Para este caso de uso particular, el único elemento sincronizado es el nombre. Para un uso más avanzado, probablemente desee incluir más campos, pero para obtener un gran resultado, comience con una suposición informada y comuníquese con el lado comercial a menudo para conocer los detalles.

Considerar reintentos

Bajemos al nivel más técnico: implementar la sincronización real entre su sistema y el CRM. Es casi un hecho que la integración se realizará a través de una conexión HTTP. La mayoría de los sistemas proporcionan una API HTTP y todos los lenguajes de programación le permitirán realizar llamadas HTTP muy fácilmente.

Desafortunadamente, no importa cuánto dinero gaste en un sistema CRM, eventualmente no será accesible. Esto sucederá en algún momento y no hay nada que puedas hacer al respecto. Por lo tanto, también podría tener esto en cuenta cuando esté desarrollando su integración.

Lo que esto significa en la práctica es: cada vez que llame a una API, asegúrese de que su llamada se vuelva a intentar en caso de un problema (código de estado 500 del otro lado). La implementación de reintentos es algo que generalmente proporcionan las bibliotecas de terceros del idioma de su elección.

Además de volver a intentarlo, es posible que desee considerar registrar lo que sucedió exactamente. Recibir una notificación sobre un error que ya se solucionó en el primer reintento puede ser frustrante.

Entonces, en lugar de enviar spam a su canal de error con problemas resueltos, registre todas las llamadas con la cantidad de reintentos para tener una idea de cuán confiable es el sistema, un sistema por el que acaba de pagar mucho dinero.

Si tomamos la clase que creamos como ejemplo y nos mantenemos en el contexto de Ruby on Rails, podemos simplemente envolver la llamada en un ActiveJob y estar bastante seguros de que finalmente tendrá éxito. El método handle_response generará un error en caso de un código de estado inesperado y ActiveJob intentará volver a intentarlo con un retroceso exponencial. Para una solución más avanzada, también debe considerar los códigos de estado 4xx para evitar un reintento y, en su lugar, se genera un mensaje de error.

 class HubspotSyncJob < ApplicationJob def perform(customer) HubspotSync.new.sync(customer) end End

Asegúrese de que el sistema se utilice realmente

Bien, supongamos que lo envió todo. Estás muy orgulloso de tu trabajo y el sistema se activa. ¿Ahora que? Este es solo el comienzo. Porque no importa cuántas pruebas estés haciendo, siempre habrá errores y cambios solicitados.

El problema es que no se enterará de esto a menos que realmente use su sistema. Y esto sucede por todo tipo de razones: el departamento de ventas actualmente está demasiado ocupado para comenzar a usarlo, la estrategia cambió o incluso ya se están evaluando nuevos sistemas.

Por lo tanto, para evitar posibles problemas a largo plazo, asegúrese de haber eliminado todos los obstáculos que impedían el uso del sistema en producción. Comuníquese con frecuencia entre los equipos para alinear los nuevos requisitos. Y si descubre que el sistema simplemente no va a funcionar para usted, apague la integración. Suena duro y puede resultar muy frustrante, pero es menos frustrante que tener que solucionar siempre los problemas de inconsistencia de los datos y solucionar los problemas.

Terminando

Al final, un proyecto de integración es un gran proyecto, y hay muchas cosas que pueden salir mal. No es muy popular entre los ingenieros por varias razones, pero puede ser gratificante ver que una implementación tiene un impacto positivo en la productividad de las personas que se sientan a su lado.

Entonces, para los ingenieros, intente comprender las necesidades de un sistema externo, como un CRM o un sistema de facturación, haciendo preguntas concretas como: ¿Cómo hará este producto su vida más fácil? ¿Has considerado competidores? ¿Por qué no funcionan?

Para todos los demás involucrados: involucre a los ingenieros lo antes posible, confíe en ellos cuando señalen líneas rojas y no opte por un plan barato cuando pueda ver que la implementación de la integración hará que sea mucho más difícil en el futuro. largo plazo.