Archivo de la categoría: Ventas

Cómo construir un eCommerce Singular. Capítulo 2, El Monolito

Publicado el por

Aunque es verdad que a veces hacer las cosas mal cuesta más que hacerlas bien, nadie se propone de manera consciente construir un sistema de software que sea ineficiente o inmantenible. Simplemente, pasa. Algo se desarrolla pensando en resolver un problema; pero el problema va cambiando, o creciendo; y entonces se van añadiendo nuevos módulos, nuevos componentes, o se añade funcionalidad sobre algo que ya existía, y la cosa se termina por complicar.

Frankenstein, o el Nuevo Monolito

Un sistema de software donde todos sus elementos están fuertemente acoplados y además está autocontenido y se ejecuta como un sistema único puede llegar no sólo a ser difícil de mantener y evolucionar, sino que también podría no ser capaz de mantener su rendimiento y eficiencia cuando aumenta su uso y por tanto las interacciones, lo que viene conociéndose como escalar.

El concepto de acoplamiento en términos de ingeniería del software hace referencia a la dependencia que tienen diferentes partes de un sistema, a la hora de realizar la función para la que fueron diseñadas. Aunque es normal que cuando se construye un sistema, haya partes que necesiten de otras para realizar ciertas tareas, la forma en que esta dependencia se construye podrá hacerse con mayor o menor acoplamiento. Por ejemplo: el caso de un formulario en una web que acaba insertando información en una base de datos. Puede hacerse con cierto desacoplamiento cuando los datos de los formularios viajan por diferentes capas / componentes que los piden, los recogen, los validan y los procesan cada uno como corresponda; o muy acoplada cuando un único componente coordina la operación, y le va pasando al resto no sólo los datos, sino instrucciones sobre qué hacer con ellos y cómo hacerlo.

Monolito Obelix

UX Designer FullStack Developer DevOps as a Service

Tradicionalmente, se define un sistema Monolítico como aquél en el que todas las capacidades de representación, procesamiento y almacenamiento están entrelazadas, y son gestionadas como una única unidad de ejecución, prevista para correr en un único servidor. Es decir, una única aplicación contiene y es responsable de todas sus funcionalidades.

Hay muchos motivos por los que alguien acabaría teniendo un sistema Monolítico. Estadísticamente yo diría que de menor a mayor probabilidad, serían cuatro.

Primer motivo: porque alguien lo habría diseñado así intencionadamente.

En esta categoría podemos meter por ejemplo el llamado “Majestic Monolith” (no hace falta traducción) de Basecamp. En un artículo de 2016, David Heinemeier presenta el concepto Majestic Monolith para referirse a la forma en que Basecamp está construida. Los conceptos subyacentes a esta decisión de arquitectura son: eliminar abstracciones innecesarias, y hacer distribuidas únicamente las partes del sistema necesarias. Básicamente defiende que es la mejor alternativa en el escenario de un equipo reducido de desarrolladores (12), con experiencia y criterio, que conocen y entienden el código del sistema; código que se ha escrito con criterios de simplicidad, limpieza y orientación a la prueba. Teniendo en cuenta que este hombre creó Ruby on Rails, parece que es una decisión razonada que le permite mantener y evolucionar un sistema que en 2018 tiene más de 2,8 millones de cuentas registradas, accesible desde 6 plataformas.  

Segundo motivo: porque estaba mal diseñado.

Asumamos como cierto que las personas que han estudiado una carrera de informática (técnica o superior; en la universidad o en la FP, o como se llamen ahora respectivamente, que yo no estoy muy al día) han recibido los conceptos y bases necesarios para diseñar arquitecturas de software. Asumamos también como cierto que otras personas que no han estudiado en las universidades o centros de formación profesional pueden adquirir conocimiento a partir de la experiencia, la lectura de documentación y el aprendizaje autodidacta o desde un referente. Asumir estos planteamientos significa partir de la base de que las empresas ponen a diseñar arquitecturas de software a personas que saben como hacerlo, que han leído, conocen patrones de referencia, y quieren hacer bien su trabajo.

Sin embargo, shit happens. Como decía al empezar este post, no creo que nadie diseñe de manera consciente sistemas para que sean ineficientes o no escalen; simplemente a veces se toman las decisiones erróneas. En 2013 tres investigadores de la universidad de Groningen (Holanda) D. Tofan, M. Galster y P. Avgeriou publicaron un paper en el que analizaban las causas por las que un Arquitecto de Software llegaba a tomar malas decisiones a la hora de plantear una solución técnica.

D. Tofan, M. Galster y P. Avgeriou, ECSA 2013

Como resultado del estudio, llegaron a varias conclusiones, aunque a lo mejor no todas sorprendentes e inesperadas:

  1. El principal motivo que lleva a tomar decisiones erróneas a la hora de hacer una arquitectura de software es la dependencia con otras decisiones ajenas a la decisión técnica en sí; seguido por el impacto que una decisión a priori técnica tenía en el negocio. Es decir, al propósito por el que se está construyendo el software en la organización, en el caso de un eCommerce: ganar dinero vendiendo cosas por internet.
  2. Por el contrario, que hubiera demasiadas alternativas o muchas personas en el proceso de toma de decisión no se consideraban motivos relevantes de un diseño mal planteado.
  3. Existe una diferencia entre los motivos que detectan los arquitectos de software según su experiencia. Los que tenían menos de 5 años de experiencia consideraban problemático tener que enfrentarse a criterios y recomendaciones contradictorias a la hora de tomar una decisión, y que cuanto más había que pensar, más difícil les resultaba decidirse. Por el contrario, los arquitectos de software con más de 5 años de experiencia no daban importancia a estos conceptos, sino al tema del contexto y el negocio (lo cual hace inevitable resucitar la paradoja del Arquitecto de Software Junior)
  4. El tiempo medio que se se consideraba necesario para tomar las decisiones de diseño de una arquitectura de software era de 8 jornadas de trabajo. Paradójicamente, el estudio también apunta a que los arquitectos de software con menos experiencia tardaban la cuarta parte en tomar decisiones de diseño (de ahí el refrán acerca de la ignorancia y el atrevimiento)

Tercer motivo: porque estaba bien diseñado, pero en algún momento las cosas se torcieron.

Se que al final se me hacen unos post muy largos, que a veces abro muchos temas y demás, pero es que hay que hablar de la deuda técnica. Más allá de que nos guste más o menos el término, o su sentido; en el contexto de este post voy a usarlo porque me parece la forma más universal de hacer referencia a la degradación que sufren los sistemas durante su desarrollo y evolución. Puede que se partiese de un sistema bien definido y planteado, pero con el paso del tiempo la aplicación acaba siendo ponzoña. ¿Por qué? De nuevo, es algo que nadie quiere que ocurra de manera intencionada, yo creo en la buena fe de las personas. Pero ocurre.

Por lo general, el código de un sistema se degrada poco a poco, como respuesta a situaciones del tipo “me ha quedado complicado, pero ya lo arreglaré más adelante”, “no tengo tiempo para hacer las pruebas”, “este fallo debe ser un Expediente X, porque suele funcionar”, etc.

En 2015, Neil Ernst del Software Engineering Institute de la Universidad Carnegie-Mellon publicó un estudio / paper sobre los motivos de por qué sucede esta degradación. Os comparto la gráfica que me parece más relevante. Es bastante auto-explicativa, la verdad.

Neil Ernst, SEI 2015

Cuarto y último motivo: porque no sabía que se lo estaba comprando.

Creo que es lo más normal, y suele pasar cuando alguien compra un producto mirando los Cuadrantes que publican los analistas de negocio, o porque nobody ever was fired for buying IBM, o porque las demos de jugar estaban bien, etc. En lugar de hacer una due diligence tecnológica como Dios manda.

¿Qué hace aquí este Monolito?

El esfuerzo e interés por desarrollar aplicaciones desacopladas no es algo nuevo, y forma parte del corpus teórico de la ingeniería del software desde sus inicios. En el caso que nos ocupa en este contexto, que es el eCommerce (algo inherentemente ligado a la Web y en los últimos años al móvil) las arquitecturas en tres capas (presentación, lógica de negocio y datos) y el Patrón Model-View-Controller han sido la forma habitual de construir sistemas con bajo acoplamiento.

