Cómo crear una tienda online: qué implica realmente el proyecto

Crear una tienda online no es solo elegir una plantilla de diseño. Sepa cómo preparar el catálogo, el cobro, la entrega y el proceso de desistimiento, y qué comprobar antes del lanzamiento.

Una tienda online no está lista en el momento en que se puede abrir la ficha de un producto y meterlo en el carrito. Está lista cuando el comprador ve el precio correcto, elige una variante que de verdad está disponible, paga y recibe una confirmación comprensible, y el vendedor es capaz de servir el pedido y, si hace falta, aceptar la devolución del producto; el diseño es la parte más visible del proyecto, pero no decide si el primer pedido termina en una entrega.

Por eso la pregunta «cómo crear una tienda online» hay que precisarla primero: ¿qué proceso de venta tiene que ocurrir sin improvisación? La respuesta empieza con un producto y un pedido completo en el que están claros la fuente de los datos, la reserva de existencias, el resultado del pago, la creación del envío y qué se hace en caso de desistimiento. Cada pregunta sin responder se convierte después en alcance de trabajo o en una operación manual: indique al responsable, el tiempo de ejecución y el umbral a partir del cual el enfoque manual ya no sirve. Si no, una tienda técnicamente terminada seguirá apoyándose en un acuerdo verbal y en la memoria de una persona.

Este artículo se centra en la preparación y la aceptación del proyecto, no en comparar precios de plataformas; antes del desarrollo y del lanzamiento usted debe preparar los datos de partida, separar las funciones de la tienda del proceso de la empresa y aceptar el trabajo tras un pedido de prueba real, no a partir de una captura de pantalla. Ese enfoque vale tanto si crea la tienda usted mismo como si encarga el trabajo a un desarrollador.

Empiece por un pedido, no por el nombre de la plataforma

Antes de elegir la tecnología, describa un pedido habitual desde que se encuentra el producto hasta la entrega, con un artículo concreto, un precio, una forma de pago y una dirección. Anote qué hace en cada etapa el comprador, la tienda y su empleado. Si la respuesta es «eso lo arreglaremos a mano», indique también a la persona responsable, el tiempo que exige la operación y el número de pedidos a partir del cual esa forma de trabajar dejará de ser práctica.

Esa descripción muestra enseguida si necesita una tienda estándar o un tratamiento de pedidos más particular, porque un catálogo, una sola lógica de precios, un pago con tarjeta habitual y una taquilla de recogida no suelen exigir un sistema complejo, mientras que los precios según el contrato del cliente, la disponibilidad en varios almacenes o una aprobación en otro sistema cambian el alcance ya antes del diseño. En la lista de funciones ambos proyectos pueden parecerse, pero en la descripción del proceso la diferencia se vuelve inequívoca, y se puede convertir en un criterio de aceptación que al final del proyecto se puede comprobar sin conjeturas sobre lo que el proveedor había querido decir.

La plataforma hay que elegirla según ese proceso y el crecimiento previsto: WooCommerce puede ser una solución racional para un comercio estandarizado, pero Laravel da más libertad para una lógica atípica y para las integraciones; una comparación más amplia está en el artículo sobre cuándo elegir WooCommerce o Laravel. En esta fase lo más importante es entender que el nombre de la plataforma, por sí solo, no dice qué ocurrirá con su pedido.

Añada también una excepción a la descripción del proceso y compruebe qué pasará si el pago falla, si dos personas intentan comprar a la vez la última unidad, si la taquilla de recogida no está disponible o si el cliente quiere devolver una parte de un lote. No hace falta enumerar cada situación rara; aun así, un escenario fallido revela estados, avisos y obligaciones de los empleados mucho mejor que diez vistos verdes en el presupuesto.

El catálogo empieza por la definición de la unidad que se vende

Un Excel de productos aún no es un catálogo, porque primero hay que acordar qué es en el sistema una unidad vendible: para un libro sencillo puede ser un producto con un precio y unas existencias, pero en la ropa cada combinación de talla y color puede tener su propia referencia, imagen, código de barras y existencias. En un lote, a su vez, hay que saber si es un producto autónomo o un conjunto de varias unidades de almacén.

