Push v/s Pull ... Un cambio de mirada en el servicio
Hoy se estrenó un número de consulta atendido por un IVR (Interactive Voice Response) en el número 600 422 0000, para que los ciudadanos automovilistas de Santiago de Chile, podamos consultar la restricción vehicular.
Lo primero es mencionar que NO es un Call Center, como se ha publicitado tan profusamente.
Aprovecharé este caso para explicar en forma práctica la diferencia entre los modelos "Push" y "Pull", aplicables a múltiples casos de negocio, como un ejemplo del cambio de mirada estratégica para los modelos de servicio.
Y quién sabe, haciendo los contactos adecuados, quizás pueda colaborar con un granito de arena a "mejorar la vida de las personas" mediante la tecnología, motivo original por el cual inicié este blog.
Primer paso: La definición correcta del problema
Como información de contexto para mis lectores internacionales, Santiago es una ciudad con una muy alta contaminación ambiental. Y al igual que muchas otras megaciudades en el planeta, poseemos restricciones de circulación, dependiendo del dígito en el cual termina la placa patente de nuestro vehículo. Si circulas con restricción y eres fiscalizado, la multa es muy alta y además te ganas una anotación en tu hoja de vida como conductor.
El problema surge como consecuencia del modelo de operación, siendo una restricción "no modificable" y que debe ser considerada por el arquitecto del sistema. Dado que el modelo de predicción de contaminantes es de horizonte temporal muy corto, la decisión de si existe restricción o no, se toma generalmente a las 20:00 del día anterior, siendo efectiva a contar de las 07:00 del día siguiente.
Por tanto, los ciudadanos nos enteramos por las noticiarios la noche del día anterior (muy tarde), o en otros casos, apostamos a la "buena de Dios". Eso sin considerar los múltiples problemas domésticos para coordinar a última hora la logística de inicio del día (niños al colegio, transporte a la oficina, etc.)
Ya se había anunciado esta medida hace un mes por el Intendente. Y si bien es una solución parcial, es fácilmente mejorable, porque las primeras "barreras" ya fueron superadas: compromiso con prestar un mejor servicio. Veamos qué mejoras se pueden incorporar.
Pero antes, un poquito de teoría.
El modelo Pull
Las estrategias de servicio "Pull" son aquellas en las cuales el usuario "tira" del contenido, generalmente en modelos de autoconsulta. Es decir, el usuario actúa mediante un mecanismo de "polling" (de consulta periódica).
Ese es el modelo de operación tradicional al cual responden sistemas del tipo:
Una característica de este modelo es que el costo de la transacción es principalmente cubierto por el usuario (medido en tiempo y recursos de conexión), siendo responsabilidad del prestador de servicio la actualización del contenido y asumir el costo de la infraestructura base.
Si bien es un avance en el servicio, uno de los problemas que tiene este modelo es la alta cantidad de transacciones "fallidas", es decir, en las cuales el usuario realiza la transacción pero sin éxito, lo cual tiende en el largo plazo a desincentivar su uso. El costo recurrente de transacción fallida termina "frustrando" al usuario.
Por ejemplo, en nuestro caso del IVR para la restricción vehicular, probablemente será bastante utilizado durante un tiempo. Pero los casos en los cuales la información realmente "sea útil" (es decir, una llamada que realmente informe que me toca restricción), no compensará el costo recurrente en tiempo y dinero que deberé invertir, por lo cual buscaré alternativas o simplemente no lo utilizaré.
De hecho, es más fácil y "gratis", revisar la restricción en el sitio Web de algún periódico nacional o de la Oficina de Control de Tránsito, siendo mi inversión en tiempo y recursos "similar o menor" a la actualmente implementada.
El modelo Push
Las estrategias de servicio "Push" son aquellas en las cuales el prestador de servicios "empuja" el contenido hacia el Usuario, en aquellos casos en los cuales hay información que efectivamente sea de interés. Un ejemplo práctico son los correos electrónicos que recibimos de prestadores de servicio para enviarnos una cuenta o algún aviso.
Desde un punto de vista de sistemas, son modelos basados en "interrupciones" (es decir, actuamos en respuesta a un evento asincrónico).
Ese es el modelo de operación tradicional al cual responden sistemas del tipo:
Una característica de este modelo es que el costo de la transacción es principalmente cubierto por el prestador del servicio, quien se hace responsable de los costos de "enviar" el contenido.
Pero no siempre es así. Muchas veces el usuario estará dispuesto a "asumir el costo de transacción", siempre que el contenido "sea útil", ya que responderá a un evento sobre el cual efectivamente deberá ejecutar una acción. Para estos casos, en los cuales hay un costo por parte del usuario, se aplica generalmente un modelo de "suscripción OptIn" (es decir, el usuario acepta explícitamente el servicio). Y todas las transacciones "son útiles", por lo cual en la práctica, el costo y uso global de recursos del sistema es menor en un modelo Push.
Cuando no hay costo de transacción para el usuario (por ejemplo, para el correo electrónico hoy la percepción del costo de transacción es "cero") y en ciertos casos muy justificados, se puede "inscribir en forma automática". Y en caso de no desear continuar con el servicio, el usuario puede desuscribirse (mecanismo OptOut).
Pero ojo, hay que ser cuidadosos con la estrategia comunicacional y el modelo de servicios para el caso OptOut, porque hoy es fácil que se confunda con SPAM y termine generando una mala percepción en los usuarios.
En nuestro caso de la restricción vehicular, no hay modelo Push al menos en esta etapa. Y creo que incorporar en forma simple esos mecanismos, puede mejorar notablemente la calidad de servicio (y ayudar a la vida de los ciudadanos :-).
Combinando ambos modelos
¿Push o Pull, por cuál decidir? La respuesta no es generalizable, porque ninguno es mejor que otro. Simplemente son distintos y su aplicación dependerá fuertemente del modelo de negocios y aplicación. Y en las modernas implementaciones de servicio, la tendencia actual es combinar ambos modelos en forma armónica.
En el caso de la Web 2.0, lo interesante es que gran parte de su infraestructura de operación y servicios se basa en modelos Push.
Para nuestro caso particular de la restricción vehicular, mi recomendación sería:
En cuanto a los costos de implementación, con las plataformas actuales es mínimo y de fácil puesta en marcha. Un modelo Push en el cual el usuario defina las restricciones de la "alerta", asegurará un uso óptimo de los recursos en forma global: "aviso sólo cuando y para quien sea realmente necesario".
Y respecto a los casos de mensajería e-mail y SMS, estoy cierto que habrían múltiples compañías dispuestas a prestar este servicio en forma gratuita para la Intendencia y para los usuarios ... a cambio de permitir un pequeño espacio para publicidad. ;-)
Personalmente, no me aproblemaría en absoluto recibir un SMS avisándome de la restricción, donde el "costo" sea un pequeño mensaje de publicidad asociado. Win-win para todos.
Pero ese modelo de colaboración público-privado puede que sea demasiado avanzado, y probablemente la maraña de restricciones y licitaciones necesarias harían más difícil su puesta en marcha. Por último, para el caso de SMS, yo estaría dispuesto a pagar un costo mínimo por el mensaje, siempre y cuando sea realmente útil.
Veamos si esta idea prende.
Stay Tuned!
Leer artículo completo ...
Una innovación interesante incorporada este año en el concurso 
Feed de artículos
