Por Martín Alejandro Mednik
CEO y Co-Founder de TOBS
Miembro de la Comisión de Tecnología de CACE

Estamos atravesando un nuevo cambio de paradigma en la web. Conceptos como blockchain, criptomonedas y contratos inteligentes forman parte de esta nueva versión de Internet. En este artículo vamos a conocer qué es la Web 3, haciendo un recorrido desde sus comienzos.

Nuestra experiencia como usuarios y creadores de contenido le dan forma a la web. En sus inicios Internet era una red estática, pero con el paso del tiempo los usuarios cobramos protagonismo. Así como la web2 tuvo a la generación del contenido como elemento clave de su revolución, esta nueva era de Internet se empieza a gestar alrededor de la descentralización.

Recorramos la historia de Internet para entender a fondo el impacto total que está teniendo y tendrá la web3.

Web1

La creación de Internet generó una revolución de acceso a la información. Las primeras computadoras conectadas a esta red de redes podían consultar información, desde distintas ubicaciones geográficas, en tiempos cortos.

Los primeros sitios web consistían en una recopilación de información estática. No era posible ninguna interacción más allá que navegar de una página a otra a través de enlaces (hipervínculos o links).

Durante esta época la única forma de comunicación online era el correo electrónico. Vale mencionar que, incluso desde esta primera versión de Internet de finales del siglo XX, tuvieron lugar las primeras transacciones de comercio electrónico.

Web2

Al sumar interactividad a los sitios web y, de esta manera, permitir que se conformen de manera dinámica, surgió la Web2. Algunos autores determinan su aparición a partir del año 2002.

Hasta ahora, los usuarios de la web sólo habíamos consumido contenido. Esta segunda versión de Internet propuso nuevas formas de comunicación tanto a nivel personal como profesional. Es la era de las redes sociales.

La aparición y popularización de blogs determinó el leitmotiv de la web2: los usuarios generamos el contenido. Durante esta etapa vimos también la creación de grandes plataformas que seguramente usamos en nuestro día a día, como Wikipedia, YouTube o Facebook.

Esta segunda revolución impactó en todos los sentidos: nuevas posibilidades de negocio, nuevos dispositivos, más conectividad, mayor velocidad… El objetivo era claro: que los usuarios generemos la mayor cantidad posible de contenido desde dónde sea.

En el comercio electrónico también aparecieron nuevos conceptos, tales como los sistemas de referidos, las suscripciones o los marketplaces. La relevancia de las calificaciones y opiniones en la compra online justamente tienen como base la generación del contenido por parte de los usuarios.

Web3

La búsqueda de una Internet más justa o más democrática nos acerca, desde hace algunos años, a lo que la mayoría de autores acuerdan llamar web3.

Esta nueva etapa de Internet posibilita la soberanía individual sobre el contenido digital:

  • los usuarios podemos co-crear: leer y escribir, como en la web2, pero ahora también ejecutar.
  • los usuarios podemos compartir la propiedad y las ganancias que se puedan generar.

Ahora los usuarios no sólo podemos generar contenido sino que además podemos ser los dueños del mismo.

El concepto clave detrás de la web3 es la descentralización:

  • bases de datos descentralizadas (blockchains o cadenas de bloques)
  • aplicaciones descentralizadas (dApps)
  • acuerdos o contratos descentralizados (smart contracts o contratos inteligentes)
  • organizaciones autónomas descentralizadas (DAOs)

No hay una sola persona u organismo capaz de decidir arbitrariamente el acceso (o no acceso) a cierta información.

Hemos conocido casos de gobiernos restringiendo el acceso a ciertas webs o aplicaciones o de plataformas eliminando perfiles arbitrariamente. La web3 tiene mecanismos que logran evitar la censura. Todo dependerá de cómo sean implementados y de cuánta libertad realmente quiera proponerse. Pero ahora tenemos la tecnología que lo posibilita. 