Prepare un producto de muestra completamente relleno antes de que el equipo empiece la importación masiva, e incluya el nombre, la descripción breve y la completa, el precio, la aplicación del impuesto, la categoría, la variante, la referencia, las existencias, el peso o las medidas relevantes para el envío, las imágenes y cualquier otra información importante para el comprador. La muestra permite detectar un campo que falta mientras solo hay que corregir una fila, y al mismo tiempo da al diseñador contenido real, no una ficha de demostración ideal.

Un número ilimitado de SKU en la solución técnica no significa que preparar cuarenta productos y cuatro mil exija el mismo trabajo, porque el precio de las funciones de la tienda puede no cambiar, pero en un catálogo mayor crecen la limpieza de datos, el enlace de imágenes, la comprobación de variantes, la traducción y la importación. Por eso en el presupuesto hay que indicar por separado la capacidad de la plataforma para almacenar el catálogo y el trabajo necesario para dejar sus datos listos para el uso; en ese trabajo pueden entrar el mapeo de campos, el tratamiento de filas erróneas, la revisión de imágenes y la comparación de la importación final con el archivo de origen.

Ropa: la talla y el color no son solo un filtro

En una tienda de ropa, la talla y el color suelen ser variantes con su propia disponibilidad, no meros valores de un filtro, de modo que el comprador debe ver que la talla M azul se ha agotado aunque la M negra siga disponible, que la imagen cambie con el color elegido y que al pedido llegue la combinación exacta. Antes de cargar todo el catálogo, compruebe un producto con al menos dos tallas, dos colores y una variante no disponible.

El catálogo necesita un responsable también después del lanzamiento, así que determine quién cambia el precio, quién añade una variante, quién corrige la descripción y quién retira un producto de la venta; si la información llega del proveedor o del sistema ERP de la empresa, hay que fijar la fuente principal de los datos y el sentido de la sincronización. Dos sitios en los que los empleados pueden corregir un mismo precio no crean flexibilidad, sino la premisa de una discrepancia. Por eso hay que acordar el historial de cambios, los derechos de aprobación y qué se hace si una importación es errónea; el equipo debe poder averiguar en qué fuente nació el valor incorrecto y a qué ha afectado ya.

El proceso de cobro hay que describirlo con estados y acciones

La integración de pagos no está terminada cuando se abre la ventana de pago, porque en el proyecto hay que acordar qué hace la tienda tras cada resultado: un pago correcto puede cambiar el estado del pedido, enviar la confirmación, reducir la cantidad disponible y pasar la tarea a la preparación. Un pago fallido o interrumpido no debe parecer un pedido pagado, pero tampoco debería reservar el producto de forma indefinida.

En el lenguaje cotidiano, «el pago ha salido bien» puede significar que el banco confirmó la operación, que el proveedor de pagos la registró o que el dinero ya está ingresado en la cuenta de la empresa, y el proceso de preparación no puede apoyarse en una formulación tan imprecisa, así que determine qué estado del sistema permite empezar a preparar el pedido y cómo ve el empleado el pedido que necesita revisión. Los pedidos contra reembolso y por transferencia hay que tratarlos aparte, no como una copia del proceso de la tarjeta.

Hay que decidir también cuánto tiempo un pedido impagado mantiene el producto reservado, porque un plazo demasiado corto puede liberarlo mientras el comprador aún termina el pago, y uno demasiado largo reduce de forma artificial las existencias disponibles. Los ajustes básicos de inventario de WooCommerce permiten gestionar la cantidad y fijar el tiempo de reserva de los pedidos impagados, de modo que una tienda estándar puede controlar sus existencias internas sin una integración externa de almacén.

Antes del lanzamiento, haga al menos un pago correcto, un pago interrumpido y un reembolso en modo de prueba o con una suma real pequeña, y compruebe la pantalla del comprador, el estado del pedido en la administración, los correos, el cambio de existencias y el registro del proveedor de pagos. Si el equipo solo ha visto el escenario correcto, gran parte del proceso de cobro sigue sin comprobarse, porque en el trabajo real hay que distinguir un aviso bancario retrasado, un pago interrumpido por el comprador y un error del sistema, y en cada caso debe quedar en la administración un registro comprensible.

La entrega y la preparación del pedido no son marcar una casilla