No sólo desde el punto de vista de la construcción, ya que al separar de forma conceptual las distintas partes del sistema es más fácil actuar sobre ellas; sino desde el punto de vista de la infraestructura que las soporta, con el objetivo de mejorar el escalado y el rendimiento. Poder empaquetar y desplegar cada una de las capas en servidores diferentes permite al sistema escalar de manera independiente cada capa cuando se producen los picos de acceso al sistema (cuando hay ventas privadas, o campañas como Rebajas, San Valentín, Navidades o el Black Friday) Por eso es bastante habitual ver infraestructuras donde se ha separado la parte de presentación en unos servidores optimizados para servir el front, complementados con un CDN para los estáticos (las imágenes, vídeos, etc), la parte que hace la lógica de operaciones en servidores de aplicación, y otra capa con la base de datos en alta disponibilidad.

Monolito Scrum

El equipo Scrum hace sus dailies frente al Monolito

Sin embargo, dejadme que os diga que la primera referencia a patrón MVC se remonta a finales de los 70. Y la idea de crear una arquitectura en 3 capas para construir aplicaciones cliente / servidor es de mediados de los 90. Así que, ¿a qué nos referimos hoy en día cuando se habla de un Monolito? Porque es lógico suponer que la mayoría de los eCommerce Singulares, que es de lo que va esa serie de posts, se han construido bien sobre plataforma, bien a medida, siguiendo arquitecturas y patrones que desacoplan al menos las capas de presentación-negocio-datos.

Bien. En primer lugar, aunque la tienda como tal esté desarrollada en 3 capas, puede que la capa de lógica de negocio (o back-end) se haya construido como un Monolito. Significaría que es un bloque único que recibe las peticiones de la parte del cliente (web o móvil o por qué no, un botón IoT), hace cierta lógica (como una búsqueda de productos según un criterio,  o añadir un elemento al carrito) y genera la información que se renderizará en la capa de presentación a modo de respuesta. Entendido de esta manera, el servidor puede estar construido de manera modular, con sus elementos desacoplados en paquetes y clases, de forma que tenga su componente de carrito, otro de catálogo, etc. Pero lo cierto es que al final todas importarán las mismas librerías con las mismas dependencias, compartirán el mismo modelo de almacenamiento de datos en sesión, y  la misma política de persistencia.

También el back-end de la aplicación puede considerarse un monolito si se empaqueta como un único artefacto. Podría llegar a desplegarse en varios servidores, lo que le permitiría escalar en caso de aumento de peticiones. Pero es una única unidad lógica; de forma que en caso de ser necesario hacer una modificación, hay que volver a compilar, empaquetar y desplegar toda la parte servidora, haya o no sido actualizada. Y una vez que se empaqueta, la misma versión es la que se despliega (y por tanto se ejecuta) en todos los nodos de la infraestructura. Al hacer el despliegue, aunque sea por nodos, es necesario reiniciarlos. En la medida en que haya un entorno distribuido con alta disponibilidad y persistencia compartida de sesiones, los usuarios podrían no verse afectados; sin embargo, tareas programadas o procesos de sistema (como sincronizaciones de inventario, confirmaciones de pago, o envío de newsletters) que estuvieran ejecutándose, se perderían. Por eso muchas veces hay que hacer las actualizaciones de manera programada, lo que es una barrera para llegar al despliegue continuo.   

Y el artefacto que se despliega en cada nodo, se ejecuta en un mismo entorno, compartiendo la misma configuración y el espacio de memoria y en general, los recursos del nodo. Cuanto más pesado sea, más tiempo tardará en arrancar y mayores recursos necesitará. Por tanto, todos los servicios o end-points del artefacto están replicados por igual en cada nodo y acceden a los mismos recursos del sistema, con independencia de la frecuencia con que se usen para resolver las tareas del sistema. En todos los servidores se ejecutan réplicas idénticas del back-end, capaces de hacer las mismas operaciones de lectura y escritura contra la base de datos; por tanto lo normal es que escalar la capa de negocio conlleve escalar la capa de datos.

Cuando alguna de las partes de tu sistema se ha convertido en un Monolito lo normal es que tengas algunas desventajas, que veremos a continuación.

Cosas malas que pasan cuando tienes un Monolito

Desde el punto de vista del desarrollo, cuando todo el back-end de una plataforma (y en este artículo estamos hablando de un eCommerce Top 100) está construido como un Monolito, se producen unos efectos indeseables que impactan en la productividad y eficiencia del equipo. ¿Por qué?

Porque todo el equipo de desarrollo del back-end trabaja sobre el mismo artefacto. Cuando hay demasiada lógica de negocio en la misma capa, es normal que se rompa la modularidad de los componentes con el paso del tiempo, conforme se van haciendo extensiones del producto, o se corrigen errores. Por ejemplo, añadir un nuevo medio de pago a un eCommerce puede afectar: al módulo desde el que se procesan los pagos, al que renderiza el selector de medios de pago durante el proceso de checkout, al que gestiona el medio de pago favorito en el perfil del usuario (necesario para los one-click-payments), etc. Eventualmente llega un momento en que el sistema es una maraña y es costoso tener una visión global de cómo funcionan las cosas.

Como además el back-end es un único componente que se carga completamente, los entornos de desarrollo son cada vez más costosos de arrancar, se tarda más tiempo en compilar y en ejecutar y depurar en local. Esto hace que cada vez los ordenadores para el desarrollo requieran mayores prestaciones; algo que no siempre es posible conseguir porque puede llegar a  chocar con las políticas de actualización de los departamentos de tecnología, o los responsables de compras. ¿Alguna vez habéis visto a personas cronometrando cuánto tiempo tarda en arrancar el Eclipse, o cuántas horas pierde al día mientras espera en las compilaciones? Yo sí, y es muy lamentable.

Un back-end que acaba siendo un Monolito hace que todos sus componentes y módulos que se despliegan como un mismo artefacto, estén ligados a un lenguaje de programación específico, y a unas determinadas versiones no sólo del framework de desarrollo, sino de las librerías que se importan. Los cambios de versiones son más costosos, porque se hace necesario validar el impacto que puede tener el cambio de librería en todo el sistema como un conjunto (en lugar de en partes concretas donde el cambio puede tener más sentido). Eso por no hablar de cambiar de stack tecnológico. Un proyecto de refactorización de un sistema para ir aliviando la deuda técnica, puede ser una inversión en tiempo y dinero difícil de justificar ante el responsable de asignar recursos económicos a los proyectos.

Monolito Asuán

Antes de levantar este monolito de 36m y 150 toneladas se rompió la build. Por eso se llama El Obelisco Inacabado de Asuán

A la larga, todo esto unido significa que se incrementa la curva de entrada de las nuevas incorporaciones al equipo, con lo que aumenta el tiempo que necesita una persona para hacer trabajo productivo. Cuando el tamaño del equipo de desarrollo alcanza un nivel importante, y estamos hablando de un eCommerce Top 100 (no de la demo de la tienda de mascotas), aumenta el esfuerzo de coordinación de los diferentes subproyectos / extensiones que se van haciendo en paralelo. Esto puede llegar a hacer difícil segregar las responsabilidades de los diferentes equipos, y por tanto su autonomía e independencia; y complicar el modelo de gestión de los diferentes proyectos / equipos. Podemos añadir a esta ecuación que las personas pueden estar distribuidas en diferentes localizaciones, cosa habitual en los tiempos que corren.

Desde el punto de vista del delivery, actualizar un sistema Monolítico requiere recompilar toda la aplicación, volver a empaquetarla y redespeglar. Al ser una sola pieza, hay que parar todo el sistema por completo para hacer la actualización.

Además, si llega el caso en que el sistema tiene que escalar, es necesario hacer que escale todo el monolito al completo; en lugar de aumentar la capacidad de aquella parte del proceso / operación que realmente lo necesita. Lo que lleva a aumentar la capacidad (procesamiento, memoria, almacenamiento) del servidor en el que corre, y podría no ser la estrategia de infraestructura más óptima en términos de inversión.

Finalmente, una vez que empiezan a dar servicio, en caso de que se produzcan errores, el proceso de depurarlos e identificar dónde se está produciendo el error puede llegar a ser complejo debido al acoplamiento. Es cierto que desde hace años (de cuando yo programaba) ya están inventados los IDE de desarrollo que se conectan a un servidor y permiten hacer depuración en tiempo real, y esto ayuda a encontrar los errores. Sin embargo, cuanto mayor sea el acoplamiento, y más pesado el entorno de desarrollo y sus dependencias, más implicaciones puede tener encontrar y depurar un error, corregirlo y validar la solución, por el efecto secundario que pueda tener en otros componentes.

Cuando existe fuerte acoplamiento entre los elementos de la aplicación, lo normal es que no se haya logrado separar operaciones y reutilizar código. De forma que cuando hay que modificar o corregir cualquiera de sus funcionalidades, se requiere primero entender cómo el cambio puede afectar a sus diferentes partes; y lo que es peor, identificar todos los puntos en los que se tendría que replicar la actualización.

