Una vez conocida, a nivel genérico, la funcionalidad de un CRM (Customer Relationship Management)… ¿Cuál es la mejor manera de modelar un software de gestión de relaciones con los clientes?
Antes de realizar personalizaciones o cualquier tipo de configuración en un CRM, en este caso Microsoft Dynamics 365, es necesario marcar pausada y detalladamente tres puntos:
Modelo de negocio
Se entiende por ‘modelo de negocio’ dentro de un ámbito de IT a la representación teórica de cómo funciona una empresa.
Por ejemplo, en una compañía de telefonía móvil, ¿qué ocurre desde que un cliente descontento por el servicio llama al departamento de Atención al Cliente hasta que le dan una respuesta o una solución? Si nos ponemos a pensar es ese instante en el que todo el mundo teme hablar con Atención al Cliente, seguro que se nos pasa por la cabeza qué datos nos han preguntado o por qué han tardado un poco en obtener una información que a nuestro parecer sería sencilla de conseguir.
Una llamada que no dura ni dos minutos, tiene por detrás una compleja red de procesos internos que el operador lleva a cabo a través de una interfaz. Esos procesos necesitan una información mínima para tipificar la incidencia y asignarla a un equipo específico. Y, a raíz de esa información, asignar los tiempos de SLA (Service Level Agreement) y la respuesta que se da en función a la resolución asignada.
Una vez hecha una pequeña introducción al termino de ‘modelo de negocio’ en IT, ¿por qué es importante definir bien algo así? La respuesta es sencilla, ya que a la hora de extrapolar un ‘modelo de negocio’ a un CRM si los procedimientos y los procesos no se definen bien tendremos un CRM que habrá costado tiempo, dinero y esfuerzo, y prácticamente no servirá para lo que debería.
Modelo de datos
Está estrechamente relacionado con el ‘modelo de negocio’, ya que para poder replicarlo satisfactoriamente será necesario crear nuevos campos, entidades y relaciones.
La definición del ‘modelo de datos’ es casi tan importante como la del ‘modelo de negocio’, ya que no es lo mismo que un cliente pueda tener solo un contacto o que una lista de productos solo pueda tener un producto. No solo en casos sencillos como los expuestos anteriormente es importante, sino que también es necesario saber cuándo será imprescindible una relación n:n entre dos entidades con una tabla intermedia o cuándo no será necesario.
Definir bien el ‘modelo de datos’ también es en sí la única manera de evitar la duplicidad de registros o prevenir el uso excesivo de un sistema de almacenamiento (servidores o almacenaje contratado en la nube).
Modelo de seguridad
Por último, pero no menos importante el ‘modelo de seguridad’, específicamente el de Microsoft Dynamics 365 for Sales, gestiona todo lo relacionado con los accesos a entidades, tipo de acceso de registros y visibilidad de estos.
Tomando el ejemplo de la empresa de telefonía móvil del primer punto, si en un país se ha segmentado de manera geográfica el ámbito de los equipos, el equipo de Vigo no debería poder acceder a los registros de incidencias de Castellón o en su defecto solo podría leerlos pero sin poder modificar ningún dato. También los usuarios del departamento de Marketing no deberían poder acceder a las entidades relacionadas con la gestión de Atención al Cliente.
En conclusión, para poder configurar un CRM es necesario, por no decir indispensable, tener en cuenta estos tres puntos y saber definirlos de manera eficiente.
Sergio Iñigo
Dynamics 365
[contact-form][contact-field label=»Nombre» type=»name» required=»true» /][contact-field label=»Correo electrónico» type=»email» required=»true» /][contact-field label=»Web» type=»url» /][contact-field label=»Mensaje» type=»textarea» /][/contact-form]