Conclusión

Más allá de todos los avances tecnológicos que nos permitieron llegar hasta aquí, la gran innovación de la web3 radica en su filosofía y, fundamentalmente, en el concepto de descentralización. Este cambio de paradigma propone formas originales de interactuar entre nosotros.

Estas nuevas posibilidades de anonimato, propiedad e inversión, pueden ser muy buenas y efectivas en tanto se usen de forma responsable y con las mejores intenciones. Por supuesto, también pueden resultar peligrosas si la búsqueda va en la dirección contraria. Es por esto que es necesario tener presente que el cambio debe emprenderse partiendo desde la educación, que ocupará un rol muy relevante. La libertad y el poder de acción que nos otorga la web3 son una gran responsabilidad.

No podemos dejar de mencionar algunas palabras sobre el comercio electrónico, en este contexto de evolución hacia la web3. Creemos que esta nueva versión de Internet cambiará cómo los consumidores compran online. Éstos buscarán adquirir sus productos y/o servicios de forma más conveniente. Buscarán una experiencia de compra más personalizada, más rastreable y más segura.

Keywords: web3, descentralización, blockchain

El presente documento intenta reflexionar sobre la aplicación de la Inteligencia Artificial en eCommerce y Marketing Digital a fin de tomar conciencia sobre su uso y beneficios, como así también incluirlas responsablemente en nuestras estrategias y planes de Marketing. Esto es capitalizando sus ventajas a favor de los negocios, pero principalmente a favor de los usuarios a las que la destinamos, poniéndolos en el centro de nuestras estrategias en todas las etapas de su relación con la marca.

En esta charla del Ecommerce Full Experience 2022, de la mano de los profesionales de la industria y junto a Luciana Monaco, Directora General y Creativa en Galileo MediaLab, comparten las principales tendencias del mundo digital para cada área de tu negocio.

La evolución de las empresas hacia la transformación digital se ha vuelto en los últimos años, muy vertiginosa. Cada vez son más las compañías que obligadas por la coyuntura o entendiendo el rumbo de las preferencias de sus consumidores, deben apresurarse a adoptar su operatoria dentro de canales online.

En la mayoría de los casos, las empresas que deseen ingresar al proceso de transformación digital, dependerán de la contratación de los servicios expertos que les brinda una implementadora o agencia especializada en eCommerce. Estas tendrán el objeto de llevar adelante la gestión, desarrollo, concreción, implementación, evolución y mantenimiento de su solución de eCommerce.

Esta relación entre el cliente y la consultora, como en toda relación, debe tener reglas de convivencias, responsabilidades, un plan y objetivo en común, entendimientos, disidencias y, claro, puntos de conflicto que inevitablemente sucederán. Estos últimos deben tender a minimizarse para asegurar la buena convivencia, la disminución del estrés y el éxito del proyecto. 

A continuación revisaremos algunos puntos a tener en cuenta a la hora de interactuar con una implementadora, solicitar requerimientos y solucionar problemas de entendimiento con el objetivo de llevar al proyecto en un camino exitoso:

Recomendaciones y buenas prácticas

Definir responsabilidades

  • Al inicio del proyecto se debe generar una serie de encuentros donde conjuntamente se defina cuáles son las responsabilidades de cada participante tanto a nivel empresas (cliente, implementadora, integraciones, etc), como a nivel departamentos o áreas, y finalmente para cada rol individual con nombre y apellido. La responsabilidad incluye lo que cada parte debe hacer, lo que podría hacer y lo que no debe hacer, esto último a fin de que no se produzcan solapamientos de tareas o doble comandos. Hay que considerar que pese a que existe un organigrama estandarizado para la mayoría de los proyectos, cada organización será única y siempre debe adaptarse a la misma.

  • En términos generales, el 30% de los problemas con los requerimientos se dan porque el cliente desconoce cómo diligenciar, qué pedir y qué no, cómo manejarse en cada etapa y la interacción en general con la implementadora. Por ejemplo, se podría generar el siguiente requerimiento: “se solicita armar un template para un email de campaña de descuento”. Esto por lo general no es responsabilidad de la plataforma de eCommerce sino de la solución de Email Marketing, que no suele ser gestionada por la implementadora (a menos que haga Full Commerce). En este caso, una implementadora que sepa visualizar la foto general del proyecto, sabrá guiar al cliente para seleccionar la plataforma de Email Marketing que mejor se adapte a sus necesidades, siendo la contratación y configuración de la misma, responsabilidad del cliente.

