Como sus propietarios
notaron una caída en las ventas se propusieron averiguar de cuánto era y a qué
se debía dicha caída.
Más allá del
indicador del monto de la caída, que era un indicador tardío, les interesaba
saber si había alguna otra observación que les permitiera adelantarse a los problemas.
Descartaron
primero las obvias, precio, variedad, ubicación del local, etc., ya que en
todas ellas estaban en iguales condiciones que la competencia.
Quedaba por
entender entonces algo que estaba ocurriendo dentro del local, entre el cliente
y la oferta de nuestro supermercado. Pensaron varias alternativas, entre ellas:
- Contar cuánta gente entraba y cuánta salía sin comprar nada.
- Ver los tickets y entender en qué góndolas la gente compraba menos, a igual precio e igual mercadería que la competencia, habría otros factores que no les convencían.
- Detectar cuántos clientes vuelven a comprar luego de la primera compra (licencia poética).
- Entender el tipo de cliente que normalmente atraemos y entender sus expectativas (qué le encanta y qué le disgusta).
- .……
Podríamos seguir
enumerando indicadores que le pongan valor al comportamiento del cliente y
tratar de deducir de allí la experiencia
de compra que tiene.
--
Dejemos aquí al
supermercadista preocupado y nuevamente hagamos una analogía entre lo dicho y
nuestra tarea de crear productos y servicios de software.
Comencemos por la
definición de requerimientos o exploración de las necesidades.
Si el comportamiento
del usuario es más conocido y manejable nos permitirá la definición de
requerimientos algo más precisa, si es menos conocido y manejable nos obligará
a explorar.
Para ordenar el
trabajo puede ser útil aquí el modelo Kano (1), que nos dice habrá funcionalidad
que el producto deberá tener, ya que si ellas nuestro usuario/consumidor ni
siquiera lo considerará, habrá otras características que entre más tenga de
ellas, más apreciará el producto y finalmente habrá otras que al descubrirlas
le encantarán y eso hará que lo considere de calidad superior, y tal vez esté
dispuesto a pagar más por él. Es una ayuda, al menos nos acercará a descubrir
necesidades y algunas expectativas.
Pero qué ocurre cuando
el producto está en operación durante algún tiempo. ¿Cómo podremos descubrirlas?
Es una situación parecida a la de nuestro personaje del supermercado que quería
verificar la experiencia del consumidor en su local. Buscaba medidas e
indicadores que lo orientaran a qué cambiar y mejorar y a qué mantener.
Nosotros también.
Dependiendo del
tipo de producto/servicio que estemos tratando, algunos indicadores pueden ser
parecidos, por ejemplo cantidad de visitantes convertidos en ventas.
Algunas
alternativas de qué medir cuando el producto/servicio está operando las plantea
la idea de calidad en uso propuesta por la ISO 25010, hoy con poco detalle
todavía, pero ayuda.
Nos hace preguntar por ejemplo:
- ¿Confía el usuario en el sistema?
- ¿Hace más cosas en menos tiempo?
- ¿Está satisfecho con el sistema?
- ¿Se logró/mejoró el objetivo económico con la adopción del sistema?
- ¿Logró lo anterior, confiabilidad, efectividad, satisfacción, en los diferentes contextos de utilización?
En estas entradas:
La
calidad en uso e Indicadores
accionables hay algo más sobre esta idea.
Posiblemente
nuestro caso necesite algunos indicadores distintos, o más detallados, o de
mayor precisión. Pero esta es una buena aproximación.
Dejamos entonces
a nuestro supermercadista de la historia viendo cómo mejorar la experiencia de
usuario de sus visitantes y, como él, entendamos que las expectativas al entrar al local, superadas o
no, son lo que va a definir finalmente el futuro del negocio.
Viene de Equipos Multidisciplinarios
y de Una visita al supermercado
Viene de Equipos Multidisciplinarios
y de Una visita al supermercado
Saludos,
Raúl
TW: @RaulMartinez582
Referencias:
Kano, Noriaki;
Nobuhiku Seraku, Fumio Takahashi, Shinichi Tsuji (April 1984). «Attractive
quality and must-be quality»
No hay comentarios:
Publicar un comentario