Chikero

Podre. A Veiga

[Juan Luis Hortelano @jlhortelano]

Se viene rollo filosófico, aviso ;)

Llevo casi 30 años en el mundo tech. He cofundado empresas, gestionado equipos, invertido en startups, construido productos desde cero. Y hay algo que me está pasando con la IA que me cuesta describir con una sola palabra. Así que voy a intentar describirlo con varias.

La primera reacción, al menos en mi caso, cuando empiezas a usar estas herramientas de verdad, es una mezcla rara. Euforia. Miedo. Y sobre todo vértigo.

Ver que algo en lo que eras bueno, algo que te costó años construir, se convierte en commodity de golpe tiene mucho de desconcertante. Años construyendo una empresa, con patentes y con una tecnología que creías era una barrera de entrada y tu principal valor... y que de repente desaparece. No te lo esperas. Y aunque intelectualmente puedes entenderlo, vivirlo es otra cosa.

Pero ese miedo pasa. Al menos a mí me ha pasado.
Lo que viene después es energía. Proyectos que antes no intentaba porque el coste era demasiado alto, ahora los puedo arrancar en una tarde. Cosas que requerían un equipo, las puedo explorar solo pese a llevar años sin programar y alejado de la parte técnica.
Nuevas oportunidades.

De repente, para muchas cosas no dependo del equipo técnico de mi empresa. Y eso es por una parte reconfortante, pero por otra inquietante.
El techo no ha bajado... es que ha desaparecido. Y eso tiene algo de adictivo, de "joder, ¿por qué no estaba haciendo esto antes?".

Y aquí entra algo que creo que mucha gente no está considerando: la paradoja de Jevons.
En el siglo XIX, cuando se inventaron máquinas de vapor más eficientes, todo el mundo asumió que se consumiría menos carbón. Ocurrió exactamente lo contrario. La eficiencia hizo que usar carbón fuera más barato, así que se usó para más cosas, en más sitios, por más gente. El consumo total se disparó.

Con la IA va a pasar lo mismo. No vamos a escribir menos software porque la IA lo haga más rápido. Vamos a escribir muchísimo más, en muchos más sitios, para muchos más problemas que antes ni siquiera intentábamos resolver porque el coste era prohibitivo. La demanda de inteligencia no se reduce cuando se abarata. Se expande.

