Cuando el creador sabe que tendrá que brindar soporte al usuario,crea un producto que funciona mejor y es más amigable.

El fundador de Booking.com puso un ruidoso teléfono rojo en la oficina de Ingeniería. Era el teléfono de atención al cliente. ¿Por qué alguien pondría a un ingeniero a atender llamadas?

Porque después de la tercera llamada por el mismo problema, el ingeniero prefiere cortar con lo que esta haciendo y arreglar el problema, que seguir atendiendo el teléfono.

La mayoría de mis aprendizajes han venido por frustraciones (¡sino es que todos!) y como argentino sé lo frustrante que son los servicios en general aquí (particularmente Internet cuando no funciona).

Hubo 3 momentos claves en mis experiencias con mis proveedores de Internet:

• El servicio no es estable: deja de funcionar intermitentemente y algunas veces se cae por horas.

• Cuando llamo me atiende un operador con mala onda que me trata como un tonto. (No creo que lo haga a propósito, sigue órdenes o no tiene idea de lo que habla).

• Luego de varias llamadas, no obtengo una solución.

¿Qué pasa luego?

• Cancelo el servicio
• Contrato otro proveedor.
• Si un amigo me pregunta, no lo recomiendo.

Sin embargo,  y a pesar de que el servicio de Internet es malo en Argentina, nuestros proveedores, en vez de solucionar los problemas para brindar un servicio estable y confiable, lanzan nuevos planes cada 6 meses con el afán de conseguir nuevos clientes: 5 mb en vez de 2.5 o 15 en vez de 10mb, etc.

¿Hay un problema de prioridades?

Lo que yo necesito no es mas velocidad; es estabilidad y alguien que me brinde un buen soporte si algo falla.

Como mis proveedores no podían proveerme un servicio confiable el 100% del tiempo, terminé contratando a los 2, de manera que si uno no funciona, puedo usar el otro.

Moraleja 1.

Cuando el servicio falla, el soporte es clave. Es un momento decisivo; es el momento en el cual el cliente decide permanecer o empezar a buscar un reemplazo.

Moraleja 2.

Brindar un mal servicio es como hacer publicidad para la competencia. Un evento de mal servicio dispara una búsqueda de proveedores alternativos.

Moraleja 3.

Como cliente, estoy pagando 2 veces, por obtener más estabilidad y confiabilidad. ¡Qué importante es que las cosas funcionen simplemente bien!

 

Dos términos para describir la calidad según los japoneses

La cultura japonesa tiene dos términos para describir la calidad de un servicio o producto:

• Atarimae hinshitsu:

El nivel de básico de calidad es que el producto debe funcionar, la promesa que se le hizo al cliente se debe cumplir. «Una lapicera debe escribir», «Una cuchillo debe cortar».
Este nivel de calidad se obtiene cuando el producto hace lo que dice que hace. En el caso de Internet, sería, simplemente que entregue la velocidad que contraté y que sea estable.

• Miryoku teki hinshitsu:

El siguiente nivel en la calidad es que el producto debe encantar al cliente. El ejemplo más claro que se me viene a la mente son los productos de Apple: la caja, el envoltorio, el diseño, es impecable. Hace nmucho más de lo que prometen: no solo funcionan bien, sino que además, encantan.

En el diseño de productos o servicios, atarimae hinshitsu y miryokuteki hinshitsu juntos se aseguran que crearemos algo que no sólo cumplirá con las expectativas del clientes, sino que también será un producto «encantador».

Este video de Ken Hale, uno de los partners de Y Combinator, (un grupo de inversores y mentores exitosos) lo explica perfectamente.

 

La gran pregunta ¿Arreglamos, mejoramos o hacemos algo nuevo?

En el afán de crecer, todas las empresas quieren hacer cosas nuevas para atraer más clientes.

Pero cuantas veces nos preguntamos ¿y si primero arreglamos lo que tenemos roto? ¿o mejoramos lo que tenemos? o ¿hacemos algo nuevo? Los recursos son muy limitados y necesitamos definir prioridades.

La respuesta podría estar en el Soporte al Cliente.

Cuando el desarrollo esta guiado por el soporte al cliente, estamos en presencia del SDD (Support Driven Development). Acuñado por el fundador de Wufoo, Kevin Hale, el Support Driven Development es:

«Inyectar humildad y responsabilidad en el proceso de desarrollo asegurándose que los creadores también serán los que brinden soporte al cliente.»  Si voy a crear esto,¿cómo me afectará después cuando tenga que brindar soporte al usuario?» – Kevin Hale

En otras palabras: los ingenieros hacen soporte. O mejor dicho, todos hacen soporte.

Basta con hacer soporte o hablar con la  persona encargada de soporte para saber con qué debemos continuar.

El principio básico es que todo debe funcionar de acuerdo con lo prometido al cliente (atarimae hinshitsu). Por lo tanto, si hay consultas (o quejas) repetidas sobre un asunto, el desarrollo debe orientarse a solucionar ese problema primero, antes de hacer cosas nuevas o trabajar en los detalles de las existentes.

 

Las 5 prioridades en Support Driven Development, de mayor a menor prioridad.

