🔥 ME LLEVAN LOS DEMONIOS 🔥 Sí. Eché otra mañana surfeando las olas de la burocracia del Ayuntamiento de Santander. Me susurra al oído el espíritu de Ted Kaczynski cada vez que pongo mi tremuloso pie en esa Babilonia. —Nadie atiende el teléfono. —No contestan a los correos. —Hay que ir y hacer una cola soviética. Y la cita previa: ¡la risión! ⚠️ ¿Cómo es posible que la ciudadanía reciba esta paupérrima «atención»? ¿Es que no veis la brutal oportunidad de mejora que tenéis ahí, alcaldesa @gemaigual? En mi empresa éramos un equipo pequeño, pero atendimos —había un contador— más de 35 000 consultas de clientes. ¡Y estaban encantados! Éramos más caros que la competencia, pero se quedaban con nosotros por el soporte que brindábamos. La empresa fue comprada el año pasado, y creo que el procedimiento de atención al cliente que diseñé fue una de las razones. ¿Por qué no puede funcionar así mi ayuntamiento? Quizá nadie del consistorio lo lea, pero me tomo el esfuerzo de escribir esto y compartirlo porque pienso que podría ayudar o inspirar a otros: 1️⃣ Desplegué un sistema de ticketing. Era 2011 y tras estudiar varios opté por OTRS, que es libre y de código abierto. Pero hay decenas. 2️⃣ Conecté la centralita telefónica (Asterisk; también libre y abierto) al sistema de ticketing y al CRM de la empresa. 3️⃣ Habilité un buzón único de atención al cliente por correo electrónico. Aquí la palabra clave es «único». 4️⃣ Procedimenté todo, lo documenté y formé a mis compañeros. Luego ellos, a su vez, formaban a las nuevas incorporaciones. Aunque el conocimiento residía en el sistema y no en las personas. ☠️ Me resulta penoso tener que explicar esto a un organismo público, pero cada vez que tengo que hacer una gestión en el Ayuntamiento de Santander pierdo puntos de vida. Así que lo pongo por escrito, y ojalá sirva a alguien: 🟢 Diseñé todo esto pensando en el cliente. No en mi cara bonita ni en mi empresa, sino en el cliente. Y aprendí que cuando se lo pones fácil al cliente, tú curras menos. 🟢 El cliente solo tenía dos puntos de contacto con nosotros: 1️⃣ un número de teléfono único y 2️⃣ un buzón de correo electrónico único. ¡Claro que la organización era más compleja por debajo! Teníamos varias líneas de teléfono, números móviles y decenas de buzones. Pero diseñé todo de forma que el cliente no viera esa complejidad. (¡Donde escribo «cliente» y «empresa» léase «ciudadano» y «ayuntamiento»!) 🟢 Cualquier consulta de un cliente origina un ticket. Un ticket es un diálogo escrito entre el cliente y la empresa. Los tickets —por diseño del sistema— no se pueden borrar y no se pueden perder. ¡Esa es la clave! Todo el proceso está sistematizado. Es un circuito. 🟢 Si yo escribo un correo electrónico a «licencias», no lo reciben en «tributos». Pero si tienes un sistema de ticketing la consulta no está en el buzón de alguien que quizá lo ignore, sino en el sistema. ¡No puedes escurrir el bulto! Si no lo atiendes, todo el mundo en la organización ve que tienes una consulta sin atender desde hace días o semanas. ¡Transparencia! 🟢 La atención es omnicanal. Da igual si el cliente contacta por correo electrónico, por teléfono, por el formulario de contacto del sitio web, por las redes sociales… Todos esos canales convergen automáticamente en el sistema de ticketing y se gestionan internamente igual: ¡con tickets! 🟢 Un ticket tiene un ciclo de vida: se crea cuando el cliente contacta con la empresa, y se cierra cuando la consulta queda atendida. El cliente, claro, puede reabrir un ticket cerrado sin más que contestar o repreguntar. 🟢 ¡El cliente no ve nada de esto! No sabe qué es un ticket y no conoce el procedimiento. Los sistemas de ticketing suelen tener un «portal del cliente» donde el cliente puede abrir tickets nuevos o hacer seguimiento de los que tiene abiertos. Yo descarté esto, porque va contra el principio de máxima sencillez para el cliente. Te amoldas tú a tu cliente; no al revés. 🟢 El sistema está compuesto por colas. Un ticket siempre está en una cola. Hay tantas colas como áreas funcionales o departamentos tiene la empresa. «La cola de Sistemas». «La cola de Administración». «La cola de Desarrollo»… El sistema es flexible y a veces creábamos colas temporales para proyectos grandes, pero esto eran excepciones. 🟢 El sistema también tiene agentes. Que son personas que atienden colas. Hay muchas colas, pero cada agente solo ve las colas de su área de responsabilidad. En mi empresa todos hacíamos soporte, aunque fuese poco. ¡Es la forma de conocer a tu cliente! Yo era el director y cerré cientos de tickets. 🟢 ¡Algunos de nuestros clientes a duras penas sabían enviar un correo electrónico! El sistema tiene que ser tan sencillo para el cliente que resulte viable para el más torpe de ellos. 🟢 Como en el fordismo, los tickets —que son las consultas de los clientes— se mueven de cola en cola. Cuando un cliente escribe al buzón de soporte, entraba a la cola «Sin Clasificar», que era atendida por toda la empresa. Si tú veías un ticket en «Sin Clasificar», lo leías y lo movías a la cola de los compañeros que fuese. ¡Y así te lo quitabas de encima! 😃 Porque aunque tienes acceso a todas las colas, tú solo ves las que son tu responsabilidad. 🟢 A partir de aquí, ¡es todo como un juego! Gamificación. Hacíamos concursos. ¡Sistemas tiene 56 tiques y Desarrollo solo 6! ¡Fulanito ha cerrado 35 tickets hoy: nuevo récord! ¡Empleado del mes! ¡Foto enmarcada en el vestíbulo! Nadie va al trabajo a sufrir: vas a pasarlo bien, a superarte y a hacer algo que tenga sentido. ✨ 🟢 Te pasas el juego cuando has cerrado todos los tiques en tus colas. Cuando estás a cero. ¡No hay nada en tu tejado! 🟢 Transparencia. Aunque tú solo eres responsable de tus colas, toda la empresa tiene visibilidad de todos los tickets. ¡Un departamento no es un silo cerrado! Lo que pasa en otros despachos también te afecta a ti. 🟢 A veces un cliente preguntaba cosas de varias áreas en una misma consulta. El ticket llegaba a la cola «Sin Clasificar» y el primero que lo leía lo movía a la cola del área en cuestión. Esos compañeros lo atendían pero después, en lugar de cerrar el ticket, lo movían a la cola de la otra área para que terminaran de atender al cliente. 🟢 Con el ticket viaja todo el diálogo con el cliente, y también notas internas que los compañeros dejan y el cliente no ve. Sirven para dar contexto. Había tickets larguísimos, con decenas de mensajes y notas compartidos durante meses. A veces partíamos los tickets largos en otros más cortos. De nuevo, el cliente no se enteraba de cómo gestionábamos nosotros internamente su consulta. 🟢 El cliente, desde su óptica, solo ve que le atienden. Él no sabe nada de tickets, colas y procedimientos. 🟢 Al llamar por teléfono, te salía un menú interactivo de voz (IVR) y marcabas el número del área con el que querías hablar. ¡Pero el cliente no tiene por qué saber nuestra departamentalización interna! No puedes pedir a tu cliente que sepa cómo estás organizado tú. Así que el menú eran solo tres opciones. 🟢 Tras elegir el área, la llamada saltaba al teléfono del Agente 1. Si su línea estaba ocupada o él declinaba la llamada, saltaba al Agente 2. Si no podía atender, la llamada saltaba al Agente 3 …y así sucesivamente. Si no quedaba gente en el área, te atendía alguien de otra área. Yo era el director de la empresa, el último en la jerarquía de agentes de soporte, y a veces me saltaban llamadas en el despacho. ¡Pero nunca se dejaba sin atender una llamada! 🟢 Nosotros no teníamos un CAU. Yo pienso que es un error —al menos en ciertas organizaciones como mi empresa— tener un Centro de Atención al Usuario como un ente diferenciado de la parte productiva de la organización. Toda la empresa era un CAU. Pero no todo el mundo en la misma proporción: los administrativos despachaban el 85 % de los tickets. Los programadores apenas recibían tickets. 🟢 El sistema era tan eficaz, que hasta nosotros mismos nos creábamos tickets internamente. Era la forma de asegurarte de que nada se perdía ni olvidaba. 🟢 Los clientes sabían que siempre, siempre, siempre que escribían o llamaban, se les atendía. Así que eran generosos cuando a veces tardábamos más de la cuenta. Lo que pasa con el Ayuntamiento es que ya llamas o escribes de uñas porque sabes que van a pasar de ti. 🟢 Si llamabas un día festivo o fuera de horario laboral, una locución te decía 1️⃣ cuál es nuestro horario y 2️⃣ te daba dos opciones: dejar un mensaje de voz o escribir por correo electrónico. Esto era muy útil con las festividades locales. Porque tus clientes de Barcelona no tienen por qué saber que hoy es festivo en Santander. Cuando llamas al Ayuntamiento de Santander fuera de horario, simplemente oyes pitidos hasta que te aburres y cuelgas, así que te quedas a dos velas. 🟢 El número llamante se casaba con el CRM de la empresa, de modo que en la pantalla del teléfono leías, antes de descolgar, quién te estaba llamando. Esto era muy útil, porque no es lo mismo atender una llamada a ciegas que sabiendo con quién vas a hablar y anticipándote a lo que probablemente quiere. 🟢 Los mensajes que los clientes dejaban fuera de horario laboral en el buzón de voz se enviaban como un MP3 al sistema de ticketing y abrían un ticket normal. 🟢 Tras atender a un cliente por teléfono, era protocolario enviar después un correo-resumen: «Estimado Fulanito: tal como acabamos de comentar, bla bla bla». Al cliente esto le enamora. Pero nosotros lo hacíamos, sobre todo, porque era la forma de decirnos entre nosotros qué le habíamos dicho al cliente por teléfono. A veces anotábamos esto como una nota interna del ticket. ¡Poner todo por escrito nos salvó muchas veces de malentendidos muy complejos! 🟢 ¿Cómo se resolvía aquella compleja consulta que hizo tal cliente el año pasado? ¿Cómo resolvió Fulanito, que ya no está en la empresa, este otro asunto? Teníamos una base de conocimiento con 35 000 tickets, y un buscador para localizar casi cualquier cosa imaginable. 🟢 Cuando un cliente escribía un correo electrónico al buzón de soporte recibía una respuesta automática: «Estimado Fulanito, hemos recibido tu consulta y le hemos asignado el nº 31415…». Esto daba paz a los clientes, porque sabían que su petición ya estaba «en la rueda» y sería atendida. 🟢 A veces los clientes escribían a buzones de compañeros, no al buzón de soporte. Como en cada cliente de correo todos teníamos configurado el buzón de soporte, era tan simple como arrastrar el correo de tu bandeja de entrada al buzón de soporte. El sistema de ticketing leía continuamente el buzón de soporte y procesaba así los mensaje entrantes. 🔥🔥🔥🔥🔥🔥 Así es —explicado rápido y mal— como un equipo pequeño atendimos más de 35 000 consultas. No sé por qué el Ayuntamiento de Santander, que tiene muchos más recursos que mi pequeña empresa, no puede hacer algo parecido. Porque ahora cuando llamas o escribes te ignoran, y cuando llegas allí te atienden en colas soviéticas o de la manera más ineficiente para todos: con cita previa. Yo no he inventado nada de lo que he descrito. Así es como funciona hoy en día cualquier empresa mínimamente seria que tenga sistematizada su atención al cliente. No hace falta ser el lápiz más afilado del estuche para darse cuenta de que cualquier ayuntamiento mediano o grande necesita algo así. Y que si atendieran bien por teléfono y correo, se acaban las colas. Que sí. Que un ayuntamiento es diferente a una empresa. No lo estoy comparando. Solo digo que el mundo público podría beneficiarse mucho de observar y adoptar las soluciones que despliegan las empresas eficientes. Y eso beneficiaría a toda la ciudadanía. ¡Aunque quizá todo está como está porque si lo sistematizan y procedimentan bien sería evidente que un tercio de la plantilla no está haciendo nada! 🤡 👉 Yo ya no sé qué hacer para intentar que la atención al ciudadano funcione mejor en mi ciudad. He echado la mañana a padecer su burocracia, y ahora parte de la tarde a escribir esta infumable diatriba. Quizá todo esté perdido. Sea como fuere, me pongo a disposición —sin pedir nada a cambio— de quien quiera que en el equipo de gobierno o en los grupos de la oposición esté dispuesto a mover ficha para solucionar lo que está pasando en el Ayuntamiento de Santander.

Nah es demasiado crack JAJAJAJAJAJAJA

@ppopular No puede ser jajaja