Modelos -> Pull / Push
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 600 422 0000, 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:
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.
Contenido capturado de :::
http://blog.maz.cl/2008/07/push-vs-pull-un-cambio-de-mirada-en-el.html
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:
- Call Center para llamadas InBound (llamadas telefónicas generadas por el propio usuario)
- Sitios Web de consulta (sitios donde el usuario "va a mirar el contenido")
- Sistemas telefónicos tipo IVR (Interactive Voice Response, basados en interacción con los dígitos touch tone del teléfono)
- Sistemas de Autoconsulta (Kioskos de autoservicio o similares)
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 600 422 0000, 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:
- Llamadas telefónicas tipo OutBound (generadas desde un Call Center hacia el usuario)
- Correo Electrónico con mecanismos OptIn (donde el usuario se inscribe para recibir información)
- Avisos basados en mensajería corta (SMS para sistemas móviles)
- Agregación de contenidos mediante mecanismos RSS (aprovechando sindicación de contenidos)
- Sistemas de Microblogging (Twitter, Plurk)
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.
Contenido capturado de :::
http://blog.maz.cl/2008/07/push-vs-pull-un-cambio-de-mirada-en-el.html
posted by Roberto Riveros c. at 10:54 a. m.
0 Comments:
Publicar un comentario
<< Home