El problema de ir a la moda….

Posted by jmacias · 2 Comments 

Ya sabía que mi artículo sobre aplicaciones de Web vs aplicaciones tradicionales no iba a ser bien acogido, por que, mientras casi todo el mundo mira hacía aplicaciones web, reflexiono y justifico el seguir haciendo aplicaciones tradicionales.

Antes de nada, está claro que si vas a hacer un portal, un foro, o una red social tienes que utilizar tecnología web, pero si vas a hacer una aplicación de gestión, el photoshop, o una herramienta para grabar DVDs, las aplicaciones de escritorio, por ahora, son mejores.

En el año 2000, hacíamos aplicaciones web en ASP, desarrollé un framework, que permitía hacer aplicaciones en un tiempo casi igual que aplicaciones tradicionales, pero claro, con la limitaciones que teníamos entonces con los browsers, no obstante generamos algo similar a AJAX, y pudimos añadir bastante interación entre browser y servidor.

Por entonces, la empresa en el que trabajaba, encargo a una gran consultora que estudiara cual era el futuro de la tecnología web, y esa gran consultora dicidió que había que migrar a Java. Así que la empresa, empezó a mirar todo a JSP, por entonces dejé la empresa, no me apetecía abandonar mi know-how en ASP y tener que empezar desde el principio.

En el 2005 volví a la empresa, a incorporarme en uno de esos proyectos Java, durante esos años, habían migrado muchas aplicaciones a JSP, despúes las habían vuelto a migrar a Servlets, después a Webmacro y ahora volvían a cambiar para utilizar Struts.

En el 2007, nos pidieron que analizaramos las distintas tecnologías disponibles, por que se proponían a dar el gran paso y migrar una aplicación de más de 1000 pantallas, con un coste de unos 10 millones de euros. Durante el análisis, se propuso esperar a la nueva versión de Struts, a utilizar JSF, incluso volver a ASP.

A mi, me pareción una aberración ir a la “moda”, supongo que a día de hoy se están planteando utilizar AJAX, o incluso Ruby. Cuando hablamos de algo “tan grande” no podemos estar dependiendo de tecnologías que no están consolidadas.

Si nos fijamos como lo hacen los grandes como Oracle, SAP, etc… ellos tienen su propia tecnología, no dependen de la moda, en lugar de dedicar tiempo a programar en web, con struts, o con JSF, lo que hacen es definir su interfaz en un formato propio, y luego lo presentan en Web o en aplicación tradicional, o como quieran.

En software libre existe algo parecido, es llama XUL, lo utiliza por ejemplo Google en su software AdWords Editor.

Con la especificación de interfaz, independiente de la tecnología, nos aseguramos una evolución constante de nuestro software. No tenemos ni idea, de que estará de moda dentro de 3 años, lo mismo, AJAX desaparece……

Existen muchas aplicaciones OpenSource que utilizan tecnologías similares como OpenBrave, OpenErp, etc..

Así, que con este conocimiento, al empezar un proyecto, tengo varias alternativas:

  • Desarrollo en Web, sabiendo que estar a la moda tiene un coste extremadamente alto.
  • Desarrollo en XUL o tecnología propia, que tiene un coste alto inicial en desarrollo de frameworks, herramientas, etc…
  • Desarrollo en Escritorio, que tiene un coste muy bajo, que la tecnología ha madurado ya, y que no se esperan cambios radicales en los próximos años.

He optado por hacer aplicaciones de Escritorio, por tiempo y coste, en otra situación hubiera elegido XUL, pero nunca un desarrollo web.

El día del espectador del comercio electrónico

Posted by jmacias · 1 Comment 

Todos los negocios suelen mantener una estructura de gastos y personal más o menos fijas, pero siempre nos encontramos con días o periodos en los que las ventas bajan, de forma que empezamos a perder dinero. Los cines los llaman el día del espectador, normalmente el Miércoles, donde ponen ofertas para poder cubrir los gastos mínimos de apertura del cine.

Otros negocio optan por descuentos, ofertas, etc…. Pero en comercio electrónico este tipo de actuaciones puede ser peligrosa, si los clientes saben que un día a la semana es más barato comprar, pueden que muchos se esperen a ese día, no es lo mismo que elegir entre ir al cine entre un miércoles y un sábado.

En mi opinión, bajar los precios para atraer a más clientes, no es una medida “sana” para una tienda, acaba destruyendo la tienda a largo plazo. Hay otras medidas que se pueden llevar a cabo más efectivas, hoy vamos a explicar la recuperación de pedidos sin cerrar o carritos abandonados.

Las estadísticas indican que es posible recuperar un 5% de los pedidos abandonados, no obstante estos datos dependen de la razón de abandono del carrito.

Dependiendo de la razón de abandono, tendremos más o menos tasa de éxito, y por la tanto debermos aplicar más o menos esfuerzo en esa tarea. Para ello, sería necesario poder determinar hasta donde se ha llegado el cliente, de esa forma podemos intuir por que abandonó el carrito.

Vamos a ver un poco más en detalle donde están nuestros carritos abandonados:

Sin hacer checkout (cerrar pedido)

Mucha gente agrega productos al carrito, pero no tienen ninguna intención de hacer el pedido, simplemente están visitando, o buscando algo que no han encontrado. Con estos clientes, podemos hacer muy poco, pero no obstante, podríamos obtener cierta información de ellos. Si observamos que productos han agregado, podemos saber los intereses de esa persona, y enviarles mailings personalizados. Hemos obtenido menos de un 1% de efectividad, pero enviar un mail es gratis……

Abandono en la pantalla de gastos de envío/confirmación del pedido.

Muchos de los abandonos se producen cuando el cliente comprueba los gastos de envío, en España tenemos uno de los gasto de envío más caros de toda Europa, esto, unido al desconocimiento general sobre los gastos de envío, hacen que mucha gente pueda pensar que los gastos de envío son excesivos.

Para estos pedidos, podemos lanzar una oferta reduciendo los gastos de envío, algo como: “Sólo hoy, gastos de envío 1.99€”

Abandono en la pantalla de forma de pago

El abandono en la pantalla de forma de pago, suele estar asociado a la confianza en la tienda, sobre todo si sólo tenemos pago por transferencia.

Una forma de recuperar estos pedidos, es enviar un mail intentando ofrecer confianza al cliente, por ejemplo indicandole el teléfono de atención al cliente, localización de la tienda física, apariciones en prensa, etc..

Abandono en el pago con tarjeta

Una de las situaciones más frustrantes para un comprador, es que el pago con tarjeta falle. El supermercado de Carrefour, tiene uno de los sistemas de pagos peores que he visto.

Sobre todo, los problemas ocurren cuando la tienda sólo soporta VISA Secure, mucha gente no tiene este tipo de tarjetas y suele abandonar la compra.

Es una lástima desperdiciar estos pedidos, pero recuperarlos puede resultar complicado. La mejor solución es ponerse en contacto con los clientes para ayudarlos a realizar el pago o elegir otra forma de pago, como transferencia o reembolso.

Otra sólución es permitir cerrar el pedido sin realizar el pago, y permitir al cliente que realice el pago más tarde. Esto requiere una modificación de nuestro software de tienda.

Resumen

Recuperar los pedidos sin cerrar es realmente útil, pero actualmente, es muy complicado encontrar software preparado para ofrecer la información necesaria. Si logramos integrar en nuestro sistema la información necesaria, podemos tener un buen número de pedidos recuperados, ideales para fechas en las que se esperar un movimiento mínimo de pedidos.