¿Entonces?

Esta casuística la comparten centenares de plataformas y sistemas de software; y la extienden a los centenares de miles de sites de comercio electrónico por todo el mundo construidos sobre ellas. Podríamos pensar que tampoco pasa nada, que no van a morir niños de hambre en el Tercer Mundo, ni vamos a prolongar el Cambio Climático (y eso sí que son problemas de verdad).

Monolito Obelix Happy

Pues me siento más ligero sin mi Monolito

Recordemos: estamos hablando de construir un eCommerce Top 100, uno que se espera que sea referente de su sector porque lo va a construir una empresa líder. Si a tu eCommerce le vas a exigir facturar millones de euros al año; operar en decenas de países; recibir miles de peticiones concurrentes de personas de todo el mundo; conocer en tiempo  real el stock de artículos y tallas; y cerrar procesos de compra con seguridad. Y por qué no, conseguir finalizar las transacciones en ese milisegundo que es la diferencia entre comprar o quedarte sin stock.

Hoy en día tiene cierta madurez y solvencia la aproximación tecnológica que permite dividir el back-end de la aplicación en partes más pequeñas, especializadas en hacer una única tarea, cada una con su propia capacidad de desarrollarse, desplegarse y escalar por separado. Con su propia arquitectura, consumiendo los recursos que necesita, y gestionando únicamente aquellos datos sobre los que tiene responsabilidad. Pero antes de hablar sobre cómo materializar este planteamiento en una arquitectura de microservicios, habrá que saber cuáles son los elementos que tiene que tener un eCommerce Top 100. Y eso lo veremos en el siguiente capítulo.

(Continuará…)

(Espero que antes de 6 meses)

Cómo construir un eCommerce Singular. Capítulo 1, El eCommerce Top 100

Publicado el por

Introducción