Una integración de envíos puede calcular el precio, mostrar taquillas de recogida, crear el envío y devolver un número de seguimiento, pero no todas las soluciones hacen todas esas operaciones, así que la fórmula «conectar el mensajero» hay que sustituirla por preguntas concretas: ¿elige el comprador la taquilla, depende el precio del peso, del importe del carrito o del país, se genera la etiqueta en la tienda y llega el enlace de seguimiento al correo de forma automática?

La preparación del pedido empieza después de aceptarlo, y el empleado debe ver con claridad los pedidos pagados y los que hay que preparar, además de qué hacer si hay un error. Determine quién puede cambiar el estado, si el comprador recibe un aviso y cómo se registra el número de seguimiento; en una tienda pequeña puede hacerlo una sola persona, pero en un equipo mayor, sin un reparto de responsabilidades, un pedido se puede preparar dos veces mientras otro pasa desapercibido.

Compruebe el precio de envío con ejemplos extremos, no solo con un carrito medio, y pruebe el producto más barato y el más caro, el umbral de envío gratuito, una dirección fuera del territorio permitido y un producto que no cabe en la taquilla. Si el cálculo usa el peso, un solo producto sin peso puede desbaratar todo el resultado. Si el precio es fijo, hay que saber quién cubre la diferencia de un envío fuera de lo habitual; hay que comprobar también el envío en varios bultos y si el método sigue disponible para un carrito con productos de tamaños distintos.

La recogida en la oficina o en la tienda es también un método de entrega con sus propias reglas, así que el comprador debe conocer la dirección, el horario y el momento en que el pedido está listo para recoger, y el empleado de almacén tiene que enterarse a tiempo de esa elección. Una buena prueba no termina en el letrero «pedido recibido», sino en un paquete o un producto preparado para la entrega y en un aviso preciso enviado al comprador.

Los requisitos del pedido y del desistimiento hay que traducirlos a acciones concretas

Un contrato a distancia se puede celebrar en un sitio web, por correo electrónico, por mensajería o por otro medio de comunicación a distancia, de modo que las obligaciones del vendedor no desaparecen si el pedido se acepta en una red social y la factura se envía después; en el proceso electrónico de pedido, el botón o una acción equivalente debe indicar de forma inequívoca que el pedido genera una obligación de pago. Las exigencias recaen sobre la propia secuencia de pedido, no solo sobre la página de condiciones en el pie del sitio web.

El artículo 98 del texto refundido de la Ley General para la Defensa de los Consumidores y Usuarios prevé que, justo antes de un pedido electrónico, se muestre al comprador, entre otros datos, determinada información esencial, el precio final y los costes adicionales, y que las formas de pago y las restricciones de entrega se indiquen a más tardar al inicio del proceso de pedido. Como el contenido de esas exigencias puede cambiar, antes del lanzamiento hay que comprobar la redacción vigente ese día y comparar las pantallas de la tienda con las normas concretas.

En la confirmación del pedido debe incluirse una copia de las propias condiciones del contrato u otro documento que el comprador pueda conservar inalterado; un enlace a una página que el vendedor puede cambiar de forma unilateral no basta, así que compruebe que la confirmación incluye los productos pedidos, el precio, la entrega, los datos del comerciante y la información precontractual exigida. El conjunto exacto de documentos y su formulación coordínelos con un abogado según su modelo de venta. Conserve la versión utilizada junto con la fecha del pedido, para que en caso de disputa se pueda mostrar no solo la página actual de condiciones, sino la información que de hecho se dio al comprador.

El artículo 102 de esa misma ley reconoce al consumidor, para los bienes, un derecho de desistimiento de catorce días naturales que se cuenta, por regla general, desde la recepción del producto, y en las normas figuran excepciones concretas. En el proyecto hay que prever no solo el texto del desistimiento, sino también un formulario o un contacto, el registro de la fecha de la notificación, la comprobación del producto, el reembolso y la reposición de existencias; si esas operaciones viven en la memoria de un empleado, la tienda funciona solo mientras esa persona está disponible.

Una tienda sin almacén propio sigue siendo un proceso del vendedor

Se puede operar una tienda sin un almacén físico propio, por ejemplo enviando el producto desde el distribuidor o el fabricante, y así se reduce la necesidad de guardar existencias, pero no se anula la responsabilidad del vendedor frente al comprador. Si el contrato se ha celebrado con su empresa, del cumplimiento sigue respondiendo su empresa ante el comprador, no el proveedor.

