El Data Base Marketing encierra una serie de procesos y recursos afectados a mejorar un negocio, a partir de la acción conjunta y coordinada en tres campos:
- La incorporación de más clientes activos al menor costo posible.
- El incremento de la rentabilidad de cada cliente existente.
- La retención más efectiva de los clientes.
En otras palabras, esto significa que:
- Las acciones comerciales deben perseguir la mayor cantidad de contactos con prospects posible por cada peso gastado, y la selección de los mejores prospects para la oferta disponible.
- Los productos deben ser diseñados para aprovechar mejor los hábitos de consumo de nuestros clientes, incrementando el cross selling, además.
- La acción comercial va más allá de la venta, para conocer y prevenir las conductas que desembocan en la deserción.
El logro de estos objetivos depende del conocimiento que podamos alcanzar de cada uno de nuestros clientes. Para lo cual es necesario saber cómo fue su relación histórica con nuestra empresa desde que fue un
prospect , hasta que nos abandonó, si es que no pudimos evitarlo. Esto nos lleva a diseñar repositorios de información (bases de datos), para conservar toda la historia que soportará nuestras estrategias futuras, y aprovechar las tecnologías actuales para estudiar esa información, definir objetivos, planificar acciones y administrarlas convenientemente.
Pero en lugar de desarrollar el modelo teórico de cómo son, o deben ser, los procesos de Data Base Marketing, veamos mejor cómo se evoluciona en ellos a partir de algunos casos concretos de nuestra experiencia en el tema.
Más clientes al menor costo: Normalmente un proceso de Data Base Marketing comienza cuando las empresas que hacen campañas masivas quieren mejorar la productividad de sus canales. A través de diagnósticos de calidad en las bases de datos, hemos encontrado que:
- Existe una gran desactualización de los datos indispensables para establecer los contactos. En promedio, entre el 30 y 40 % de los teléfonos y las direcciones son incorrectos. Esto hace que el costo por contacto efectivo esté lejos del óptimo.
- Las bases, o segmentos de bases, son heterogéneos. Normalmente se ofrece el mismo producto a toda la base, o segmento, sin determinar previamente los atributos de los prospects que definen si esos contactos son proclives o no a la compra. Por tanto, la cantidad de ventas por contacto efectivo también dista de ser la mejor.
- La cantidad de intentos de contacto se realiza de acuerdo a criterios diversos, que no consideran la mejor relación entre las curvas de probabilidad de contacto en función del número de intentos, y el costo insumido por cada intento. Ej: Un telemarketer puede intentar dos veces y desistir, otro intentará cinco, etc. En el mejor de los casos, el supervisor determinará, basado en su experiencia subjetiva, una cantidad de intentos dados, e indicará el comportamiento a seguir. Pero ¿Es la solución óptima?
- En el caso particular del telemarketing, la heterogeneidad de las bases también reduce el hit rate en relación con los horarios de mayor probabilidad de contacto para cada tipo de prospect. Por ejemplo, los números laborales y los de hogares deberían determinar distintos horarios de abordaje.
En estos casos, hemos tenido muy buenos resultados sin hacer más que realizar campañas de test del comportamiento de cada base o segmento a explotar, determinando la tasa de contactos, la curva de respuesta en función del número de intentos, los horarios de mayor rendimiento de contactos, los atributos que definen la proclividad a la compra, etc. Con muestras del orden de los 400 datos, se ha logrado duplicar, como mínimo, la tasa de contactos por intento y ventas por contacto. En otros casos, hemos podido descartar el uso de una base, o segmento, antes de incurrir en costos mayores.
Clientes más rentables. Cuando el cliente ya se ha ganado, y comienza a operar con nuestro servicio, o consumir nuestros productos, nos damos cuenta de que la información transaccional que dispone la base operativa permite facturar, distribuir, enviar resúmenes de cuenta, etc. Pero es insuficiente para relacionar la rentabilidad de cada cliente con otros datos sociales, económicos, culturales, familiares, laborales, históricos de la relación, que definen cada tipo de comportamiento. Es decir, no se tiene la posibilidad de dirigir nuestros productos a prospects con las mismas características que los actuales más rentables, o pensar en productos más adecuados a cada segmento.
Esta es una situación que se ha vivido en todos los proyectos en los que hemos participado, y ocurre porque las bases de datos operativas están diseñadas con ese fin exclusivo. Más aún, normalmente, están desactualizadas (como se dijo más arriba) en los datos que interesan comercialmente, porque no son relevantes para operar. Si el cliente opera sin inconvenientes, no parece importante saber si ha cambiado su estado social, familiar, económico, o si se mudó y ya no recibe el resumen de cuenta, etc. La necesidad de corregir esa situación lleva al diseño de repositorios de información (Data Marts) con un modelo de datos específico para la explotación comercial. Este aspecto se convierte en el núcleo de cada proyecto, y define el potencial comercial futuro del sistema. Veamos algunos ejemplos:
En una compañía de servicios financieros, el modelo relacional de datos debe reflejar la situación sociográfica mencionada más arriba con la mayor precisión posible, incluyendo las vinculaciones familiares de clientes aparentemente distintos (desde la venta, o desde la evaluación de riesgos, esta es una información importante). Los productos que posee cada cliente formarán parte del modelo, así como el detalle de todas las características de contratación. A su vez, cada producto deberá relacionarse con las tablas de datos que describen el comportamiento transaccional de cada cliente con ese producto.
Así se podrán relacionar, por ejemplo, todos los clientes que, para un producto dado, han tenido un saldo promedio creciente durante los últimos seis meses, con el ingreso de todo el grupo familiar.
Hasta aquí, vemos que el modelo de datos de esta compañía requerirá la actualización periódica de las tablas que reflejan el comportamiento transaccional a través de un refresco batch periódico del modelo comercial. En general, un caso simple como este no requiere actualizaciones on-line desde la base operativa a la base de marketing.
Adicionalmente, esta compañía necesitará registrar las acciones comerciales realizadas sobre sus clientes y prospects (provenientes de otros orígenes), y sus resultados, así como los canales a través de los cuales se ejecutaron dichas acciones. Normalmente, se deberá diseñar una tabla de contactos para cada canal, puesto que, al ser distintas las mecánicas de cada uno de ellos y de los resultados registrables, también serán distintas las estructuras de datos. De esta manera se podrá determinar cuáles son los canales, o combinación secuencial de canales, más exitosos para determinadas acciones sobre segmentos específicos.
Para el caso que tratamos, por ejemplo, se encontró que una secuencia efectiva consistía en generar un primer estímulo a través del correo postal, confirmando el interés de los clientes, luego de diez días, con un contacto telefónico y concretando, en ese acto, una cita en la sucursal más cercana.
Obviamente, la coordinación de los canales es un factor clave en la explotación de las bases de marketing para reproducir las secuencias más convenientes con precisión.
Concluido el diseño, e implementado sobre una plataforma dada, esta base debe ser
llenada con los datos existentes de los clientes actuales, que deben provenir, obviamente, de la base operativa de la Compañía. Allí chocamos con los problemas mencionados más arriba, acerca de la calidad de la información de estas bases. No debemos comenzar la explotación comercial de una base que contiene datos cuya confiabilidad es desconocida, o lo que es peor, que tiene campos vacíos o escritos con el formato del data entry de turno. Si bien la esencia de nuestra tarea no pasa por el desarrollo de sistemas, nos hemos visto obligados a desarrollar algoritmos y programas que respondieran a nuestro concepto de
medir el valor de cada información en términos de probabilidad de certeza (confiabilidad), y generar la capacidad de procesar bases de nuestros clientes para:
- Normatizar: Hacer que todos los campos de información homólogos, no importa de que base provengan, tengan un formato único. Por ejemplo, todos los nombres se escribirán con el mismo formato, y lo mismo ocurrirá con las direcciones, números telefónicos, etc. Este proceso debe incluir controles de inconsistencia tales como verificar la coherencia entre las localidades y los códigos postales y DDN, etc. El hecho de normatizar no nos dice si la información normatizada es correcta o no, salvo a través de las inconsistencias.
- Calificar: Esto es asignar, mediante algoritmos de control automático, una probabilidad de certeza a cada campo para: Detectar la necesidad de verificar o actualizar datos por otros medios. Es decir, separar buenos de malos. Poder ponderar, a priori, el hit rate de futuras campañas. Es decir, elegir los segmentos a direccionar considerando también la confiabilidad del vínculo de contacto que se utilizará.
- Enriquecer: Consiste en completar los campos incompletos, corregir los campos inconsistentes, y verificar o corregir aquellos de baja confiabilidad.
- Deduplicar: Es detectar a los clientes presentes en más de un lugar de la misma base, o en distintas bases; y traducirlos a un único registro de la base final.
Para tener una idea de qué puede esperarse de estos procesos, debemos decir que un proceso de normatización automático da como resultado entre el 65% y el 75% de la base original sin intervención humana. La fracción restante, deberá depurarse por otros medios semiautomáticos o manuales. Un proceso de calificación automática arroja, para las bases de nuestro medio, entre 50% y 70% de datos confiables, incluyendo aquellos que han sido enriquecidos automáticamente por el mismo proceso, separando al residuo que deberá enriquecerse por otro método.
Para la mayoría de los casos, el modelo de datos de esta compañía no está completo aún. Falta considerar los
otros contactos , tales como las consultas, quejas, reclamos, etc. No deberíamos, por ejemplo, realizar nuevas ofertas a clientes que aún están irritados por algún error reciente de nuestra parte. En cambio, sí podrá interesarnos realizar alguna acción prevista para atenuar el impacto de ese error. Lo mismo ocurre con las consultas más frecuentes, que ponen de manifiesto falencias en nuestros mecanismos de información a los clientes. No podremos mejorar esos mecanismos sin tener la historia...
Como se ve, si bien la base de datos de marketing es el núcleo informático, la planificación de todo lo que se va a hacer con esa información es, en si misma, toda una tarea de diseño que define la intimidad del modelo de datos a utilizar.
Cuando el volumen de contactos que se produce por uno o más canales (customer care, telemarketing, la web, etc.) es importante, se utilizan herramientas informáticas de administración de contactos para asegurar el registro, orden y productividad de esos procesos. Luego, será necesario diseñar interfases entre nuestra base de datos y estos aplicativos, para tener el registro completo de todos los contactos y sus resultados, o bien seleccionar aplicativos que puedan compartir un único modelo de datos, y que este, a su vez, pueda
modelarse según nuestro diseño. De acuerdo a nuestra experiencia, esta última es la solución más recomendable, por su escalabilidad.
A esta cuestión se le agrega un grado de complejidad más cuando la base de datos es el producto de las bases operativas de un grupo de empresas que se asocian en un proyecto común, orientado fuertemente al cross selling entre sus respectivos clientes y productos. Para estos casos, las estructuras de datos da cada una de las bases se
funden en un modelo único de datos, cuyo diseño tiene una complejidad bastante mayor que en el caso de las bases
monoempresa . Esta complejidad reside en hacer que convivan las informaciones transaccionales de distintos productos o servicios de un modo tal que sinergice nuestra capacidad de conocer a cada cliente.
De hecho, nuestra experiencia nos indica que la base resultante es incomparablemente más valiosa, desde el ángulo comercial, que cualquiera de las bases de origen. Y esto no se debe solamente a la suma de los datos, sino también al concepto del diseño. Mientras los repositorios operativos están diseñados para almacenar transacciones asociadas a clientes en grandes tablas de información, la base unificada debe ser pensada con el foco en el cliente, y en cómo este cliente se relaciona con los distintos productos o servicios (de las distintas empresas) y, finalmente, cómo transacciona con ellos. Este concepto permite una mayor capacidad de análisis en el momento de identificar los atributos de los clientes que definen (se correlacionan) su comportamiento transaccional. Esto último es lo que se conoce como minería de datos, o
mining , y toma una relevancia enorme en proyectos de esta complejidad.
El
mining tradicional del marketing se basaba en un proceso recurrente de
infererir y comprobar . Es decir, suponemos que determinados atributos están asociados a ciertas conductas, y luego comprobamos a través de
queries sobre la base, y cálculos estadísticos, dicha suposición.
En el
mining moderno juega la tecnología, a través de programas informáticos que buscan (y encuentran), dichas relaciones a través de complejos algoritmos matemáticos. El resultado es el
descubrimiento de relaciones cuantitativas que podían haber sido intuidas, algunas; y otras que jamás hubiéramos sospechado. Los algoritmos de
mining que utilizan estos programas son variados, y merecerán un capítulo específico.
A esta altura, las campañas de test mencionadas al comienzo siguen siendo válidas, pero con un proceso más elaborado. Si partimos de cero en el conocimiento de nuestros clientes, y queremos comercializar un producto, podemos hacer una campaña de test sobre una muestra heterogénea de nuestra base y registrar los resultados:
Compró ,
no le interesa por ahora ,
no le interesa el producto en lo más mínimo, etc. Luego, podemos hacer
mining con el método que tengamos
a mano para determinar cuáles son los atributos de nuestros clientes que se correlacionan con los resultados obtenidos, y a partir de allí especificar distintos segmentos de clientes:
- Al que direccionaremos la próxima campaña.
- Al que seguiremos testeando en campañas futuras.
- El que no será considerado en la próxima campaña, etc.
Con campañas de test-mining como la descripta, el resultado en términos de venta/contacto es tres, cuatro, cinco, o aun más veces mejor que con las campañas tradicionales
al bulto (dependiendo de la calidad estadística del
mining ).
Hasta aquí hemos tratado experiencias en las que las bases de datos de marketing se nutren de información de las bases transaccionales, pero funcionan aisladamente de aquellas. Se usan solamente con fines comerciales. Existen casos en los que se descubre la posibilidad (y la conveniencia) de complementar la utilización de la base de marketing con la transaccional y con los sistemas administradores de contactos de cada canal comercial para obtener un sistema CRM integrado; donde la prospección, las campañas de venta, los procesos de servicio, el upselling, etc., son componentes de un proceso sin fronteras.
Un caso típico son los servicios que se operan través de Internet, por ejemplo, pero se comercializan por diversos canales (fuerza de ventas, telemarketing, mailing, la web, etc.). Una operación de este tipo, suele (debe) incluir también procesos de customer care que se canalizan a través de e-mail o telefonía, y que son de doble vía:
- Reactivas: a través de requerimientos del cliente que deben ser satisfechos.
- Proactivas: a través de acciones de información, enseñanza y de estímulo por parte de la empresa.
Un proyecto de Data Base Marketing (DBM) de esta naturaleza alcanza otra dimensión, donde la base de datos debe ser diseñada considerando, además de lo anterior, todos los eventos de contacto posibles con los clientes (proactivos y reactivos) a lo largo de su relación con la empresa, y la planificación de las acciones que derivarán de esos contactos. Si un prospect pidió información por vía telefónica, averiguaremos si tiene e-mail, para enviársela, de lo contrario lo haremos por vía postal. Luego de un tiempo, le enviaremos un e-mail de estímulo, o lo llamaremos vía telefónica, según haya sido el resultado del primer contacto. Una vez que compre nuestro servicio, supervisaremos su actividad transaccional, resolviendo los problemas que nos plantee a través de procesos definidos, y ejerceremos contactos planificados a partir de su historia operativa, etc., etc...
Todas estas acciones estarán codificadas en flows o diagramas de estados en los sistemas administradores de contacto, los que deberán decidir qué se hace, en cada caso, a partir de la historia de ese prospect o cliente. La historia de los contactos será parte de la información transaccional del cliente y residirá en la estructura de datos de la base. Esa información, dispuesta en
tablas transaccionales de contacto , se complementará con las tablas transaccionales operativas en la toma de decisiones. Si estas tablas de contacto nos dicen que un cliente ingresa con cierta frecuencia a nuestra página en la web para consultar cierta información, podremos
ordenarle al administrador de contactos de customer care que a los clientes que muestren ese comportamiento se les envíe, en forma automática, un e-mail periódico con la información requerida.
A primera vista, una descripción de este tipo parece plantear un mundo ideal con complejidades infinitas de concreción. Sin embargo, se ha hecho y funciona. Requiere un esfuerzo de análisis, planificación y replanificación permanente e importante, pero los resultados en términos de productividad y calidad en la prestación de los servicios y eficacia de las acciones comerciales lo justifican ampliamente.