Una buena práctica es armar una tabla donde se indique la responsabilidad de cada equipo o área de la empresa, los canales de comunicación con la implementadora y la definición de responsabilidades. También incluir quiénes firman los VVBB (vistos buenos) de cada entregable a fin de avanzar a la siguiente fase.

Comunicar claramente

  • A la hora de explicar oralmente, es recomendable parafrasear y confirmar el entendimiento tanto propio como el del interlocutor, con el objetivo de clarificar. Por ejemplo, cuando se solicita: “quiero construir un sitio escalable” o “quiero un diseño moderno”, ¿qué está significando en realidad?. Una opción para mejorar el entendimiento de un requerimiento visual es incorporando lista de palabras ampliadas, descripciones coloquiales, dar ejemplos, hacer mockups y wireframe.

  • En cualquier reunión o intercambio de ideas, una buena práctica es generar notas o minutas de los puntos principales a modo de “bullets” o diagramas, a fin de consolidar, sentar como historial o evidencia de lo acordado y tener un doble check. Tener en cuenta que la minuta, no solo debe considerar lo relevado sino los próximos pasos y responsabilidades, como también, quienes participaron de la misma. Es recomendable manejar una plantilla o template estándar para este documento y que sea compartido.

  • La implementadora puede presentarle un cuestionario inicial con preguntas básicas a complejas con el fin de ir dilucidando cada tópico o tema relevante de la toma de requerimientos. El cliente también puede generar un cuestionario a la consultora en caso de dudas específicas que necesite aclarar. Otra buena práctica, puede ser, tener acordado un template general para preguntas y respuestas y manejarlo colaborativamente. También existen herramientas como Jira, Assembla o Trello para este tipo de interacciones.

  • No es malo equivocarse, pero si lo es equivocarse tarde. Si el error se reconoce tempranamente, se puede corregir con menos costo y se evitan problemas que podrían consumir mucho tiempo y recursos. Aceptar un error es natural en un proceso de aprendizaje y descubrimiento continuo.

  • Las implementadoras trabajan con muchas verticales e industrias, suelen ser expertos en algunas de ellas ,como retail, electro, moda, etc; pero no en todas. Por eso es importante compartir el vocabulario específico de su área. Una buena estrategia es invitarlos a conocer el proceso de negocio, depósitos, locales, incluso el sector de fabricación, esto puede sugerir nuevas ideas de mejora y evolución que en papel no suelen ser visibles.

  • Nuevamente se hace hincapié en que a veces el cliente no tiene claro lo que quiere o solo tiene una idea general. Por ejemplo “escalar” es una palabra muletilla en el mundo eCommerce, pero ¿qué significa?, ¿cómo se mide? Esto se aclara evitando términos ambiguos y ampliando las preguntas, por ejemplo: “¿cómo se quiere escalar?”, “¿cuántos SKUs?”, “¿cuantas órdenes?”,”¿con qué sistema integra?” etc.

Respetar los tiempos y metodologías de trabajo acordadas

Tener presente los tiempos de entrega de cada respuesta, documento e ítems solicitado por la implementadora. Estas fechas no serán unilaterales, ya que siempre se acordarán con el cliente, pero una vez comprometidas, a menos de situación de fuerza mayor, deben cumplirse para no atrasar el proyecto y se traduzcan en mayores costos.

