El Plan de Cuentas

La planificación de cuentas es una de las tareas centrales de la gestión de clientes en un departamento de ventas que busque ser calificado como profesional. Consiste básicamente en el análisis de los diferentes elementos que afectan las decisiones de compra de cada cliente de una organización (o al menos de aquellos más importantes), con el fin de elaborar planes personalizados y detallados sobre la forma en que cada uno de ellos debe ser abordado.

Aun cuando la figura del “Key Account Manager”, parece estar muy de moda en la actualidad (protagonista principal en la planificación de cuentas), la realidad es que es un concepto utilizado de forma pionera desde hace algunas décadas por empresas como IBM. Desde entonces, dferentes empresas consultoras han introducido sus propias metodologías, denominándolas de las más varias maneras: “Target Account Selling”, “Strategic Selling”, etc.

La verdad es que no existe una única manera de desarrollar un Plan de Cuentas, sin embargo, desde mi punto de vista, existen ciertos elementos que deberían encontrarse siempre:

1. La Valoración de la Cuenta: El desarrollo de un plan de cuentas es una tarea que consume tiempo y esfuerzo, por lo que, con toda seguridad, no todos los clientes activos o potenciales ameritan que se les dedique esta dedicación. La mejor manera de definir las cuentas para las que se desarrollará un plan, es mediante la realización de una valoración que puede estar basada tanto en variables cuantitativas (facturación de la empresa, potencial de compra, etc.), como en variables cualitativas (prestigio aportado, referencias claves, etc.).

2. Los Objetivos del Plan: Basándose en la valoración y el potencial de compra del cliente, se elaboran los objetivos cuantitativos y cualitativos del periodo de venta que cubrirá el plan. Estos objetivos pueden ser de incremento en volumen de ventas, en precios, ventas cruzadas, etc., refriéndonos en términos económicos o mejoramiento del nivel de satisfacción, entre otros, si hablamos en términos cualitativos.

3. Los contactos principales del cliente y el “mapa de interlocutores”: Es necesario reconocer quienes son los contactos que toman las decisiones de compra dentro del cliente y quienes pueden ser influenciadotes en dichas decisiones, para posteriormente intentar identificar a las personas dentro (o fuera) de nuestra organización que puedan facilitarnos el acceso a ellos.

Adicionalmente es interesante conocer por cada contacto del cliente, cuales son sus motivaciones principales.

4. La competencia: conocer qué competidores hacen o intentan hacer negocios en un cliente (activo o potencial) y cuál es su propio mapa de contactos es fundamental para determinar las oportunidades o amenazas que se presentan, basándose en las fortalezas y debilidades propias.

5. La “Proposición de Valor”: con base en los puntos anteriores, debe elaborarse un mensaje de ventas adecuado, que muestre claramente las necesidades del cliente y la forma como nuestra organización le ayuda a cubrirlas (venta consultiva). Este mensaje puede ser matizado de diferentes maneras, dependiendo quien sea el interlocutor del cliente en cada momento, pero siempre manteniendo un fondo coherente. Siempre es bueno presentar al menos dos (mejor tres) alternativas en cada negociación. La buena, que encaja en el presupuesto, la muy buena y la mejor.

6. El “Plan de Seguimiento del Cliente”: Debe establecerse un plan de visitas y llamadas periódicas con cada una de las personas claves del cliente, utilizando en cada caso el interlocutor adecuado de nuestra organización.
Siempre deben dejarse registrados los logros alcanzados y las posibles oportunidades de negocio que puedan surgir, para definir las próximas acciones.

Entre otras cosas, la implantación de una metodología de ventas que incluya la utilización del Plan de Cuentas, ayuda en gran medida a reducir la anarquía natural en la que viven los departamentos de venta, pero exige incrementar el nivel profesional de los vendedores (o gestores de cuentas) y un gran esfuerzo para vencer la reticencia general que tiene este colectivo a cualquier proceso, sistema o herramienta que pueda “oler” a control. A cambio ofrece una mayor visibilidad sobre los clientes más rentables o importantes de la organización, facilitando un incremento del volumen y margen de venta.

El CRM en la Administración Pública

Recientemente he recibido una pregunta de Alberto Ortiz, asociada a mi primer artículo: ¿Por qué una empresa debe implantar un CRM?. Me pregunta sobre el CRM en la Administración Pública. Lamentablemente no he tenido la oportunidad de participar en ningún proyecto de gestión de clientes en el sector público, pero en el fondo, considero que el concepto fundamental del CRM no varía, independientemente de donde sea implantado.

Cualquier organización, ya sea una ONG, una empresa o un organismo de la administración pública tiene como objetivo cubrir las necesidades de un grupo específico de clientes, la diferencia quizás es qué, en unos casos el fin perseguido es obtener una rentabilidad económica a través del cubrimiento de dichas necesidades y en otras, los objetivos finales son de diferente índole.

Si nos centramos en el caso del sector público, desde mi punto de vista, el objetivo de un CRM debe centrarse en una atención más eficiente del ciudadano, facilitándole la interacción mediante múltiples canales de contacto. Una diferencia relevante en este caso, en relación al CRM en el sector privado, es que no debe ser utilizado como una herramienta de segmentación de los clientes (tratar a cada cliente según su potencial económico ante la organización), ya que en principio, todos somos ciudadanos con iguales derechos y deberes. Otro punto diferenciador sería la forma en la cual se calcularía el ROI (aun cuando en otro artículo ya comenté sobre la dificultad que implica este cálculo en el sector privado), ya que como es obvio, no es incremento de ventas lo que se espera de su implantación. Digamos que lo que se busca es un mejoramiento de la imagen mediante la prestación de servicios más eficientes y más accesibles.

