Necesito un Administrador de Canales de Contactos (Contact Channel Management) en mi empresa?

Por supuesto que necesita de uno!

Se puede vivir sin él, pero realmente nos puede ser de mucha ayuda!

Entendamos un poco de la historia del nacimiento de estas aplicaciones y veamos en qué pueden ayudarnos

Uno de los pilares fundamentales de las empresas es el contacto con los clientes, siempre buscamos llegar a ellos de manera confiable, certera y económica. Hace mucho tiempo, la única forma de hacerlo era visitarlo personalmente, más tarde a través del teléfono, luego el mail, sms, redes sociales y vaya a saber cuantas más formas aparecerán a futuro.

Cuando un área o una aplicación necesitaba contactar a un cliente, simplemente había que saber la información de contacto y a través de qué plataforma había que solicitar el envío y simplemente hacerlo.

Desde muchos lugar se disparaban, por ejemplo, mails, en la plataforma de envío de mails podía guardar los templates de envío, el histórico de envío de mails a un cliente, si tuvo respuesta o no y más información relacionada con el envío. Además podía ver si había enviado muchos mails a un cliente durante la última semana y decidir esperar para enviar el próximo evitando el malhumor de mis clientes por recibir demasiados correos de nuestra parte.

A medida que los canales de contacto fueron creciendo cada vez más áreas y aplicaciones comenzaron a usar estos medios de formas diferentes y en distintos momentos, entonces la información que quizá antes tenía concentrada en la plataforma de mails, ahora pasó a estar distribuida en varias plataformas, con lo cual si ahora necesitaba saber cuántas veces lo había contactado a mi cliente tenía que mirar a cada una de las plataformas. Si teníamos la suerte de contar con un CRM que almacene todas las interacciones con mis clientes quizá podría consultarlo ahí, pero dependía de la buena voluntad de cada aplicación/área que tenía que avisar de dicho contacto.

Ahí es dónde surge la necesidad de tener un único punto de administración de canales de contacto, para que cada uno que necesita contactar a un cliente lo haga a través de esta nueva aplicación.

Esta nueva aplicación se nutrirá con la información de los clientes y sus contactos desde el CIM y generará las interacciones con los clientes en dicho módulo; de esta forma cualquier usuario que mire desde el CRM los datos de un cliente podrá saber su historial de contactos, si desea tener más información entonces podrá ir a nuestro Administrador de Canales de Contactos (ACC) y obtener todo el detalle que necesite. 

Funcionalidades más importantes del Administrador de Canales de Contactos

• Flexibilidad en el manejo de reglas. Por ejemplo evitar más de un envío diario sin importar el canal, selección de canal de preferencia y horarios de contacto, selección de lenguaje
• Manejo de templates
• Manejo de recepción, flujos ante fallas, reintentos a través del mismo canal o canales alternativos
• Manejo de varios canales de contacto
• Único repositorio de historial de contacto
• Encolamiento de mensajes
• Generación de eventos posteriores al envío

Espero que luego de leer este post les haya quedado claro de qué hablamos cuando nos referimos a un Administrador de Canales de Contactos, cuáles son sus principales responsabilidades y cómo pueden ayudarnos en nuestra empresa.

Sin dudas es una herramienta fundamental en estos momentos, hay mucha variedad en el mercado, pero cuidado porque también hay muchas herramientas que mezclan conceptos, que hacen cosas que no deberían hacer y que no hacen las que esperamos de un verdadero ACC, no es un desafío menor elegir bien y no equivocarse.

Las responsabilidades en las empresas no son sólo para los empleados, el software también debe ser responsable…

Así como se busca hacer software cada vez más inteligente, creo que deberíamos buscar hacer software cada vez más responsable, que conozca sus limitaciones, qué que tiene que hacer y qué no.

Hace tiempo atrás las aplicaciones o programas en las empresas eran monolíticos, únicos y se encargaban de hacer todo, por lo tanto cuando surgía una nueva necesidad o requerimiento era fácil decidir dónde había que hacerlo… ya que había un único lugar para eso.

En las nuevas arquitecturas de software SOA tenemos cada vez más aplicaciones separadas y con funcionalidad específica y concreta, se busca que cada una de ellas esté desacoplada funcionalmente de las otras para evitar solapamientos funcionales.