A continuación se describe un ejemplo donde un equipo de UX le indica el plan para validar un diseño de pantalla:

  • El equipo de UX presenta la mockup visual.
  • El cliente tiene 48 horas para indicar correcciones, mejoras y aclaraciones.
  • 24 horas después de recibida las correcciones el equipo de UX presenta una nueva mockup.
  • El cliente una vez más debe aceptar o pedir últimos cambios.
  • Si aún quedan correcciones se vuelve al paso 3, esto solo se puede repetir una vez más como máximo.
  • El cliente aprueba el mockup. Si el cliente no da respuesta a las 48 horas se da automáticamente como aceptado la mockup.

Aquí vemos, como se indica a modo de regla, que la no respuesta dentro del tiempo indicado se toma como aceptación compulsiva.

Como plantear requerimientos

  • Siempre se debe partir de una visión general a una particular. Es normal que a veces no se sepa lo que se quiere, se puede tener una idea aproximada. Hay que entender que el proceso es iterativo y uno puede ir mejorando la solución. Pero se debe tener en claro lo que se pretende del desarrollo y con un nivel de detalle aceptable.

  • Hay muchas técnicas que pueden ayudar a entender cómo se quiere orientar la solución de eCommerce y por ende qué funcionalidades incluir. Se puede iniciar con un brainstorming, para luego ir depurando un mapa de funcionalidades indicando el para qué y el cómo afecta al negocio o si podré darle soporte operativo.

  • Antes de plantear requerimientos al analista es importante entender internamente qué valor me va a proveer la necesidad que estoy delineando. Puede “quedar lindo”, pero ¿me ofrece algún tipo de ventaja en mi negocio?, ¿aumentan o facilitan las conversiones?, ¿genera más leads?”.

  • Cada departamento, desde su conocimiento del área, debe plantear sus requerimientos, pero estos no deben ser estancos. Deben poder conectarse, dialogar y ser simbióticos entre los mismos. Evitando incluso situaciones donde existan requerimientos contradictorios entre sí.

  • Es muy importante estudiar a la competencia para tomar ideas, tendencias y soluciones probadas, esto puede reducir tiempos, dar ejemplos sólidos e incluso adquirir los mismos componentes (plugins). Sin embargo, no es válido el pedir algo solo por el hecho que la competencia, líder de segmento o marca de renombre internacional lo tiene. Debe preguntarse: ¿Es esa funcionalidad para mi tipo, tamaño y ADN de mi negocio? ¿Me va a permitir mejorar las conversiones? ¿Podría incluso distraer al cliente? ¿Tengo estructura para soportarlo? ¿Realmente se usará dentro de mi segmento de clientes?. Siempre es útil buscar alternativas.

  • A la hora de solicitar requerimientos hay que saber manejar la ansiedad y entender que cada punto necesita de un análisis comprensivo, se debe evaluar la capacidad, los tiempos, el costo si es que requiere presupuesto, las prioridades y las dependencias. Tener en cuenta que siempre se debe dejar un buffer de por lo menos un 5% en los tiempos pre estimados para acolchonar imprevistos.

Cambios en los requerimientos