Desde el punto de vista de gestión de un proyecto de implantación de una herramienta de CRM en el sector público, puedo ver claramente diferencias importantes. En primer lugar, mejor o peor, en el mundo empresarial cada persona que trabaja en una organización sabe que el objetivo final de su trabajo es que la empresa venda más y con mejores márgenes, por lo que el concepto de cliente (“alguien que compra”) es más o menos conocido. Se sabe que es necesario atraerlos y conseguir satisfacer sus necesidades, ya que en caso contrario, “el puesto de trabajo está en juego”. Esto, por supuesto, ofrece en cierta medida alguna predisposición a aceptar un cambio en las reglas del juego, con el fin de conseguir dicho objetivo.

Por el contrario, en el sector público, el concepto de cliente es algo más vago (¿quién piensa en el ciudadano como un cliente?), adicionalmente no hay objetivos de rentabilidad y no se utilizan métricas para evaluar a los funcionarios (en toda la jerarquía organizacional) en relación al grado de satisfacción de las personas a las que atienden. Adicionalmente, el puesto de trabajo nunca está en juego. Todo esto conlleva a que cualquier implantación de un CRM en este sector, supone un enorme esfuerzo en formación, culturización y gestión del cambio con resultados que seguramente no se obtendrán en el corto plazo.

Algunos problemas adicionales, pero ahora a nivel tecnológico, son la complejidad de los sistemas relacionados y su integración, el inmenso volumen de datos que deben ser gestionados, la calidad, así como el énfasis que es necesario hacer en la protección de los mismos.

Como nota final, puedo dar fe que en algunos organismos de la administración pública el concepto de CRM es utilizado (aun cuando no se a qué coste). No hace mucho recibí una carta recordándome que mi hijo estaba en la edad en la que le debían ser administradas su siguiente grupo de vacunas. Claramente, para mí, esto es un valor añadido que me ofrece el organismo responsable de estos temas.

¿Cuál es el modelo de desarrollo adecuado para un CRM?

No puede haber una respuesta exacta a esta pregunta, ya que la selección del modelo de desarrollo debe basarse en las circunstancias específicas de cada proyecto, sin embargo, desde mi experiencia profesional, tiendo a favorecer los modelos evolutivos, por contra de los modelos en cascada. Estos últimos se basan en la premisa de que se pasa de cada estadio del desarrollo al siguiente una vez cumplidos ciertos hitos preestablecidos. La dificultad que presentan estos modelos consisten en la imposibilidad práctica de obtener las especificaciones integras del proyecto desde el principio (e incluso en cada una de sus fases), con el fin de establecer claramente dichos hitos. Creo que todos hemos vivido situaciones en las que los mismos usuarios no están conscientes de lo que quieren, sobre todo cuando estamos hablando de las áreas menos procedimentadas y más dinámicas de la empresa, como son las de marketing y ventas.
Ciertamente, tal como se muestra en el gráfico anexo, un modelo en cascada no impide realizar pasos atrás para corregir errores generados en etapas anteriores, el problema principal, desde mi punto de vista, es que gran parte de los errores de diseño o técnicos suelen descubrirse en las etapas finales de construcción y pruebas, justo cuando es más costosa su corrección. Adicionalmente este modelo suele requerir el desarrollo de una gran cantidad de documentación que normalmente se queda obsoleta con mucha rapidez, ya que los cambios o correcciones realizados en las etapas finales pocas veces son realmente actualizados en la documentación generada de las etapas previas. A pesar de los expuesto anteriormente, este uno de los modelos más utilizados por las grandes consultoras, ya que se adecua mejor a su esquema de jerarquía organizativa (Consultores – Analístas – Programadores), en la cual, los primeras etapas del desarrollo (desde la definición de alcances hasta el diseño técnico) es encargado a los niveles más altos de la jerarquía, dejando lo referente a la construcción en manos de los niveles más bajos y por lo general menos experimentados. Este esquema de por si no es malo, solo que se ve afectado por el uso de personas sin suficiente experiencia, que no saben o no pueden asumir los errores u omisiones proveniente de etapas anteriores.

Tal como comenté al principio, sobre todo en el caso de implantaciones de paquetes comerciales (dígase Siebel, SAP CRM u otro), apuesto por un modelo de desarrollo en espiral, basado en prototipos o entregas parciales, en las cuales se define al inicio lo que debería ser el corazón del sistema y los alcances generales del mismo, realizándose un desarrollo por etapas, en la cual cada etapa por si misma se gestiona como si fuese un mini-proyecto que se va enriqueciendo con la aportación de las etapas subsiguientes. Las ventajas de este modelo consisten principalmente en otorgar visibilidad a los usuarios, desde los primeros momentos del proyecto, de lo que será una aproximación al resultado final esperado, evitando sorpresas de última hora o errores de interpretación. Adicionalmente, les permite digerir con mayor facilidad un conjunto reducido de funcionalidades a la vez. Por otro lado, el nivel de experticia requerido de los consultores suele ser mayor, pero el tamaño general del equipo de proyectos se reduce. Cada desarrollador asume más de una función, ya que no existe una separación explícitamente marcada entre las etapas de análisis, diseño, construcción y pruebas.
Por el contrario, este modelo exige un esfuerzo mayor en la gestión de los alcances del proyecto, debido a que no requiere que todos los puntos estén cerrados antes de iniciar el desarrollo, lo cual puede ser un arma de doble filo si no se controlan minuciosamente los riesgos asociados.