En ese modelo es crítica la información de disponibilidad y, si el proveedor ofrece un flujo de datos o una interfaz de aplicación, hay que acordar la frecuencia de actualización, el tratamiento de errores y qué se hace si se corta la conexión. Un retraso de cinco minutos puede ser decisivo para la última unidad de un producto de venta rápida, y aceptable para un catálogo de rotación lenta. La frecuencia de sincronización hay que fijarla según el movimiento de existencias y el riesgo de la empresa, y hay que acordar también si, durante un error de conexión, el producto se oculta, se deja a la venta o se pasa a una comprobación manual.

Importa distinguir la contabilidad interna de existencias de la tienda de un módulo de almacén o de una integración externa: las funciones básicas de WooCommerce pueden guardar la cantidad de cada producto y variante, reducirla tras el pedido e impedir pedir un producto sin existencias, y con eso puede bastar para un catálogo que se mantiene en la propia tienda. El módulo de almacén hace falta cuando la cifra principal de existencias vive en otro sistema, hay varios lugares de almacenamiento o hay que sincronizar varios canales de venta.

Antes del lanzamiento, ensaye la situación en la que el proveedor no puede servir el pedido aunque el producto aún aparece disponible en la pantalla de la tienda, y determine quién recibe el aviso, con qué rapidez se contacta al comprador, si se ofrece una alternativa y cómo se hace el reembolso. Ese escenario no convierte el modelo en malo, pero transforma una complicación inesperada en un riesgo manejable.

¿Se puede crear una tienda online gratis?

Crear una tienda online gratis puede significar varias cosas distintas, por ejemplo una plantilla de diseño gratuita, software de código abierto, un plan de prueba o el escaparate de una red social. Esas herramientas pueden reducir la cuota inicial de licencia y ayudar a comprobar si hay interés por la oferta, pero no eliminan el trabajo con los datos de los productos, los pagos, la entrega, las condiciones, la seguridad y la administración cotidiana.

Si crea la tienda usted mismo, empiece por el proceso más pequeño que se pueda ejecutar correctamente, porque un solo idioma, un catálogo reducido, una forma de pago y un método de envío permiten comprobar la demanda sin asumir el mantenimiento de integraciones complejas. También en esa versión el comprador debe ver el precio correcto y las condiciones de entrega, el pedido debe llegar a la administración, y usted debe poder enviar el producto y tramitar un desistimiento.

Los costes suelen aparecer donde termina la herramienta gratuita: en el dominio y el alojamiento, las comisiones de cobro, los plugins de pago, la importación de datos, la adaptación del diseño, el mantenimiento y su propio tiempo, así que no compare solo la suscripción mensual, sino también las horas que harán falta para el catálogo, la corrección de errores y las actualizaciones. Ya en la fase de prueba anote los trabajos repetidos, porque la herramienta gratuita puede ser económica justo mientras la atención manual no se coma el ahorro de la licencia. Si una operación manual la hace para cinco pedidos, puede estar justificada; para quinientos ya es una partida de coste medible.

La ayuda profesional se vuelve racional cuando el error cuesta más que la implantación o el proceso ya no cabe en la jornada de una persona, y de ese umbral pueden ser señal existencias que no coinciden, varios idiomas y grupos de precio, comprobaciones manuales reiteradas de datos o integraciones con la contabilidad y los proveedores. Una tienda hecha por cuenta propia no es un fracaso y contratar a un desarrollador no es el siguiente paso obligatorio; la decisión la marca la complejidad del proceso y la capacidad de la empresa para mantenerlo. En el equipo hace falta alguien que revise con regularidad las actualizaciones, las copias de seguridad, los avisos de seguridad y los registros de errores, y hay que poder restaurar el proceso de compra tras actualizar plugins y documentar la solución de modo que la tienda no quede atada al tiempo libre de un empleado.