• Arreglar lo que está roto. Si hay algo que no funciona, se arregla. Esa es la prioridad más grande; todo lo que este en frente de nuestros clientes, debe funcionar bien.

Tip: basta con preguntarle a la persona de soporte o hacer soporte una semana para saber lo que esta roto. Concentrarse primero en los problemas que se repiten; esos los sabe cualquier persona de soporte, sin necesitar ningún sistema de control de bugs o tareas.

• Hacer más fácil de usar lo que ya existe.  Si hay algo que no tiene documentación, es difícil (o imposible de usar), no es intuitivo o no es accessible, entonces se trata de hacer más fácil de usar (más intuitivo, se le agrega documentación o ayuda contextual, etc).

Tip: para hacer más usable cualquier cosa, hay que ver como la usa alguien por primera vez.

• Mejorar la funcionalidad. Basándonos en los requerimientos de nuestros usuarios, mejoramos una funcionalidad de nuestro producto.

• Humanizar la relación. Cuando la funcionalidad ya está funcionando bien, (aunque esto puede ser hecho desde el principio), la humanizamos. ¿Qué significa humanizarla? Hacer la comunicación más personal, más intima y más relevante.

TIP: habla en el lenguaje de tus clientes. Haz un estudio de «personas» para entender quién es tu cliente y cómo hablarle.

• Cuando lo anterior está listo, agregamos nuevas funcionalidades.  En última instancia, cuando todo funciona, es usable y se ha humanizado, creamos una nueva funcionalidad para resolver otro problema de nuestro cliente.

Las prioridades 1 y 2 del SDD están relacionadas al «atarimae hinshitsu». O sea, de ellas depende que el producto pueda hacer para el usuario lo que dice que puede hacer. El producto debe funcionar y debe haber sido diseñado de manera tal que el usuario pueda utilizarlo.

Las prioridades 3 y 4 del SDD están más relacionadas al «miryouku teki hinshitsu». O sea, a como el producto va a encantar al usuario, debe hacer su experiencia placentera.

3 estrategias para acelerar el SDD

1. Poner a todos en servicio al cliente (especialmente a los ingenieros)

 «El creador, también hace soporte»

¿Te gustaría de tener un crecimiento como el que tuvo Stripe? Ellos utilizan el SDD: todos hacen soporte, incluso los fundadores.

Cito un fragmento de este post que habla sobre la cultura de Stripe:

Every single engineer does support, on a bi-weekly rotation. Even the founders John and Patrick. We provide support over an IRC channel, email, and through Stripe answers. I’ve found providing support to be one of the best ways to learn about the company, how everything works internally, and our customer’s needs. I’ve been writing a bunch of tools to automate some of the most common queries, like chargeback evidence, but at the end of the day we want to ensure that there’s always a human available.»

2. Mejorar las herramientas de soporte

Una de los grandes beneficios de poner a un ingeniero a trabajar en soporte, es que va a mejorar las herramientas de soporte. Cuando se presente ante una tarea repetitiva, va a desarrollar una herramienta para hacer ese proceso más simple y esa nueva herramienta va a acelerar el soporte de toda la organización. Las herramientas de soporte se van a ver naturalmente mejoradas cuando un ingeniero trabaje en soporte.

3. Poner un responsable de Customer Happiness, que reporte al o sea también el responsable de Operaciones y que los clientes puedan acceder a él.

La excelencia operativa y la eficiencia operativa debería estar ligada a la felicidad de los clientes de la empresa. Las operaciones de la empresa deben hacerse más eficientes día a día pero nunca a costa de la felicidad de clientes o empleados.

Por qué es mucho mejor ser el mejor para uno que bueno para todos

Por último, pero muy importante, especialmente para un startup es recordar que nuestros recursos están muy limitados y por ello, no podemos (ni debemos complacer a todo el mundo).

Para crecer rápido, Paul Graham de Y Combinator recomienda hacer un producto que satisfaga completamente las necesidades de un solo tipo de clientes. Un producto que sea «lo mejor» para un tipo de cliente y no un producto que sea mediocre para un montón de personas.

Una vez que conseguimos un producto que es excepcionalmente bueno para alguien, es mucho más fácil encontrar otras personas similares que tratar de adquirir más clientes cuando tenemos un producto que es medianamente bueno para muchos.

En realidad esto es fácil de explicar matemáticamente: si elegimos un tipo de clientes y nuestra clientela es básicamente una colección de clientes con las mismas necesidades, cada mejora que hacemos impacta a toda la colección de clientes.

Por otra parte, si tenemos un conjunto de clientes con diferentes necesidades, cada mejora impacta parcialmente en nuestro conjunto de clientes. O impacta positivamente en unos y negativamente en otros, consiguientemente el impacto es mucho menor.

A la hora de definir prioridades empieza por resolver lo que está roto, lo que no funciona para un segmento de clientes en el cuál te quieres enfocar; cuando todo esté arreglado, haz todo más fácil de usar. Cuando todo funcione y sea fácil de usar, mejora las funcionalidades actuales. En ese punto puedes comenzar a hacer tu producto «encantador» y recién después y por último, comienza a desarrollar cosas nuevas.

Me gustaría escuchar lo que piensas ¿Te parece correcto que todo el mundo haga soporte, incluso los ingenieros?