Esta situación debe tenerse presente para saber atacarla y que sea provechosa, a continuación algunas recomendaciones:

  • Seguramente luego de presenciar una demo o al ir entendiendo más sobre la plataforma y cómo ésta impacta en su negocio, descubrirá nuevas necesidades. Darse cuenta que la necesidad era otra, cambiar el rumbo de un proceso, ver que la competencia o un cambio de tecnología hacen que la necesidad ya no sea válida o requiera innovar, implica que tendrá una pronta conversación con la implementadora donde lleve a la mesa de discusión esta situación disruptiva. 

  • Considere que los cambios pueden comunicarse en cualquier momento, pero nunca deben afectar al ciclo de desarrollo actual (ó Sprint) y lo que se tiene acordado como resultante. El cambio será analizado y evaluado para ingresarlo al listado de requerimientos pendientes (ó backlog) y que forme parte de las iteraciones próximas. Durante un Sprint, el equipo no debe ser interrumpido con cambios o pedidos adicionales. Los cambios en la planificación deben ser acordados antes de comenzar cada ciclo de trabajo. Esta práctica, permitirá al equipo realizar un compromiso real sobre la concreción de los objetivos planteados para dicho Sprint.

  • Los cambios se deben informar formalmente por medio de un RFC (Request for change) donde se debe indicar la funcionalidad actual y cuál es la que cambia, el rational (motivo), la prioridad, si afecta otros requerimientos y donde se incluyen diagramas, esquemas, casos de uso o documentos complementarios que sean necesarios como soporte. Seguramente el analista y líder técnico sumarán preguntas y su entendimiento a la necesidad planteada, que se resumirá como un Caso de Uso en el backlog del proyecto.

  • Aunque surjan ideas nuevas, siempre hay que pensar en el MVP (minimum valuable product), lo cual es lo mínimo indispensable que necesitamos para salir operativos a producción. Luego habrá tiempo para mejoras evolutivas.

  • Hay que tener en radar que si el proyecto se extiende por muchos meses, las ideas que quizás eran buenas al principio de la iniciativa, puedan ser menos interesantes o incluso caducas al momento de la salida a producción. Esto se podrá deber a los avances tecnológicos, cambios de hábitos de consumo, sobresaturación de algún tipo de experiencia e incluso la innovación de la competencia.

  • Tener en cuenta que un requerimiento se debe cerrar para luego poder abrir otro. Si algo cambia en una funcionalidad solicitada, la misma no se debería ampliar. Sino desde lo formal, se debe generar un nuevo requerimiento (con un nuevo ID) y extender esa funcionalidad. Si el requerimiento cumple con los criterios de aceptación se debe dar como válido, pese a que haya cambiado.

  • Saber que los requerimientos deben estar consensuados entre distintas áreas o departamentos de la empresa impactados por dicha necesidad. Evitar situaciones en donde se pide una funcionalidad y luego desde otra área se solicita algo distinto. Por eso el rol de Product Owner es tan importante como centralizador y árbitro de cara de la empresa hacia la implementadora.

Catalogación

  • Se debe trabajar codo a codo con la implementadora para entender cómo realizar la catalogación. Hay cuestiones básicas que deben ser contestadas lo antes posible en el proyecto, por ejemplo si se contará con productos simples, configurables o variaciones, combos, virtuales; o si se tendrá stock centralizado o aperturado.

  • Es primordial armar el set de atributos o características que deberán mostrar cada producto según su familia de producto. Dado que, por ejemplo, son diferentes los detalles de la ficha de producto de una heladera o de un televisor. Además, dichas características no solo se verán en la ficha de producto, sino que se usarán para filtrado, ordenamiento, armado de reglas de carrito, etc. 

  • Se debe definir la taxonomía del árbol de catalogación, entendiendo como se verá en la tienda, la cantidad de subniveles y que tan balanceado quedará. Definir un límite máximo de subniveles (generalmente 3) y de ítems por nivel.

  • Al momento de catalogar recomendamos comenzar con un conjunto acotado de productos, por ejemplo 10 por categoría, para probar inicialmente y luego ir armando los batch o paquetes de catalogación completos.

Capacitaciones

  • Es muy importante acordar capacitaciones previas a la salida de producción para formar a los distintos roles de la empresa en las funcionalidades básicas de la plataforma,  desde lo administrativo y la gestión del eCommerce. 

  • Las capacitaciones deben estar divididas en cada temática, por ejemplo: catalogación, promociones, gestión de órdenes, gestión de clientes, CMS, etc. Previamente se debe tener el cronograma, a fin de poder invitar a los participantes que cumplirán distintos roles dentro de la gestión del eCommerce.