Comienzo aquí una serie de posts sobre cómo construir un eCommerce Singular, candidato a estar en un listado de Top 100, utilizando una arquitectura de microservicios. Son dos de los temas a los que dedico mi atención últimamente en Sngular. En cierta medida es normal: por una parte Sngular es una empresa que lleva construyendo tiendas online prácticamente desde sus orígenes como MediaNet, a mediados de los años 90. Algunos de los proyectos que hemos hecho son www.lolamarket.com , el caso de ModeloNow de Grupo Modelo (ahora https://www.pepedelivery.com/), https://www.cuidadoconelperro.com.mx/ y sus dos millones de fans en Facebook, cuando hicimos Planeo.com del Grupo PRISA, y por encima de todos ellos, el caso de BuyVIP y su posterior adquisición por Amazon. Por otra parte, porque los compañeros del área de Arquitectura llevan ya unos años construyendo soluciones basadas en microservicios. Empezamos en entornos de banca, pero la realidad es que se trata de una aproximación que cada vez tiene más adopción a la hora de construir grandes sistemas distribuidos, que gestionan miles de transacciones al día y que tienen que responder y escalar ante picos de carga.

Total, que me parecía interesante compartir algunas reflexiones. El hilo argumental que voy a seguir se materializa en los siguientes capítulos:

  • ¿Qué es un eCommerce Top 100 y por qué hay que hacerlo a medida? Donde vamos a repasar los diferentes tipos de sites de eCommerce que construimos en Sngular, los criterios de cualificación con los que los clasificamos, y sobre todo, qué es lo que nosotros consideramos un eCommerce Singular. Aprovecharé para compartir algunos datos que me parecen relevantes a la hora de enunciar nuestra definición, y que además, son la clave de la argumentación de los 3 motivos por los que siempre vamos a recomendar hacerlos a medida.
  • El bloque Monolítico. Una de las principales áreas de trabajo y evolución de la disciplina de la Arquitectura de Software es la creación de sistemas desacoplados, que combinen la eficiencia en el consumo de recursos para producir resultados, la capacidad de escalar ante los picos de carga del sistema, y que puedan ser extendidos y mantenidos por un equipo de desarrollo. Desde los años 90 existe el patrón de 3 capas (presentación, negocio y datos) que aplican todos los eCommerce del mundo, pero un back-end puede terminar por convertirse en un Monolito, y eso podría ser una barrera para el crecimiento / rendimiento de un eCommerce Top 100. Por cierto, que hay empresas como Basecamp o Etsy que defienden sus arquitecturas de Monolito Majestuoso; también hablaremos sobre ello en los Apéndices.
  • Los elementos de un eCommerce. Para crear una arquitectura de referencia de microservicios sobre la que construir un eCommerce Singular, hay que tener una idea de los elementos estarán presentes en la tienda online. En este capítulo haremos un benchmarking de sites que servirá posteriormente como base para plantear la arquitectura. Me refiero a aspectos como la gestión de múltiples países, el registro de usuarios, el catálogo, las páginas de producto, las recomendaciones, el proceso de checkout, el pago en one-click, la integración de medios de pago, etc. Para escribir sobre esto intentaré engatusar a Farid Fleifel y Javier Cuervo.
  • Arquitectura de Microservicios de Referencia. Donde se presentará un modelo de arquitectura que contenga los elementos descritos anteriormente, y un planteamiento de muy alto nivel sobre qué tecnologías utilizar para construirlos. Se que muchos pensaréis que qué coño voy a contar sobre esto si la última vez que abrí un Eclipse fue en 2009, pero no os preocupéis porque en este capítulo espero contar con la visión de César Camargo, Eugenio Concepción, Iñaki Reta, Daniel Castilla, y el resto de compañeros del equipo de Arquitectura de Sngular. (Puede que os parezca un truco sucio dejar sus nombres por escrito, pero así es la vida¯\_(ツ)_/¯  )
  • ¿Cómo hacer la transición? En el último capítulo haremos una pequeña revisión de diferentes estrategias para hacer la transición de un sistema a una nueva arquitectura de microservicios, sin pérdida de continuidad del negocio (sin dejar de vender, vamos). Lo que viene siendo el símil de cambiar el motor del avión en pleno vuelo.

En fin, es un reto ambicioso porque me salen unos cuantos posts. Pero bueno, lo mejor es empezar por el principio. Así que vamos a ello. Espero que os parezca interesante 😉

Capítulo 1. ¿Qué es un eCommerce Top 100 y por qué hay que hacerlo a medida?

Estoy en condiciones de afirmar, sin posibilidad de error (incluso con apuesta de pincho de tortilla y caña) que en todas las reuniones en las que he estado donde una o más personas querían crear un modelo de negocio de eCommerce, siempre ha salido la pregunta del millón. Y contra todo pronóstico, la pregunta del millón no es “¿qué tengo que hacer para vender mi primer millón de euros online?”, sino “¿esto se hace con una plataforma o se desarrolla a medida?” La siguiente pregunta es “¿y cuánto va a costar?”.

En Sngular, como somos gente muy práctica y además transparente, estudiamos cada caso y hacemos una recomendación basada en la necesidad, el escenario y en general todas las condiciones de contorno del caso del cliente. Esto siempre gira en torno a las dos Cs Elementales del eCommerce. La primera es la de la Cualificación del tráfico y la segunda la de Conversión. El propósito de cualquier plataforma que se construya debe ser la de convertir tráfico cualificado en ventas de productos de calidad, y eso se consigue a través del diseño de una experiencia de compra construida sobre una plataforma tecnológica. Hay otros elementos del círculo virtuoso del eCommerce, como es la capacidad de hacer la entrega de los productos, y el servicio post venta que se da al cliente. Todos son importantes para lograr el éxito.

Pero lo más importante desde nuestro punto de vista es que una tienda online, es un modelo de negocio de base tecnológica. Es decir, la tecnología es una condición necesaria (pero no suficiente) para el negocio: para que funcione y crezca. Dicho lo cual, en nuestro árbol de decisión, existen cuatro categorías de eCommerce.

En el escalón más básico está el eCommerce MVP (de Minimun Viable Product) que refleja aquellas situaciones donde se está creando un modelo de venta estándar que incluye las 3 Cs Básicas del eCommerce (Catálogo, Carrito y Check-Out), en una compañía 100% online (es decir, no hay venta física), que inicia una etapa exploratoria de la viabilidad de su idea con un catálogo de productos reducido. Aquí nuestra recomendación es concentrarse en validar la idea negocio lo antes posible, con una inversión acotada. Por eso apostamos por plataformas tipo Shopify (un eCommerce as a Service) o WooComerce (que por resumir, es una extensión de WordPress) En un eCommerce MVP el rango de inversión inicial empieza en torno a los 16 o 20K y puede llegar a los 50K sólo en tecnología (es decir, sin contar otras inversiones necesarias como el sourcing o campañas captación de tráfico, etc), y un time to market que no supera las 6 semanas. Es una inversión pequeña, como pequeño es también el control que se tiene sobre la solución. Lo importante en este caso es validar el modelo con una inversión que si no cubre la expectativa no suponga grandes pérdidas; pero que si se demuestra que el modelo de negocio es viable, se pueda tirar a la basura sin gran tristeza, y pasar al siguiente escalón.

Ese sería el de un eCommerce Standard, aquellos casos en los que existe un catálogo con más o menos cierta profundidad, en un modelo de venta que empieza a considerar las 2 Cs Adicionales (Consejos y Comentarios) para incrementar el ticket medio y la fidelización de los usuarios. En este escenario, el promotor no necesita validar la viabilidad de su idea, porque ya se sabe que lo es; y tiene prevista una inversión moderada en un horizonte temporal de medio plazo (1 o 2 años). Nuestra recomendación es ir o bien a una plataforma estándar tipo Magento / Prestashop o construir sobre nuestra plataforma Sngular Billionlabs basada en PHP Laravel. La decisión fundamentalmente depende de las integraciones a realizar, de cómo se espera abordar la omnicanalidad, y en general de hasta qué punto se quiere o necesita construir sobre la plataforma para lograr materializar el site. Cuanto más estándar sea, más fácil es que se pueda construir sobre una plataforma de mercado; sin embargo, la particularidad del modelo, o del diseño, o de las integraciones pueden marcar la diferencia entre construir sobre plataforma de mercado y re-construir una plataforma de mercado. Por lo general, re-construir la plataforma es una mala idea, se pierde la continuidad con futuras versiones, aumenta la complejidad del mantenimiento y la extensión, y se acaba con un bonito Frankenstein. Si en tu horizonte te ves con un Frankenstein, lo mejor es que te plantees un desarrollo a medida desde el principio. En este tipo de eCommerce, la inversión sólo en tecnología puede empezar en el rango de los 60K-80K anuales y llegar a los 100K-120K. En cuanto al time to market, ya varía entre usar plataforma o desarrollo a medida, sin embargo nuestra experiencia nos dice que a partir de la semana 8 ya es posible tener una primera versión lista para empezar a vender online, en un proyecto que con entregas iterativas puede llegar a las 16 semanas.

eCommerce Usage Stats

Estadísticas de plataformas de eCommerce según datos de https://trends.builtwith.com/shop

 

El tercer escenario es el eCommerce Pro, el de empresas en un importante nivel de madurez que apuestan por el online como una fuente de ingresos relevantes dentro de un plan de negocio en varios países. En este caso el nivel de adaptaciones específicas es cada vez mayor, sobre todo con la integración de otros sistemas corporativos. Este tipo de proyectos tienen previstos fuertes inversiones no sólo en tecnología, también en captación de tráfico para el site. El catálogo de productos es relevante, el modelo online incluye todas las Cs del eCommerce habidas y por haber; y otros aspectos como la gestión de inventario (que puede estar distribuido) y logística de entrega (donde puede haber diferentes proveedores) o medios de pago (incluyendo por ejemplo diferentes plataformas para cada país) tienen mayor peso. Hay además una necesidad fuerte de integración de sistemas existentes (propios o de terceros), y el site forma parte de una estrategia omnicanal donde el cliente puede llegar a interactuar con la marca y el producto en tiendas físicas, en el online, en el móvil, etc. En este caso, la recomendación de Sngular es ir con grandes plataformas como Hybris / Oracle ATG / IBM Websphere según lo aficionado que uno sea a dejarse guiar los Gartner y Forrester de turno, o hacer un desarrollo completo a medida.

En general, si la tienda online requiere integrar un elevado número de sistemas legacy para procesar las operaciones; o está concebido como una plataforma en la que acceden diferentes terceros; o el modelo de negocio no encaja al 90% con el estándar de una plataforma, nuestra recomendación es un desarrollo a medida.

En un eCommerce Pro, el rango de inversión empieza en los 120K-160K anuales sólo en tecnología, y puede llegar al millón de euros cuando empezamos a meter licencias e infraestructura. En estos escenarios hay mayor variabilidad en el time to market, si bien es razonable pensar que en el mes 4 puede haber una plataforma bastante parecida al resultado final, sobre que la que se puede seguir iterando ampliando funcionalidades hasta los meses 6-8.

 

 Gartner Magic Quadrant Digital Commerce 2017  Forrester Wave Report for B2C eCommerce, Q1 2017
Gartner Magic Quadrant to Digital Commerce, April 2017 Forrester Wave Report for B2C eCommerce, Q1 2017

eCommerce Singulares según Sngular

Por último tenemos la joya de la corona. Esos que llamamos los eCommerce Singulares. La clase de eCommerce que siempre recomendaremos construir a medida, porque nuestro cliente quiere entrar en el Top 100. Para lograrlo es posible que haya que dar respuesta la creación de un modelo de venta propio, clave para la ventaja competitiva y por tanto, no cubierto por ninguna plataforma estándar. En este caso estamos hablando de inversiones por encima de los 250K sólo en tecnología el primer año, que pueden empezar directamente en los 400K-500K.

 

 DigitalCommerce360 Top500 USA DigitalCommerce360 Top500 Europa

DigitalCommerce360 Internet Retailer Top500 Report (USA y Europa)


Los datos que publica DigitalCommerce360 son muy interesantes, muestran que el 41% de los Top 100 eCommerce de Estados Unidos desarrollan a medida su tienda online. Este dato sube hasta el 58% si lo filtramos al Top 100 eCommerce en Europa. Amazon, Alibaba o Rakuten, los gigantes del eCommerce mundial, han desarrollado a medida sus plataformas (propias, que luego abren a terceros o incluso permiten que se construya sobre ellas). Si miramos la lista de los principales eCommerce de Estados Unidos, podemos comprobar que todos han desarrollado su propia plataforma de comercio electrónico, y de hecho en algunos casos como Amazon.com o Wal-Mart la han abierto a que otras empresas puedan construir con ellas.

Facturación del Top5 eCommerce US en 2016 (Fuente: WWD)

Facturación del Top5 eCommerce US en 2016 (Fuente: WWD)

El eCommerce Singular siempre hay que hacerlo a medida

Nuestra recomendación para crear un eCommerce Singular es siempre el desarrollo a medida. Para conseguir un eCommerce que entre en el Top 100 tienes que mantener el liderazgo estratégico frente a tu competencia, tener el control sobre tu plataforma, y evitar el vendor lock-in;

  • Liderazgo estratégico. No se puede condicionar en ningún caso la implementación de una estrategia de comercio online a las capacidades o features de una plataforma, y mucho menos al roadmap de evolución que haya decidido un fabricante. Esto es fundamental: ser un eCommerce Top 100 significa innovar, liderar y estar por delante de los competidores. Construir sobre una plataforma implica tener los mismos niveles de libertad y las mismas funcionalidades que el resto de tus competidores que la usan. Crear tu propia plataforma te permite construir tu propio liderazgo.
  • Continuidad del producto. Construir extensiones o adaptaciones sobre una plataforma propietaria no evita una inversión elevada, por la especialización de las personas que tienen certificados los conocimientos para hacer las extensiones o adaptaciones sin que impacten en el rendimiento o escalabilidad. Sobre todo, tampoco garantizan que ante una nueva versión del core de la plataforma las extensiones vayan a seguir funcionando. Tu propia plataforma puede evolucionar y re-evolucionar según tu necesidad.
  • Vendor lock-in. Utilizar tecnología propietaria, es decir, no estándar, siempre tiene asociado el riesgo de convertirse en una relación asimétrica, en la que el proveedor tiene un papel dominante sobre el cliente, llegando incluso a coartar su independencia. El temido vendor lock-in. Construir una plataforma según tus propias especificaciones usando tecnología estándar y abierta te permite crear tu propio equipo de desarrollo in-house, o abrir el desarrollo de forma transparente a un amplio abanico de proveedores.

En general, una plataforma a medida permite tener el control absoluto sobre el modelo de negocio, la experiencia del usuario, la tecnología y su evolución.

Categorías eCommerce Sngular

Las cuatro categorías de eCommerce tal y como las concebimos en Sngular

 

De cualquier manera, supongamos que tienes un eCommerce Top 100 construido sobre una plataforma de terceros, que ha ido evolucionando con integraciones y extensiones. O que es un desarrollo a medida hecho entre 2010 y 2015 (me resultaría difícil pensar que a día de hoy alguien está vendiendo como churros algo en internet con un desarrollo de hace más de 8 años) Puede que esté desplegada en la nube de Amazon AWS o de Microsoft Azure; de cualquier manera, seguramente lo que tienes es, como se dice en el ámbito del software, un Monolito.

Y si estás en el momento de rehacer tu eCommerce, o tienes luz verde para crear un nuevo eCommerce Top 100, lo que deberías evitar es ponerte a construir un Monolito. Pero, ¿qué es eso del Monolito?

(Continuará…)

Elogio del Vendedor

Publicado el por

¿Por qué ocultar que vendemos?

Estamos en el año 2017 y, por extraño que parezca, hay personas que siguen pensado que un comercial es un tipo graciosete que le cae bien a la gente y habla mucho. Por eso a veces (para que deje de molestar) alguien le da una propina y en paz. Los que en 1990 nos acabamos el Monkey Island ya sabemos que ese personaje se llama Stan, y es un poco lamentable.

Después, Gordon Gekko (Wall Street), el señor Blake (Glengarry Glen Ross) y Jordan Belfort (exconvicto en la vida real) nos enseñaron que un buen vendedor es una especie de vikingo hipercompetitivo capaz de manipular, estrujar, triturar y dominar a sus clientes y humillar a sus compañeros; porque son unos pusilánimes que merecen acabar como deshechos. Y porque alguien tiene que pagar esas casas tan grandes, con esos coches tan potentes, y esos yates llenos de putas y coca. Suelen escribir un bestseller para purgar su auge y caída, por lo general en los ratos libres en el patio de la cárcel.

Por equilibrar ese modelo tan tóxico y quizá también, por el auge de los libros de autoayuda, llegó una nueva corriente de vendedores. Personas con actitud positiva que saben automotivarse, y que no admiten un no por respuesta porque saben que pueden conseguir todo lo que se propongan. Efectivamente, hay dos grandes referentes para esa generación: Paulo Coelho y Mr. Wonderful; que comparten icono en el Whatsapp (una pista: los hay que piensan que en realidad representa un sonriente helado de chocolate)

Tipos de Vendedores

Tipos de Vendedores condenados a desaparecer

Por no hablar de los vendedores de cuota. No hay nada más disciplinado, organizado y metódico que los chicos que se reparten en sectores la Calle Preciados para conseguir suscriptores a una ONG. Incluye un rápido perfilado en tiempo real del incauto peatón para ver quién es el miembro (o miembra, ojo) del equipo más adecuado para cerrar la venta.

En fin, en general, parece que hay una connotación negativa en la venta. Como si hubiese que levantar una barrera mental o incluso física, porque un vendedor siempre está cogiendo información de nosotros. Información que en algún momento dado va a usar en nuestra contra, y nos la va a colar. Nos va a vender algo que no necesitamos, puede incluso que nos haga un pufo.

Yo he llegado a la conclusión de un vendedor genera rechazo por 3 motivos:

  • porque pensamos que nos ve simplemente como dinero ambulante; y por tanto todo lo que dice o hace está dirigido a sacarnos la pasta.
  • porque nos va a molestar haciéndonos perder el tiempo, contándonos chorradas que no nos interesan.
  • porque una vez que hace su venta, si te he visto no me acuerdo; ya ha hecho lo que tenía que hacer y al siguiente.

Las 12+3 Competencias del Vendedor

Bueno, entonces ¿necesitamos una Nueva Generación de Vendedores? Pues desde mi punto de vista, no hace falta. Lo que hace falta es hacer un Elogio del Vendedor. De ese estilo de vendedor que siempre ha estado ahí, y que se ha dedicado a crear relaciones de confianza y a conseguir que sus clientes logren sus objetivos. ¿Cuáles son sus competencias?

  • Escucha. Osea, dejar que otra persona hable sin interrumpirle y, si es posible, concentrándose en lo que dice. Entendiéndolo, además.
  • Empatiza. La capacidad de ponerse en el lugar de otra persona para saber qué quiere y por qué lo quiere.
  • Analiza. Estar todo el día escuchando y empatizando es agotador. Un buen vendedor debe ser capaz de procesar todos los diferentes inputs y la información que recibe para discernir el grano de la paja, y llegar a la verdadera raíz de un problema.
  • Toma decisiones. La autonomía es la competencia de tener claros los objetivos, y estar alineado con la estrategia de la empresa; para poder así tomar decisiones en tiempo real basadas en prioridades conocidas y compartidas.
  • Se comunica. La capacidad de expresar ideas y conceptos de una manera clara y coherente, adecuada al lenguaje y contexto del interlocutor.
  • Compite. Toda esa gente que hay desde la puerta hacia fuera nos odia porque no puede hacer lo que nosotros hacemos; y tenemos que vivir con ello.
  • Coopera. Porque de puertas hacia dentro, lo que se espera de los vendedores es que trabajen en equipo por un fin común. La mejor forma de definirlo es leyendo las declaraciones de Llull cuando fue declarado MVP de la Copa del Rey en 2017. Habló de sus compañeros y del éxito del equipo.
  • Se Anticipa. Conocer una empresa y en general a una persona, supone ser capaz de comprender sus objetivos, el camino que va a recorrer. Y así, poder utilizar el conocimiento y capacidades de la organización para anticipar los posibles obstáculos que haya en ese camino.
  • Aprende. Vivimos en el mundo del cambio constante, hay que adquirir permanentemente nuevas competencias…
  • Crea. Porque al final, lo que se espera de un vendedor es que encuentre una solución y muchas veces no viene empaquetada con un manual de instrucciones.
  • Propone. Es capaz de explicar y argumentar las propuestas de manera convincente.
  • Relativiza. Es decir, pone las cosas en contexto, normalizadas, para darles el peso que les corresponde de manera ponderada junto al resto de cosas que ocurren en la empresa.
¿Es posible ser feo y/o vender?

¿Es posible ser feo y/o vender?

Y sobre todo:

  • Resuelve. Da igual que tengas puesto un sofá en el Wallapop, que vendas televisiones gigantes, o que presentes una RFP para un sistema de contratación bancaria 100% online. Lo que se espera de un vendedor es resolver una necesidad.
  • Cumple. Porque el valor está en las relaciones en el largo plazo, y eso se consigue con el compromiso; poder mirar a la gente a la cara y dormir tranquilos por las noches. Eso significa para un vendedor contraer la obligación de llevar a cabo la solución que han propuesto.
  • Ilusiona. Porque los seres humanos no quieren que les vendan, quieren comprar. Y en general, compramos aquello que nos acerca a la experiencia o a la proyección que tenemos de cómo nuestra vida va a ser mejor.

Vender es conectar a una persona con aquello que necesita, quiere o le interesa. La verdad es que puede llegar a ser un trabajo muy bonito.

 

Ghosting, la nueva vieja forma de ignorar al Vendedor

Publicado el por

Tú no lo sabes, pero es la última vez que hablaréis. Crees que es una despedida más, igual que las anteriores, sin embargo, esta vez va a ser diferente. A partir de mañana no va a contestar al teléfono cuando llames. Y no es que tenga lío, no. No piensa devolver tus llamadas.Tu teléfono seguirá en su agenda, sólo para saber que eres tú quién llama. Tampoco va a contestar tus whatsapps, olvida del doble tick azul, no los va a leer. Tampoco va a contestar tus emails. Vas a dejar de ver sus post en Facebook, y sus fotos en Instagram.

Una persona normal esperaría al menos una explicación. Un motivo. Nada. No te esfuerces, no pierdas el tiempo, y sobre todo, no pierdas la decencia: no existes. Te has convertido en un Fantasma.

Ghosting

Agárrame ese Fantasma

¿Qué es el Ghosting?

El Ghosting es la nueva forma de terminar una relación: convertir a otra persona en un fantasma, alguien que no existe, simplemente ignorándolo. Sin pasar por el penoso y a veces engorroso proceso de dar explicaciones. Por el camino fácil.

Aunque el Ghosting es algo que parece fomentar una sociedad que nos ha dado Tinder, Grindr, Happn, las Adopciones de Tíos y demás, el caso más sonado es el de Sean Penn. Efectivamente, un hombre que tiene 2 Oscars© de la Academia y que estuvo casado con Madonna y con Robin Wright, pero al que Charlize Theron sacó de un plumazo de su vida, haciéndole desaparecer como un fantasma.

Por lo demás, una encuesta de YouGov demostró que el 11% de los encuestados había hecho Ghosting para terminar una relación (un 6% adicional de cachondos decían no estar seguros, osea, que sí) La revista Elle también publicó una encuesta que mostraba que casi el 17% de los hombres y el 24% de las mujeres se habían convertido en fantasmas alguna vez en su vida.

Lo que las encuestas no te dicen es que el 100% de los vendedores hemos sufrido Ghosting alguna vez en la vida.

Cómo saber si eres víctima del Ghosting

Efectivamente, queridos amigos. Todos los que estamos en el mundo de la venta hace años que sabemos que el Ghosting existe. Seguramente lo aprendimos la primera vez que presentamos una propuesta. Es algo que hemos incorporado a nuestro día a día, pero no le habíamos puesto un nombre molón ni hablaban de ello las revistas de moda.

¿Reconoces alguno de estos síntomas?

  1. Parece que no contesta a mis correos, el caso es que no me los rebota
  2. Le dejé un mensaje en el buzón de voz, lo debe tener lleno porque no me devuelve la llamada
  3. Qué mala suerte, es la tercera vez que me cancela la cita
  4. Siempre le llamo cuando está reunido
  5. Le mandé una propuesta pero nunca me contestó, creo que sólo quería mirar precios
  6. No pone su teléfono en la firma de los correos, es que ya me conoce
  7. Me dijo que me invitaría al siguiente concurso, lo que pasa es que para este año ya no tiene presupuesto
  8. Nunca aceptó la invitación a conectar en LinkedIn, porque no usa mucho las redes sociales
  9. Nos cruzamos frente a frente en la cola del café de un congreso, lo que pasa es que no hablamos porque tenía que enviar un email
  10. Le fui a dar la mano, y se la metió en el bolsillo, lo mismo es que le sudan mucho

Bien, ahora que ya sabes que te has convertido en un fantasma, veamos por qué.

Game Over

Los fantasmas atacan al Jefe

No soy yo, eres tú

Ignorar a un vendedor es algo que todos hemos hecho alguna vez en la vida, basta con pensar en la persona que te llama por teléfono a la hora de la siesta para que te cambies de operador; en el que te quiere vender un seguro en un centro comercial; o el que quiere que alivies tus pecados de burgués colaborando con una ONG.

Después de muchos años estudiando al respecto, la conclusión a la que llego de los motivos del rechazo giran en torno a cuatro grandes ejes:

  • No me interesa escuchar lo que me estás contando
  • Tengo cosas más importantes que hacer
  • Eres un cansino y me aburres
  • No quiero establecer una relación contigo

Partiendo de la base de que todos tenemos derecho a no comprar algo, ni a comprar siempre en el mismo sitio, ¿tenemos la obligación de explicar el motivo por el que no compramos? Obviamente no.

Al igual que en el Ghosting de las relaciones de pareja, exponer los motivos del rechazo de una oferta puede convertirse en algo desagradable. Supone dar explicaciones, lo que en general muchas personas prefieren evitar. Incluso puede abrir la puerta a los reproches. «Nos quedamos ayer currando hasta las 2, podríamos habernos ido a casa»

Nadie quiere explicaciones y reproches en la relación con sus proveedores. Por eso a veces lo más fácil es ignorar a una persona a la que con suerte uno no va a volver a ver. Y aunque a nadie le gustaría ser víctima del Ghosting, lo hacemos por dos motivos:

  • Porque asumimos que la otra persona se va a dar por enterada de que no queremos comprarle nada y acabará por desistir
  • Y porque no vemos directamente la incertidumbre o duda que generamos en el vendedor ni las explicaciones que tiene que dar en su empresa. Al fin y al cabo, cómo haya gestionado las expectativas ante sus responsables es asunto suyo

Lo que pasa es que alguna mente perversa inventó los conceptos de «prospect», «lead», «Funnel», «CRM» y otras aberraciones infames, y por eso cada mes tienes un contacto de alguien que te abrasa para ver qué pasa con lo suyo. Con lo suyo, no con lo tuyo. No te llama para ver cómo estás, qué tal van las cosas, si tienes algún problema, nada nada, te llama para ver si cambia el estado de una oportunidad registrada en su SalesForce de «Negotiation/Review» a «Closed Won».

El subconsciente de estas personas desea en secreto que les digas que te dejen en paz para poner de una vez la oportunidad como «Closed Lost» y no tener que volver a llamarte, porque les da vergüenza.

Y por eso el primer griego que quiso deshacerse del primer fenicio se inventó El Motivo.

Ghostbusting

Supongo que ya sabes que El Motivo es el precio. «No, es que sois muy caros». Es la mentira piadosa de la venta.

  • Es universal: la mayoría de las personas creen que las ventas se basan en el precio
  • Es un argumento incontestable: nadie sabe el precio de sus competidores
  • Permite delegar la responsabilidad del rechazo en un tercero sobre el que no se puede influir: como El Área de Compras (si hubiera Polis Malos en el Lado Oscuro trabajarían en el Área de Compras)

Osea, es el camino fácil.

Hay un antes y un después en la venta, y es cuando dejas de escuchar El Motivo. Cuando alguien se toma la molestia de explicarte que no has entendido lo que necesita. O que le estás poniendo unas condiciones que sinceramente, no tiene por qué asumir; que las condiciones las pone él que para eso paga. O porque no se cree que seas capaz de cumplir y no se quiere jugar su dinero, su ascenso o su variable en una lotería. O simplemente, que hay más empresas ahí fuera perdiendo el culo para trabajar con él, que le hacen más caso y se lo toman más en serio. Etc.

Esa clase de explicaciones requieren una relación de confianza entre cliente y vendedor que muy pocas personas cultivan.

Ghostbusters

¿A quién vas a llamar? (Imagen de Birds of North America en Wikimedia Commons)

Sobre todo piensa. ¿Cuándo has dado explicaciones a un vendedor? ¿Cuando te has sentido obligado a hacerlo? Nah. Lo has hecho cuando has creído que era importante explicar tus motivos. Porque estás construyendo una relación con esa persona/empresa. De la misma manera  tu cliente te las dará cuando considere valioso construir una relación contigo.

Sólo te harán Ghosting cuando quieran perderte de vista. En ese caso no insistas y trata de entender por ti mismo los motivos.

PS- A Debbie Harry tampoco la llamaban

Chiringuito Sales

Publicado el por

El mundo de las empresas de servicios es tan simple que hasta un niño de 4 años entiende cómo funciona. Concretamente, el mío lo entendió el otro día cuando le llevé a cenar a los chiringuitos de la playa donde estábamos pasando las vacaciones.

Partamos de la base que un padre y un hijo son buenos clientes. Previsiblemente comprarán bebidas, aperitivos de bolsa, helados y en general productos que no requieren prácticamente elaboración, que no aumentan la carga de trabajo de la cocina, y a la media hora van a dejar libre la mesa para que entre otro cliente.

¿Por qué elegimos el Chiringuito Pirata? El Marketing

Según se entra a la playa por la zona de la izquierda del paseo de las tablas, está el Chiringuito Ramón. Pero pasamos de largo, ¿por qué? Ofrecían lo mismo: una carta a base de pescaditos fritos, carne a la brasa, cerveza fría y gin-tonics como el resto, y las vistas del mar y la luna (casi llena) eran prácticamente iguales. Lo que pasa es que estaban poniendo Reguetón. Don Omar (o quien fuera) le decía vulgaridades a su mami. 300 metros más allá, una bandera negra con una calavera y dos sables cruzados nos ofrecía una promesa de ambiente rockero. Así que pasamos por delante y seguimos hacia el Chiringuito Los Piratas.

“Chicos, tengo una mesa en primera línea para vosotros” nos dijo un camarero, pero Coquito y yo hicimos caso omiso. “No es justo”, pensaría el camarero. “El sitio está medio vacío, tengo las mismas vistas, el mismo menú, y estoy más cerca de su casa. Nunca han cenado aquí, ¿por qué no me dan una oportunidad?” Pues porque tu competencia, a la que tampoco conozco, me ofrece para el mismo servicio una experiencia que me interesa más, que me invita a pensar que va a ser diferente. Veo banderas piratas, llegan acordes de blues, y creo que me voy a sentir mejor allí.

ChiringuitoSales-Marketing

Goonies never say die

Esto se llama marketing y posicionamiento. Consiste en que muchas empresas prestan los mismos servicios, pero cada una ofrece una experiencia diferente.

Cuando eres cliente, eliges cenar en un sitio antes que en otro por una serie de motivos objetivos y subjetivos, en un proceso similar al que utilizan tus clientes para trabajar contigo o con tu competencia. Hay clientes que esperan recibir a profesionales trajeados de arriba abajo porque les transmiten seriedad y disciplina, y otros que quieren ver a jóvenes despeinados y con camisetas de superhéroes porque asumen que son gente apasionada por el trabajo técnico. ¿La ropa tiene que ver con la seriedad profesional? ¿Uno es mejor creativo por tener gafas de pasta, barba tupida y tatuajes? ¿Voy a cenar mejor en un sitio que pone Blues que en otro que ponen Reguetón? Quizá la calidad de la comida no sea mejor, pero seguramente me encuentre más a gusto.

La imagen, el posicionamiento y la experiencia percibida es importante para ti cuando eres cliente, así que tenlo en cuenta cuando eres proveedor.

¿Por qué nadie pregunta primero? La Atención Personalizada.

Cuando llegamos al Chiringuito Los Piratas, un camarero muy amable nos condujo directamente a una de las mesas exteriores que quedaba libre sobre la propia arena de la playa. “La verdad es que preferiría una mesa un poco más recogida, sobre el suelo de tablas”.  “Pero si estas son las mejores mesas”, me dijo el chico, “ninguna mesa te tapa las vistas al mar”

Sí, tienen vistas directas al mar, pero están sobre la arena, y la brisa levanta tierra. Al niño ya le traigo duchadito de casa, y no quiero tener que volver a lavarle después de cenar ni tener que andar sacudiendo arena de la ropa. A parte, que si está en la playa, se levanta de la silla y echa a correr por la arena, se me va un poco el tema de las manos. Y sobre todo, no tengo ganas de darle explicaciones a un camarero de por qué quiero una mesa u otra.

ChiringuitoSales-Atencion

No importa quién tenga el dinero, pregunta siempre al que toma las decisiones. En este caso, al niño

Efectivamente, muchas veces ofrecemos a nuestros clientes aquello que pensamos que es lo mejor, lo que creemos que quieren. ¿Y cómo lo sabemos? ¿Porque todo el mundo queremos lo mismo? ¿No es mejor preguntar? ¿Cómo vas a saber lo que alguien quiere si no se lo preguntas?

¿Cómo nos gusta que nos atiendan? La Gestión de Cuenta.

Hay toda clase de teorías sobre cómo debe ser el menú de un restaurante (y en ese punto asumimos que un Chiringuito Playero es un restaurante). Con muchas cosas para elegir, o con pocas pero muy elaboradas. Con sugerencias del día o sin ellas. En el caso de un Chiringuito Playero uno espera encontrar pescados fritos, carnes a la brasa, y paellas por encargo.

Lo que uno no espera en un Chiringuito, un lugar de tamaño reducido (no supera las 15 mesas), es que la chica que te toma nota de las bebidas te diga que ahora viene su compañero a tomarte nota de la comanda. ¿Perdona? Yo ya he mirado la carta, ya se lo que quiero, y tú tienes un cuaderno de notas. Pero en fin. Lo entiendo. Al menos la chica se acerca al tipo de la comanda para decir que nos tome nota, y el chaval viene enseguida.

Hay un gerente que ha decidido que cada miembro del equipo hace una cosa, y en su organización se exige que se respete el procedimiento por encima de la atención al cliente. Hoy he tenido suerte, pero ¿por qué tengo que esperar a que venga otra persona para tomarme nota? ¿Por qué la organización está por encima de la atención? ¿Y a quién le pido luego la cuenta? ¿A la de las bebidas? ¿O al de la comanda? ¿Por qué tengo que saber yo a qué se dedica cada empleado? ¿Y qué me importa cómo se organicen?

Pues a tu cliente le pasa lo mismo. A tu cliente no le interesa conocer tu organización y los motivos por los que te estructuras como lo haces. En general, trabaja con muchas empresas y le da lo mismo cómo se organizan. No les obligues a aprendérselo. Es asunto tuyo. Lo normal es que sólo quiera tener un teléfono guardado en la agenda; cuando necesite hablar con tu empresa lo último que espera es bucear en el email para encontrar ese correo donde le contabas tu nuevo organigrama para 2015. Seguramente prefiera hablar siempre con la misma persona, que le conoce, que sabe lo que quiere y cómo lo quiere; porque casualmente es lo mismo que tú prefieres.

¿Cómo salen los platos? El Delivery

Uno de los principales problemas a los que se enfrenta un cliente en un restaurante es el Delivery: tanto el tiempo que pasa desde que un camarero hace un pedido a cocina y este se sirve al comensal, como que todos los platos se sirvan a la vez, a la temperatura adecuada. Y que estén buenos, claro. Todos los programas de Pesadilla en La Cocina giran sobre lo mismo. Exactamente lo mismo que les pasa a las empresas de servicios profesionales. Incluso a las de consultoría y desarrollo de software.

A mí me da lo mismo que haya una mesa de ocho señoras inglesas poniéndose hasta arriba de sangría y pescaítos, yo quiero que me atiendan en un tiempo razonable. “Pero es que tenemos esa mesa que está siendo muy complicada. Las señoras no paran de pedir cocktailes, todos distintos, y venga raciones”. Bueno, pues eso es algo que tendrá que gestionar la persona que haga la planificación de las salidas de la cocina, pero desde luego no es asunto mío. Que estén muy liados es su problema, pero si lo convierten en mi problema, como cliente posiblemente no perciba que me estén dando un buen servicio.

ChiringuitoSales-Delivery

Todo forma parte de la entrega del servicio, hasta traer una pajita a juego con el cinturón de Batman

¿Te importa que te hagan esperar cuando te atienden en un restaurante? Hay personas a las que no les importa esperar y otras a las que sí. Aunque cada uno gestiona de manera diferente la espera, todos compartimos un concepto de calidad. Podemos asumir que todos queremos que nos llegue la comida caliente, que sirvan a todos los comensales a la vez, y que no nos hagan esperar más de 15 minutos en servir el primer plato. Si nos llega la comida fría, mal hecha y a destiempo, habrá gente que se calle y otros que monten el pollo, pero lo raro será volver al restaurante. Por muy bien situado o decorado que esté, porque pongan a BB King o porque los camareros sean muy majos.

Pues igualmente hay personas a las que no les importa que el proyecto arranque el mes que viene, y otras que tienen una serie de compromisos clave para su negocio. Y esa decisión es suya, no tuya. Una empresa que vende material escolar por internet tiene que tenerlo todo listo para la Campaña de la Vuelta al Cole, y le da lo mismo que la gente quiera cogerse vacaciones, que menganito se haya cogido una excedencia para hacer un master o que perengano se case: se están jugando su ingresos, hay gente que incluso se estará jugando su variable, y no quiere oír hablar de esperar o de retrasos.

¿Por qué se nos olvida cómo pensamos, sentimos y actuamos cuando somos clientes? Seguramente tus clientes cuando te contratan piensan, sienten y actúan de forma parecida a ti cuando contratas a otro. No les des motivos para cruzar al siguiente chiringuito, o para no volver.

¿Volveremos? La Fidelización del Cliente.

Hay sitios a los que sin duda volveremos. Aunque más o menos a todo el mundo le guste conocer sitios nuevos y demás, hay restaurantes (y chiringuitos) en los que nos sentimos bien atendidos, donde tenemos una experiencia agradable que nos gusta repetir.

El Chiringuito Pirata es uno de ellos. La experiencia agradable no incluye sólo la atención de los camareros y la calidad de la comida, también que nos dejen «disfrutar a nuestra medida”. Conocer la medida de cada cliente y adaptar la experiencia es clave para la fidelización. Hay personas que quieren cenar e irse, y otras que se quedan de tertulia. Los clientes tipo cenar e irse esperan recibir la cuenta según la piden, y no tener que pedirla a cada camarero que pasa. “Es que no es mi mesa, pídasela a mi compañero” (de nuevo el truco de trasladar al cliente las carencias organizativas) Los de tipo tertulia, que cuando se acabe la cena inviten a los licores, y luego vayan saliendo los copazos periódicamente.

ChiringuitoSales-Experiencia

Adaptar una experiencia general a la particularidad de cada cliente es clave para la fidelización

Como cliente, sabes por qué no volverás nunca a un chiringuito playero. Porque no te han atendido como querías, porque el ambiente no te gustaba, porque te han hecho esperar, porque la comida estaba mal elaborada, por la relación calidad / precio, porque no has sintonizado con el sitio… En definitiva, por una mala experiencia. Estás en tu derecho de no querer volver, de comentar tu mala experiencia en las redes sociales, incluso de recomendar a otras personas que no vayan. Y a veces hasta pides el libro de reclamaciones.

Míralo desde otro punto de vista. También sabes por qué volverás, por qué hablarás del sitio o por qué recomendarás a otras personas que vayan.

Exactamente lo mismo que hacen tus clientes.

 

10 Formas de No Vender

Publicado el por

Vender puede ser una de las cosas más bonitas que hacer en esta vida, o puede ser una auténtica pesadilla. Depende de si tu objetivo es conectar a las personas con aquello que les interesa, desean o necesitan; o si las personas sólo te interesan porque necesitas conectarlas a tus objetivos.

La connotación negativa de la Venta

Confieso que a veces me da vergüenza decir que soy comercial. Supongo que porque todos hemos sido víctima de alguno de estos tres modelos de vendedores:

  • El Estadista. El vendedor de cuota. Sabe que tiene que hacer 100 contactos para conseguir hacer una venta. Tú sólo eres un número más en su lista. Cuanto antes acabe contigo, antes llegará su venta. Es el modelo de los teleoperadores que te llaman para ofrecerte un cambio de línea a la hora de la siesta, del que te intenta vender un seguro en un centro comercial, o de los chavales que te asaltan en la calle Preciados con preguntas capciosas del tipo «¿Estás en contra del trabajo infantil?» (Yo a veces digo que no, que estoy a favor: todos esos balones no se van a coser solos)
  • El Macho Alfa. Es el modelo de vendedor que explotan las películas de Hollywood. Estruja a sus clientes demostrando que es superior a ellos física, psicológica e incluso sexualmente. Después de sacarles la pasta, los deja temblorosos, derrumbados como peleles, en posición fetal. Nunca venderá dos veces a la misma persona, ni establecerá una relación de confianza; pero no le importa, porque hay más ovejas que cazar en el rebaño. La mayoría acaban politoxicómanos, durmiendo en una pensión.
  • El Listillo. Es el tipo aparentemente simpático que notas que te está engañando pero todavía no sabes cómo. Es esa clase de persona que enseguida sabe como piensas y lo utiliza en tu contra, en lugar de en tu favor. Aunque te dirá lo que quieres oir, no le importará que el argumento de venta se reduzca al precio, porque pagues lo que pagues, él siempre sale ganando.
Obsolete Salesman

Yes, we can

Cuando compramos algo que no necesitamos, nos manipulan para tomar una decisión o nos engañan; nos sentimos frustrados, estafados, incómodos, o una mezcla de las tres. Y como quién más quién menos, todos alguna vez nos hemos sentido así, es normal que los que nos dedicamos a esto queramos distanciarnos un poco de la palabra «vendedor». Porque esos sentimientos negativos se asocian obviamente a una persona, el tipo que te vendió la moto (aunque a veces se proyectan al producto, servicio y empresa para la que trabaja)

10 Razones por las que la Bruja Mala del Oeste no vende

Hace unos días dí una conferencia en el MBA / MDSIC de la Universidad Politécnica de Madrid, en la que hablaba sobre mi visión de la venta, y cómo aplico la innovación y el Design Thinking para entender lo que quieren las personas y diseñar esa propuesta de valor con la que intento hacerles sentir lo importante que es para mí dar una respuesta a su necesidad, presentándoles algo diferente, algo que nadie más les ha presentado.

Con un storytelling ambientado en el Mago de Oz, utilicé a la Bruja Mala del Oeste como antagonista del buen vendedor. Y aquí están los 10 motivos por los que no vende:

  1. Interrumpe sin un buen motivo. Todos estamos demasiado ocupados, el recurso más escaso que tenemos es el tiempo. Cuanto más responsable es una persona, menos tiempo tiene. Exacto, el tipo que tiene que tomar una decisión de compra suele tener muchas cosas que hacer. No está sentado al sol esperando tu llamada. Lo último que quiere es que le interrumpas para hacerle perder el tiempo.
  2. Sólo habla de si misma. A nadie le interesa oirte hablar de ti, de tus productos, de tus servicios ni de tus objetivos. Excepto a tu sicólogo, pero a ese le pagas tú. Si quieres que alguien te escuche, tienes que hablarle de sí mismo, de sus productos, de sus servicios, de sus objetivos o de sus problemas. Dale una oportunidad a Dale Carnegie.
  3. Interroga a las personas. Que nadie quiera oirte hablar de ti mismo no quiere decir que tengas que convertir una reunión en un interrogatorio. ¡Tampoco te pases! Seguro que más de una vez habrás leído que el arte de la venta es el arte de hacer preguntas; eso significa no sólo que hagas preguntas inteligentes, sino que crees primero una atmósfera de sintonía en la que una persona no sienta que ha llegado el momento de llamar a su abogado.
  4. Intenta solucionar lo que ya está solucionado. Hay que tener mucho valor para decirle a alguien que tiene que tirar a la basura su inversión del año pasado. Seguramente no es algo que quiera oir. Imagina todas las explicaciones que va a tener que dar a sus responsables. Además, ¿cómo te sentaría que el albañil te dijera que tiene que levantarte los azulejos que te acaba de poner para cambiarte una tubería? Y que te lo tiene que cobrar a parte, claro. El 50% de los encuestados echa al albañil de casa, y el resto llama a la policía.
  5. Presiona para la toma de decisión. Una cosa es que queramos transmitir la exclusividad de nuestros productos, la escasez de la oferta frente a la demanda, etc., y otra cosa es obligar a que una persona indecisa tome una decisión. Las personas indecisas necesitan unas veces más información, y otras que les proyecten cómo va a mejorar su vida cuando hagan la compra. Lo que no necesitan es que les aprieten. ¿Cómo quieres que te recuerden? ¿Como la persona que les orientó o como el hijo de puta que les puso contra las cuerdas? Esa es la clave.
  6. Ofrece lo que le sobra. Nadie quiere comprar tu basura, así que deja de intentar colocarla. Nada más que añadir.
  7. No le interesa lo que la gente necesita. Con esfuerzo y mucho trabajo tal vez consigas venderle a una persona algo que no necesita. Es cuestión de probabilidades, siempre acaba picando uno. Aunque si ese mismo esfuerzo y trabajo lo dedicas a entender lo que la gente necesita, seguramente consigas olvidarte de las estadísticas, y empezar a crear relaciones. Las relaciones destruyen cualquier estadística.
  8. Manipula a las personas. Manipulamos cuando intentamos tomar el control de los pensamientos, comportamientos o emociones de una persona en nuestro propio beneficio. La mayoría de las técnicas de manipulación empresarial incluyen la distorsión de la realidad, la mentira, jugar con las emociones de las personas (positivas, como el deseo de reconocimiento, o negativas como el miedo y la vergüenza), jugar con el lenguaje y la retórica (para que las personas digan aquello que no quieren decir, o crean que han dicho lo que no han dicho), etc. Todo ello mezclado con anular, cambiar o crear sentimientos. Puede que en caliente sea posible manipular a una persona, pero con el tiempo (y sobre todo, con la reflexión), acabará llegando la sensación de haber sido manipulado. Nadie quiere ser manipulado. Y lo que es peor, nadie hace negocios con alguien que le ha manipulado. No manipular.
  9. Quiere que alguien solucione sus problemas. Uno de los principales errores de la mayoría de las organizaciones. Espero que no pienses que hay gente llamando a tu puerta con las manos llenas de fajos de billetes, deseando pagar para solucionar tus problemas. ¿Que tienes el almacén lleno de cajas cogiendo polvo? No te preocupes, yo me las llevo a que cojan polvo en el mío. ¿Que tu equipo está de brazos cruzados mirando por la ventana? Tranquilo, que se vengan a mi oficina. ¿Sabes que eso no va a pasar, verdad? Es justo lo contrario: estamos dispuestos a pagar para que alguien solucione nuestros problemas.
  10. Es cansina. La mayoría de los manuales de venta insisten en el concepto de «mantener la oportunidad caliente». Lo peor es que hay muchas personas que se lo han creído, así que no paran de llamar a sus clientes, perdón a sus «prospectos» (en serio, esa palabra no significa lo que pensáis), saturarles a correos (largos y densos, con mucho contenido porque la gente está deseando leerte) o dejarles mensajes de voz en el contestador. Curiosamente, también se quejan de que nadie devuelve sus llamadas, ni contesta sus correos. Abre los ojos: lo que pasa es que les estás aburriendo. Deja de hacerlo. Descubre lo que a ese persona le interesa, ofrecele algo valioso, o no molestes más.
10 Formas de No Vender

10 Formas de No Vender (aunque seguro que hay más)

¿Te reconoces haciendo alguna? Por si acaso, la mejor recomendación es hacer un ejercicio de empatía. Porque todos somos alguna vez cliente de alguien. Así que ¿cómo te has sentido como cliente cuando te has visto en alguna de estas 10 situaciones?

Pues si lo interiorizas, tendrás una idea clara de cómo se sienten tus clientes cuando les haces pasar por esto. ¿De verdad es ese es el profesional que quieres ser?

PS- Jet nos recuerda que pongamos nuestro dinero donde tengamos la bocaza, porque al fin y al cabo, este es un post de la categoría «Money Talks»