Pero el concepto de “autoservicio” no quiere decir “yo proveo las herramientas y que el cliente se las arregle” sino “automatizar procesos existentes para la atención al cliente”. En otras palabras, autoservicio no es “encajarle el sistema al cliente” sino en darle buenos modales al sistema para que lo atienda, manteniendo los mismos estandares y procedimientos que en cualquier otro canal.

Pero la realidad es que mientras en las sucursales y en el call center atienden representantes de atención al cliente, en Internet “atiende” el departamento de IT. Que, dicho sea de paso, es una de las áreas que menos contacto real tiene con el cliente.

Pensemos en homebanking. No importa de qué banco hablemos, casi todos operan desde la perspectiva “yo proveo las herramientas y que el cliente se las arregle” y no desde la idea de “ayudar al cliente a efectuar una transacción”. Es decir, en homebanking queda sólo la capa de IT atendiendo a los clientes, sin que el área de atención al cliente haya agregado buenos modales a la interacción.

Veamos un ejemplo con una de las transacciones más utilizadas en homebanking: transferencias bancarias.

Más allá de cuestiones de legibilidad y consistencia en el diseño (espacios verticales entre los campos, ubicación de los rótulos, consistencia en los botones, etc.), que hacen que el cliente se sienta “bienvenido”, la forma en que operan algunos de estos campos da cuenta de la “perspectiva del sistema” vs. “perspectiva del usuario” con que está encarada la operación de transferencias en este canal.

Importe a debitar

No solamente está separado en dos campos, sino que el campo de los enteros es más corto que el campo de los decimales. Salvo que alguien quiera transferir el número PI (3,14159265), tiene más sentido que haya más espacio para los números enteros que para los decimales.

¿Por qué están divididos los campos? Algunas hipótesis, suponiendo que el cliente quisiera transferir $1.789,32 :

  • separar los enteros de los decimales evita que se debite un monto equivocado si se omiten puntos y comas (ingresando 178932 se transferirían $178.932)
  • para que la gente no confunda puntos por comas (1.789,32 vs 1,789.32)

Esta es la respuesta de IT frente al riesgo de que el usuario ingrese un monto equivocado y de asegurarse consistencia de los datos. Además le evita al programador agregar unas líneas de código para separar los enteros de los decimales. Pero esta solución representa un problema para el usuario, ya que exige mayor esfuerzo en la interacción, interrumpiendo el flujo de escritura innecesariamente para pasar de un campo al otro.

¿Se podía solucionar de otra forma? Sí. Muchos sitios, financieros y de e-commerce (e incluso los cajeros automáticos) insertan automáticamente una coma y un punto a medida que el usuario va ingresando los dígitos. Así, el banco se asegura de que el monto es correcto y que tiene la puntuación correcta sin tener que molestar al usuario. Este es un ejemplo de agregarle buenos modales al sistema.

Cuenta de Destino (CBU)

Al contrario de lo que ocurre con el monto de la transacción, que el usuario puede conocer y tipear directamente, el CBU tiene 22 dígitos, y es improbable que alguien lo recuerde de memoria.

Para ingresarlo sin errores, lo más común es copiar el CBU de algún lado y pegarlo en el formulario. Pero al separar el campo en dos, la operación copiar/pegar es imposible. Esto obliga al usuario a: copiar el CBU del documento original y pegarlo en otro documento, contar los primeros 8 dígitos y separarlos del resto, copiar esos dígitos y pegarlos en el formulario, volver al documento, copiar los 14 dígitos restantes y volver al formulario a pegarlos.

Pero hay otra opción: que el usuario los ingrese manualmente, con el alto riesgo de error que esto significa, sin mencionar la incomodidad para el usuario.

Era necesario hacerlo así? No. La forma de agregarle buenos modales a este campo es simplemente juntar los campos. Pero si por algún motivo el sistema requiere que se ingresen los dígitos en campos separados, la interfaz debería hacer la separación automáticamente y, de alguna manera, comunicarle al usuario que puede pegar los 22 números en el campo y que el sistema se encargará del resto.

Microsoft hace esto cuando pide el código para sus productos: si bien aparecen 4 campos separados, se puede pegar todo el número en el primero (20 dígitos) y el sistema lo separa automáticamente en grupos de 5 dígitos.

Con el campo Documento del Beneficiario pasa lo mismo que con los dos ejemplos anteriores, así que no lo desarrollamos.

Si bien hay empresas que pueden darse el lujo de priorizar sus sistemas por sobre sus clientes porque son cautivos, hay pocas opciones o porque el costo de cambiar de empresa es mayor que el de tolerar la mala atención, la mayor parte de las empresas operan en un contexto competitivo. Y esas empresas no pueden  darse este lujo de pensar en sus sistemas sin pensar en sus usuarios.