Pruebas y defectos

La etapa de “pruebas de aceptación de usuario” es crítica para el buen funcionamiento de un proyecto:

  • Se debe planificar con la participación de todas las áreas de la empresa que tengan incumbencia en los procesos del eCommerce. Es mandatorio tener un plan de pruebas acordado con la implementadora.

  • Lo principal es realizar un E2E (end to end) que es una prueba completa de todo el funnel de conversión en lo que respecta al “happy path” (situación o caso de usuario ideal) y luego validar las situaciones alternativas o de errores.

  • También se deben probar las situaciones de borde, estrés de datos, operativos y concurrencias. Otro punto muy importante es probar, no solo el frontend del store, sino todas las integraciones y procesos que corren por detrás.

  • A la hora de reportar defectos o bug se debería trabajar mínimamente en una planilla de seguimiento en común donde se indique prioridad, problema, fechas, responsable, etc. Idealmente utilizar una plataforma como Jira o Assembla para el reporting.

  • El reporte de defectos tiene que ser lo más claro posible con el fin de poder reproducir el mismo escenario. Se debe indicar el paso a paso, captura de pantallas o videos de la ejecución, logs de error, set de datos con los que se probó, incluso a veces la configuración del browser, de la red u hora del día en la cual se produjo el inconveniente.

  • Hay que entender qué es un error o bug y qué es un cambio de requerimiento. Esto suele ser un punto de conflicto porque a veces es difícil aceptar que lo que uno pidió no era lo correcto. Pero no hay que preocuparse, sino ocuparse. Como dijimos el cambio es bueno y constante. Nunca existirá un sistema terminado. Por otro lado, en situaciones así hay que confiar en el expertise, know how y buenas prácticas que propone la consultora.

Conclusión

El proceso de creación o evolución de un eCommerce es realmente apasionante, presenta muchos desafíos pero también oportunidades que, quizás inicialmente, no se vislumbraban.

El tener conciencia de cómo interactuar con la implementadora, quiénes participarán de la arquitectura y construcción de su tienda, es fundamental para lograr buenos cimientos y un crecimiento exitoso. Como cliente debemos tener la imagen de la implementadora como socia continua en su crecimiento, y no meramente como un proveedor de servicios tecnológicos temporario.

Muchas cosas se aprenderán sobre la práctica, y tal vez haya fuentes de conflicto y desentendimientos. Pero cuanto más tengas presente las buenas prácticas aquí brindadas, amenizadas con tu cultura de trabajo y la de la implementadora, siempre podrás encontrar terreno común para avanzar exitosamente y crecer.

Para nuestra invitada de este nuevo episodio de Pensar Digital, la experiencia es lo que el cliente percibe cada vez que interactúa con la empresa, sin importar la vía de contacto. Es por eso que para llegar al objetivo de que nos vuelvan a elegir es muy importante escuchar a nuestros clientes y más aún, definir qué queremos que sienta durante y después de la compra.

También escuchalo en: Apple podcast y Google Podcast

En el marco del evento eCommerce GO Nacional 2021, te compartimos conceptos claves para definir el modelo de prevención: Billeteras Virtuales, PSP, Gateway.

En el marco del evento eCommerce Go Nacional 2021, te compartimos consejos prácticos para diseñar una estrategia de marketing que incorpore la generación de contenido propio y así lograr mayor impacto en tus clientes.

En el marco del evento eCommerce Go Nacional 2021, un experto nos comparte recomendaciones para tomar mejores decisiones al operar con cada canal de eCommerce.

En el marco del evento eCommerce Go Nacional 2021, analizamos los desafíos y oportunidades que presenta el comercio electrónico en el interior del país, según los números del último informe anual realizado por CACE.

En esta charla del eCommerce Full Experience 2021 edición online, te compartimos claves y estrategias de marketing para comprender el journey del comprador de cada canal.