Sea quien sea quien ejecute el trabajo, el dominio, el alojamiento, el proveedor de pagos y las cuentas de envío deben estar bajo el control de la empresa, no ligados a la dirección personal de un empleado o de un especialista externo; anote dónde se guardan los accesos, quién puede aprobar pagos y cómo se recupera el acceso si falta la persona responsable. En un proyecto hecho por cuenta propia ese orden es tan importante como en uno externalizado, porque los derechos de administración de la plataforma aún no significan control sobre el dominio, el servidor y los contratos de los servicios externos.

El contenido y la migración hay que prepararlos antes de cerrar el desarrollo

El proyecto de una tienda a menudo lo retrasa no el código, sino la falta de datos de productos, de imágenes y de decisiones, así que determine quién en la empresa entrega el contenido, quién lo aprueba y qué campos son obligatorios, y cada resultado intermedio necesita una fecha. El desarrollador puede crear el campo de la descripción, pero no puede decidir en lugar de la empresa qué se puede prometer del producto.

Las imágenes necesitan una proporción unificada, una resolución suficiente y derechos de uso; compruebe los nombres de archivo, los textos alternativos y qué foto pertenece a cada variante. Si el proveedor cambia las direcciones de las imágenes sin aviso, el enlace externo puede desaparecer, de modo que el proceso más seguro suele ser importar y optimizar las imágenes de forma controlada en el entorno de la tienda, conservando el vínculo con el identificador del producto.

En la migración hay que enumerar por separado productos, categorías, clientes, historial de pedidos, cupones, contenido y archivos, porque no todo se puede o se debe trasladar, y los datos históricos de clientes hay que valorarlos también desde el punto de vista de la protección de datos y de los plazos de conservación. Antes de la migración completa, haga una prueba con un conjunto pequeño de datos, compare el número de registros y los campos y solo entonces fije el momento a partir del cual en el sistema antiguo ya no se hacen cambios; tras la importación final, prepare un informe de registros que faltan, duplicados y valores que el sistema nuevo ha interpretado de otro modo.

Al cambiar de sitio web, prepare el mapa de direcciones antiguas y nuevas, porque una dirección sin redirección lleva al usuario y al buscador a una página inexistente, y la redirección por sí sola no garantiza las posiciones anteriores, pero sí ayuda a conservar un camino lógico y a pasar las señales a la página nueva que corresponde. Tras el lanzamiento, compruebe las direcciones más importantes de productos y categorías, no solo la de inicio.

Antes del lanzamiento, ejecute una prueba de aceptación completa

En la prueba de aceptación use un escenario realista de comprador con un producto concreto: abra la tienda en el teléfono, encuentre el producto con la búsqueda o la categoría, elija la variante, métala en el carrito y cambie la cantidad, y después compruebe el precio con impuestos, el descuento previsto y el envío. Siga hasta formalizar el pedido, pague y lea todas las pantallas y todos los correos.

Continúe la prueba en la administración: compruebe el estado del pedido, la reducción de existencias justo en la variante elegida, la dirección, la taquilla de recogida y la nota del comprador, cree el envío, envíe la información de seguimiento y cierre el pedido. Por último, formalice un desistimiento y un reembolso, porque el ciclo completo a menudo revela que cada función funciona por separado, pero la información no pasa de una función a otra.

Repita una prueba más corta con errores: un cupón no válido, una variante no disponible, un pago interrumpido, una dirección fuera de la zona de entrega y la última unidad del producto; el aviso de error debe explicar el siguiente paso, y el sistema no debe dejar una reserva incorrecta. El resultado de la prueba no es solo una lista de fallos, sino también la decisión de cuáles bloquean el lanzamiento. En cada corrección indique al responsable, la fecha de la nueva comprobación y la prueba de aceptación, y después asegúrese de que el error ya no se repite ni en el teléfono ni en el navegador del ordenador.

Compruebe también los ajustes de privacidad y de analítica, porque los scripts de analítica, publicidad u otro seguimiento no necesarios, cuya actividad exige consentimiento, no deben empezar a funcionar antes de la elección correspondiente, y la comprobación hay que hacerla también tras denegar el consentimiento y tras su retirada. Las operaciones técnicas necesarias para el pedido, en cambio, no deben dejar de funcionar si el comprador rechaza la analítica.