Hay un estudio de Berkeley en HBR (https://t.co/sRjR7sWszs) que lo confirma de forma bastante incómoda.
Investigadores de Haas School of Business pasaron 8 meses dentro de una empresa de 200 personas observando qué pasa cuando das herramientas de IA a todo el mundo y dices "adelante". Lo que encontraron contradice todo lo que nos han vendido: los empleados trabajaron más rápido, asumieron más tareas y extendieron su jornada. Nadie se lo pidió. Lo hicieron solos porque la IA hacía que "hacer más" se sintiese posible.
Un empleado lo resumió mejor que cualquier paper: "Pensabas que ahorrarías tiempo y trabajarías menos. Pero no trabajas menos"
El 77% de los empleados que usaban IA en otro estudio decían que les había aumentado la carga de trabajo.
La IA no te devuelve tiempo. Expande el perímetro de lo que sientes que deberías estar haciendo.

Y luego está el estudio del MIT (https://t.co/7rZqK7Pi8W) , que me parece el más incómodo de todos.
Pusieron a 54 personas con electrodos en la cabeza mientras usaban ChatGPT para escribir. Los que usaron IA mostraron un 47% menos de conectividad neuronal durante la tarea. El cerebro no trabajaba menos duro. Directamente se apagaba en las zonas vinculadas al pensamiento crítico y la creatividad.
Pero el dato que más me impactó es otro: el 83% de los usuarios de IA no podían citar ni una frase del ensayo que acababan de escribir. Porque nunca fue realmente suyo.
Y cuando al final de la prueba les quitaron la herramienta, el cerebro no se recuperó. Los patrones de desconexión persistieron.

Los investigadores lo llaman "deuda cognitiva". La misma lógica que la deuda técnica en software: cada atajo de hoy acumula intereses que pagas mañana en forma de menor capacidad para pensar de forma independiente.

El problema no es que la IA te haga menos inteligente. Es que tu cerebro optimiza para el entorno que le das. Y si dejas de ejercitar las partes difíciles del pensamiento, esas partes dejan de estar afiladas.

Pero entiendo perfectamente al otro lado también.

Hay un desarrollador que habló hace poco sobre algo que me impactó bastante.
Su tweet es este : I was a 10x engineer. Now I'm useless.
El video de 12 minutos merece la pena verlo (https://t.co/gLjCPrFfl3)

Describe haber construido un producto completo con IA, que funciona, que la gente usa, que genera ingresos... y al que no tiene ningún vínculo emocional. Porque no sufrió para hacerlo. Y lo describía como fabricar hot dogs: el producto existe, cumple su función, pero tú no pusiste nada de ti.
Eso conecta con algo más profundo que no estamos discutiendo suficiente.

Antes aprendías construyendo. El sufrimiento del proceso era el mecanismo. Te ibas a dormir sin saber cómo resolver algo y te levantabas con la solución, y eso te cambiaba. Ahora puedes construir sin ese ciclo. Más output, sí. Pero menos crecimiento.

Y luego está la red de seguridad. Un desarrollador siempre podía tomarse un año sabático y volver a un trabajo mejor pagado. O dejar su empresa actual sin miedo a encontrar casi lo que quisiera al día siguiente y con mejores condiciones.
Ese colchón existía de verdad y organizaba la vida profesional de mucha gente. La pregunta que nadie quiere hacerse en voz alta es si eso sigue siendo así. Tengo mis dudas.

Y aquí viene lo más complicado: no hay término medio fácil. Una vez que empiezas a usar estas herramientas en serio, tu cerebro deja de querer volver al esfuerzo. No es que puedas reservarte lo difícil para ti y delegar lo aburrido. Es todo o nada.

La energía nueva es real. Y la pérdida también es real. El error está en intentar resolver esa tensión demasiado rápido, en elegir un bando antes de haberlo vivido de verdad.

Lo que sí tengo claro, después de verlo en primera persona, es que la línea divisoria no es generacional.
He visto veteranos de 20 años sacarle un partido tremendo a estas herramientas. Y recién llegados que las tratan como una abstracción filosófica en lugar de algo que puedes usar hoy mismo.
La edad no predice nada. Lo que predice es la disposición. Si corres hacia el cambio o lo miras desde la barrera esperando a que alguien te explique si es seguro cruzar.

Nadie sabe exactamente adónde va esto. Y desconfío de los que dicen que sí lo saben, en cualquiera de los dos sentidos.
Lo que sí sé es que quiero estar en el grupo que corre hacia ello. Con la incomodidad incluida. Con la pérdida incluida. Con las preguntas sin respuesta incluidas.

Porque la alternativa es quedarse parado. Y eso, con o sin IA, nunca ha funcionado.

[Jaime Gómez-Obregón @JaimeObregon]

¿Veinteañero metido en la tecnología?
¿Funcionario ya curtido?
Sigue leyendo; esto quizá te interese…
​
En mis tuits anteriores contaba algunas batallas programando en ensamblador en los años 90.
​
El lenguaje ensamblador es el Vietnam del programador de níveas sienes. Sirve para entretener a los chavales de ahora, alrededor de una fogata, con historias de bravura hexadecimal y napalm en mnemónicos. Sirve para evocar con nostalgia un tiempo de mocedad que idealizas. Sirve para decir orgulloso que estuviste allí, que luchaste. Sirve para todo eso …y poco más.
​
¿O quizá no?
​
Hoy programamos en lenguajes de alto nivel, con orientación a objetos, recolección de basura, librerías potentes, capas de abstracción… Han pasado treinta años y ahora programamos plataformas. La web, los teléfonos o los servicios en la nube o de inteligencia artificial son plataformas.
​
El lenguaje ensamblador es el inconveniente camino contrario: programar, directamente, las instrucciones al microprocesador. Aunque tiene y siempre tendrá su nicho, es un espacio menguante casi relegado del efervescente panorama laboral actual.
​
Si tienes veintitantos o treintaypico años y estás metido en la tecnología, enhorabuena: ¡estás en el sitio correcto y en el momento perfecto! Pero como mis sienes ya platean, déjame contarte, alrededor de la fogata, qué aprendí programando en ensamblador en los años 90 y viene conmigo a día de hoy. Quizá te sea útil también a ti.
​
Releyendo mis tuits del otro día, me fijé en esta instrucción:

En álgebra de Boole, un XOR es una disyunción exclusiva: devuelve verdadero sí y solo sí uno de los operandos es verdadero, pero no ambos.
​
Entonces, la instrucción XOR DX, DX almacenará siempre en el registro DX del microprocesador el valor cero, pues cuando ambos operandos son idénticos, la salida es falsa. Es una instrucción equivalente a:
​
MOV DX, 0
​
Pero, ¿acaso no es esta última más directa y legible que la otra? ¿Qué sentido tiene inicializar una variable haciendo un XOR en lugar de, simplemente, asignarle un cero como toda la vida?
​
Hay una razón: la eficiencia.
​
En la arquitectura Intel 80x86, la instrucción MOV DX, 0 se ensambla en tres bytes y consume dos ciclos de reloj:
​
BA 00 00
​
En cambio, XOR DX, DX se ensambla en dos bytes y consume un solo ciclo:
​
31 D2
​
Hay un ahorro de un byte y un ciclo, que en un 386 a 33 MHz significa 30,3 nanosegundos. Es decir, unas treinta milmillonésimas partes de un segundo.
​
En un bucle que inicializa un megabyte de memoria, o que apaga cientos de miles de píxeles de una pantalla o que anula un fichero en el disco… esta precaución devengaba ahorros tangibles.
​
Hay otra microoptimización interesante aquí:

La instrucción INC BX incrementa el valor almacenado en el registro BX. Como está duplicada, equivale a:
​
ADD BX, 2
​
Solo que el primer camino consume dos bytes, mientras que el ADD —más legible, sí— requiere del doble.
​
Este tipo de optimizaciones son cruciales al programar un virus informático no destructivo —que es lo que hace el código— y otras aplicaciones sensibles, pe…
​
—¡Ya vale de batallitas de yayo! Esto no me sirve hoy para nada —quizá digas, al escuchar todo esto sentado mirando la fogata.
​
¡Pues quizá sí! Y es que hay algo de este Vietnam que ha venido conmigo desde entonces, y que los programadores más jóvenes creo que están perdiendo: el valor de la eficiencia.
​
El cuello de botella ya no es ni la memoria ni la velocidad de tu dispositivo, sino el tráfico de red o la duración de la batería. La eficiencia nunca pasa de moda.
​
Cuando programábamos en los años 80 o 90, a menudo nos dábamos de bruces con los límites de la máquina. Cada byte, cada ciclo de reloj, contaba. ¡Y éramos conscientes! De esto emergió incluso un arte: la demoscene.
​
Muchos programadores de hoy añaden librerías y dependencias a sus proyectos con una ligereza que frunce el ceño de los yayos de níveas sienes curtidos en Saigón. Aplicaciones con cientos de kilobytes de JavaScript. Diarios digitales donde el 90 % de las peticiones HTTP son para rastrearte o invadirte de publicidad. Sitios WordPress en los que dos tercios del DOM es morralla. Una palabra lo describe: «bloatware».
​
Y, sí; cuando has reescrito tu código para ahorrar un byte o un ciclo de reloj, te duele tanto, tanto, cada euro que se va por el desagüe de una Administración pública ineficiente.
​
¿Te imaginas unos servicios públicos óptimos como programas de ensamblador? Licencias municipales tramitadas en 48 horas, una sanidad sin listas de espera, una justicia rápida y digital…
​
Si has llegado hasta aquí y has aprendido algo… ¡redifunde, amigo! Si te ha hecho reflexionar, dale «like» y compártelo. Es gratis. 🙃
​
¡Feliz semana a todos! 😃❤️

[Endorcista @endorcista]

Igual los meteoritos son también planos

[Chikero @Chikero_]

Bravo

[La noche en 24 horas @Lanoche_24h]

Rodrigo Cuevas, cantante y artista multidisciplinar, sobre la España rural:

"Las fronteras políticas nunca coincidieron con las fronteras culturales".

#LaNoche24h
▶️ https://t.co/huxP4TvCag

[Chikero @Chikero_]

@vitoquiles Lo que ha pasado es que has cortado todas sus respuestas ¿?

[Chikero @Chikero_]

Esto es oro molido

[Jaime Gómez-Obregón @JaimeObregon]

🔥 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.

[Jaime Gómez-Obregón @JaimeObregon]

🔥 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.

[𝔸𝕣𝕖𝕫𝕟𝕠 🦋 @Arezno]

No sabía que la cámara seguía grabando. ¿Será el final de su carrera?

[On the other side of the Berlin Wall @03690jul]

Es una mentira. Gente de la zona ha contado que se metió en el vertedero y que se puso a grabar.

La ropa tirada es aquello que los mismos vecinos han tirado de sus viviendas.

Haced que esto se difunda. Es asqueroso que este miserable vaya a engañar a costa de la desgracia

[Lorena Ruiz-Huerta @LorenaRuiz_H]

Pues aquí mi personalisima aportación al caso Errejon. Espero que sirva de contribución al debate. Va por todas las que hemos sufrido violencia política ✊🏽💜 https://t.co/EtIdDA5jrq

[Chikero @Chikero_]

@diarioas Morata

[Principia Marsupia @pmarsupia]

Al-Jazeera ha estrenado este documental sobre la guerra en Gaza. ¿Qué tiene de especial?

Que está hecho con los vídeos que **los soldados israelíes** han ido subiendo a sus redes sociales.

[Chikero @Chikero_]

Correcto. No vengáis, esto es fatal.

[Adrián Cordero @Adricor_fer]

Nunca dejará de sorprenderme que haya gente que, voluntariamente, elija el Cantábrico como destino vacacional.

[Adrián Cordero @Adricor_fer]

Nunca dejará de sorprenderme que haya gente que, voluntariamente, elija el Cantábrico como destino vacacional.

[Jay Motty @JayMotty]

This is better than any speech from a politician we’ve heard recently 👏🏾👏🏾👏🏾

[Chikero @Chikero_]

Hola @mwepu_ilunga??

[Al Descubierto @Al_descubierto_]

▶️ El movimiento ‘tradwife’: las influencers que hacen todo para sus novios y que remiten al antifeminismo de los 60

🔴 La estética y el tono de voz aniñado que utilizan están relacionadas con las comunidades cristianas fundamentalistas y la ultraderecha

https://t.co/LHIdzS6WPj

[Chikero @Chikero_]

@_Rulich_ De lo poco sino lo único buen del nuevo Twitter es lo de "Los lectores añadieron contexto"

[Chikero @Chikero_]

Cada vez me da más ascopena la burbuja consumista y las auténticas ordeñadoras en las que han convertido a los festivales de música. Otro robo al pueblo.

[la jetée 🇵🇸 @lajetee.bsky.social @LaJetweet]

Virgen santísima este círculo del infierno cuál es