Uno de los mayores desafíos entonces, es conseguir que cada una de ellas haga lo que tiene que hacer, sin caer en la tentación de hacer más de lo que corresponde, es decir, es fundamental que las aplicaciones sean responsables, la pregunta es, cómo conseguir que esto suceda?

Si vas a una peluquería y pedís que te corten el pelo o que te afeiten, el dueño no dudará ni un instante en hacerlo; pero si pedís que te haga un sándwich de milanesa, lo más probable es te diga que no puede hacerlo, ya que no forma parte de sus responsabilidades como peluquero.

Entonces porque cuando viene un usuario a pedir que hagamos en nuestra aplicación algo que no corresponde aceptamos hacerlo?

El desarrollador debería saber la responsabilidad de la aplicación que está a su cargo, sus límites, qué puede hacer y qué no, para evitar aceptar pedidos que no corresponden. Inclusive el usuario debería ser consciente de estas responsabilidades para no pedir algo que fuera de lugar.

Por qué resulta tan importante que el software no haga más de lo que corresponde?

La tecnología avanza cada vez más rápido, con lo cual cada vez más rápido nuestras aplicaciones se vuelve obsoletas, viejas y necesitamos cambiarlas o actualizarlas. Hacer esto en una aplicación con claras responsabilidades y límites es mucho más sencillo, inclusive si la decisión es tirarla y comprar una nueva, es más fácil buscar su reemplazo en el mercado; en cambio si tenemos una aplicación que hace un poquito de cada cosa, seguro que no va a existir en el mercado y si queremos volver a desarrollarla será difícil entender qué hace actualmente.

Cómo puedo saber si mi aplicación es responsable?

Una forma rápida de saberlo en a través del nombre y su descripción funcional de alto nivel.

El nombre, más allá del nombre de fantasía, debe ser claro y marcar sus responsabilidades, por ejemplo, si pregunto le preguntó a un desarrollador en que aplicación está trabajando y me contesta cosas como: en el tasador, el facturador, el administrador de recursos de red o el administrador de campañas, estaríamos escuchando las respuestas correctas; cada una de ellas tiene claro desde su concepción del nombre qué hacen.

Inclusive, si le pregunto a esa misma persona qué es, cuál es su descripción, estoy seguro que me podrá responder en un párrafo no más extenso que un tweet.

Sin embargo, cuando nos encontramos con aplicaciones cuyos nombres son la web de Juan, el portal, la aplicación de Pedro, el sitio de los vendedores, claramente estamos en problemas; si a esa misma persona le preguntamos qué hace la aplicación nos empezará a enumerar cada una de las opciones que incluye y luego de estar hablando un largo rato dirá: ah, me olvidaba también hace…

Limitar una aplicación no es sencillo y lamentablemente no hay una única forma de hacerlo, existen lineamientos, tipificaciones o estándares para algunas industrias, como por ejemplo el TmForum (www.tmforum.org) para la industria de las comunicaciones, pero esos límites nunca son 100% claros y dejan en manos de quienes desarrollan la definición del alcance de cada aplicación.

Entonces, qué debo pensar antes de agregar un requerimiento a una aplicación?

Lo primero a pensar no es si se puede hacer o no, o cuanto me cuesta, lo primero que debe pensar, tanto el desarrollador como el usuario, es este requerimiento debe ser resuelto por esta aplicación?

Si la respuesta es afirmativa, entonces vendrán las preguntas de costo y factibilidad, pero si la respuesta es no, bajo ninguna condición deberemos tomar ese requerimiento por más tentador que resulte.

A veces por temas de costos, económicos o de tiempos, se aceptan requerimientos que no corresponden, eso tarde o temprano será más costoso para la empresa, para el usuario y para el desarrollador, no permitan caer en esa tentación.

Puede el peluquero hacer un sándwich?

Claro que puede, pero no va a saber hacerlo tan bien cómo lo harían en un bar, ni va a tener las variedades que podría tener un bar, pero sobre todo mientras me esté haciendo el sándwich no podrá cortarme el pelo o peor aún se distraerá y quizá termine con una oreja menos.

Una de las principales tareas de un arquitecto de software, es ayudar a que cada aplicación de la empresa sea responsable y esté bien delimitada, es fundamental que cada desarrollador lo sepa así no permite que esas responsabilidades se diluyan; pero sobre todo se debe transmitir este conocimiento a los usuarios para que sepan a quién deben pedirle que les resuelvan sus necesidades y requerimientos.