En el lanzamiento, nombre a los responsables y prepare un plan de actuación por si algo falla, fijando quién comprueba los pagos, la entrega y el contenido, a quién se informa de un error crítico y qué hacer si no se pueden aceptar pagos o los precios son incorrectos. A veces la decisión más segura es suspender los pedidos un tiempo, no recoger pedidos que no se pueden servir. En la comprobación del lanzamiento compare la configuración del entorno de prueba y del entorno público, las claves de pago, las cuentas de envío, los ajustes fiscales y el remitente del correo, porque una prueba correcta en otro entorno aún no demuestra que las mismas condiciones funcionen en la tienda a la que accede el comprador.

La administración y el mantenimiento empiezan antes del lanzamiento

El administrador de la tienda no es un rol abstracto que se asigna después de la entrega del proyecto, así que antes del lanzamiento determine quién tiene derecho a cambiar precios, publicar productos, hacer un reembolso y ver datos de clientes, porque no todo el mundo necesita todos los derechos. Al editor de contenido no suele corresponderle cambiar los ajustes de pago, y al empleado de almacén no le corresponde ver más información del cliente de la necesaria para preparar el envío.

Acuerde cómo se instalan las actualizaciones del sistema, de los plugins y de las integraciones, que no deben llegar por primera vez a la tienda pública un viernes por la tarde solo porque en el panel de administración ha aparecido un aviso. Hace falta una copia de seguridad, un entorno de prueba y una persona que, tras el cambio, ejecute una prueba corta de compra, porque una actualización puede afectar no solo al aspecto, sino también a las integraciones de cobro, envío y correo.

Determine quién se da cuenta de que los avisos de pago ya no llegan a la tienda, de que la interfaz de envíos responde con un error o de que el número de pedidos fallidos crece de golpe. La llamada del comprador no debe ser la primera señal de un fallo. Al menos para las integraciones críticas hace falta un registro de errores y un aviso al responsable, y para el equipo, un procedimiento de respuesta ante incidentes en el que se indique dónde se guarda la decisión sobre la solución temporal y con qué criterio se comprueba que el servicio se ha restablecido.

En las primeras semanas, las mediciones deben responder a preguntas de proceso, no solo contar visitas, así que compare las compras iniciadas y las terminadas, los errores de pago, las elecciones de envío y los motivos de atención al cliente. Si mucha gente se detiene en una misma etapa, compruebe primero un obstáculo técnico o de contenido antes de concluir que en el mercado no hay demanda.

Qué preparar antes de hablar con el desarrollador

Para que la primera conversación sea productiva, prepare un producto de muestra, un escenario completo de pedido y una situación de excepción, y añada el número aproximado de productos y variantes, los idiomas, los países y las formas de pago y de envío. Si ya hay un sitio web, indique qué quiere migrar y con qué sistemas debe intercambiar datos la tienda; no tiene que conocer la solución técnica, pero sí ser capaz de mostrar el trabajo de la empresa.

Nombre por separado los requisitos que deben estar en el primer lanzamiento y las ideas que se pueden aplazar: el proceso básico de pago y entrega suele ser un requisito de lanzamiento, mientras que un programa de fidelización complejo puede ser la etapa siguiente si sin él se puede aceptar y servir el pedido de forma correcta. Esa división protege el presupuesto mejor que tachar funciones a ciegas, porque cada trabajo aplazado conserva un motivo nombrado, una dependencia y el momento en que hay que volver a la decisión con datos reales de pedidos.

Con el producto de muestra, el escenario de pedido y la situación de excepción basta para determinar, en el estudio del proyecto de tienda online, un alcance de trabajo claro y comprobable, además de un plazo y un precio. En el presupuesto pida no solo los nombres de las funciones, sino también los límites: quién prepara los datos, quién configura el servicio externo y tras qué prueba se da el trabajo por aceptado.

Si ya tiene un catálogo o un esbozo del proceso, el siguiente paso es revisarlo con alguien que pueda valorar las dependencias técnicas; si aún no hay esbozo, podemos empezar por elaborarlo y decir qué no hace falta construir en la primera versión. Solicitar el estudio de un proyecto de tienda online es útil antes de elegir la plataforma, porque entonces el precio lo marca un alcance de trabajo claramente definido, no las suposiciones sobre lo que debería incluir la palabra «tienda». Las dos partes deben entender ya antes del desarrollo qué resultado comprobable acreditará que el proyecto está terminado.