Este texto trata de ese segundo coste: qué consume horas, cuánto duran las reparaciones, cómo es el ciclo de actualizaciones y cuántas horas al mes necesitan tres perfiles. Las cifras son órdenes de magnitud de nuestro trabajo, no una promesa. Si su tienda necesita tres horas al mes y se las arregla solo, también es un buen resultado.
Por qué una tienda WooCommerce consume horas de otro modo que una tienda SaaS
En SaaS la actualización del núcleo ocurre sin su participación. El riesgo se concentra en las apps del marketplace, la plantilla y el código propio, el resto es problema del proveedor.
En WooCommerce es al revés. El núcleo rara vez es el origen del problema. Una tienda con algunos millones de euros de facturación tiene entre una docena y varias decenas de plugins activos, cada uno con su ritmo. Los de pago dejan de actualizarse al caducar la licencia, los gratuitos cuando el autor abandona el proyecto. Es esa capa, no el núcleo, la que genera trabajo: no hay calendario común, ni proveedor común, ni un sitio donde se vea qué ha cambiado.
La segunda diferencia es que usted responde también de la capa de debajo: servidor, versión de PHP, base de datos, caché. En SaaS no existe para usted. Aquí existe y puede provocar una caída que parece un fallo de la tienda.
Cinco cosas que de verdad rompen las tiendas WooCommerce
Conflicto de plugins tras una actualización. Síntoma: tras una actualización nocturna falla un elemento concreto, casi siempre el punto de recogida, un cupón o el envío de la factura. Causa: dos plugins tocan el mismo momento del proceso de pedido y uno cambió su forma de hacerlo. Magnitud: de 1 a 4 horas con una copia anterior para comparar, bastante más sin ella.
Base de datos sobrecargada. Síntoma: el panel va más lento, la lista de pedidos tarda una decena de segundos, la tienda se atasca con tráfico. Causa: una tabla wp_options hinchada de entradas cargadas en cada petición (autoload), restos de plugins eliminados y pedidos guardados como entradas y metadatos en lugar de HPOS, las tablas dedicadas. Magnitud: de 3 a 8 horas. HPOS es un proyecto aparte y se activa tras probar la lista completa, donde los incompatibles son el problema habitual.
Carrito y pago. Síntoma: tras un cambio de plantilla o una actualización desaparece un campo necesario, o la página de pago se ve distinta que ayer. Causa: WooCommerce tiene dos variantes, clásica en shortcodes y nueva en bloques, y algunos plugins solo admiten una, así que un modo en el carrito y otro en el pago genera errores difíciles de reproducir. Magnitud: de 2 a 6 horas para unificar ambas páginas, más si hay que sustituir un plugin.
Licencias caducadas de módulos de pago. Síntoma: el plugin funciona pero no se actualiza, y en el panel aparece un aviso sobre la clave. Causa: la licencia caducó o se compró con la cuenta privada de alguien que ya no está en la empresa. Magnitud: de 15 minutos a 2 horas por plugin si se recupera el acceso a la cuenta de compra, si no, toca recomprar.
Rendimiento con un catálogo grande. Síntoma: filtrar y buscar en una categoría de varios miles de productos tarda demasiado, la importación de precios del ERP bloquea la tienda. Causa: consultas sobre metadatos, falta de índices, importación en un solo proceso largo. Magnitud: de 6 a 20 horas, porque no es una reparación, es rehacer un mecanismo.
Repasamos incidencias típicas en el texto sobre las averías más frecuentes en tiendas online.
Actualizaciones: por qué no las hacemos de forma automática
Actualizar todo en automático es la forma más barata de que la tienda deje de aceptar pedidos de madrugada sin que nadie se entere hasta la mañana. Si una docena de plugins tocan el proceso de compra, actualizar sin probar es una apuesta.
Nuestro procedimiento: una copia va al entorno de pruebas, instalamos allí los cambios, recorremos la compra con un pago de prueba y comprobamos envío, factura y traspaso al almacén. Solo después pasa a producción, con copia de seguridad hecha justo antes. Las críticas, las que cierran vulnerabilidades, van rápido y en ciclo aparte, el resto lo agrupamos.
En horas del paquete: con una docena de plugins el ciclo son de 1 a 2 horas al mes, con varias decenas e integración con ERP suelen ser de 3 a 6, porque no crece el número de clics sino el de rutas que revisar. A eso se suman los casos en que la actualización no pasa la prueba.
Cuántas horas al mes necesita realmente una tienda WooCommerce
Tres perfiles que vemos con más frecuencia.
Tienda pequeña y estable. Unos cientos de productos, una docena de plugins, sin ERP, cambios de banners, promociones y contenido. Consumo real: de 5 a 8 horas al mes, la mitad actualizaciones y revisiones. Paquete Basic por 220 EUR con 10 h.
Tienda mediana en crecimiento. Unos miles de productos, integración con almacén, varios canales de pago y envío, cada mes una función o campaña nueva. Consumo real: de 15 a 20 horas al mes. Paquete Advanced por 440 EUR con 20 h.
Tienda grande multicanal. Catálogo amplio, precios B2B, feeds a comparadores y marketplaces, varios entornos, trabajo continuo en conversión. Consumo real: de 30 a 40 horas al mes. Paquete Premium por 880 EUR con 40 h.
La hora dentro del paquete cuesta 22 EUR y fuera 35 EUR, con servicio en días laborables de 8 a 18. El paquete se elige por el alcance previsto de cambios, no por el tamaño de la empresa. Una tienda con 3 millones de euros de facturación que no cambia nada en un año cabe en Basic. Una con 450.000 euros que entra en un marketplace y reconecta su ERP agotará Advanced. Para el cálculo completo, con hosting y licencias, tenemos un texto sobre el coste de mantener una tienda online.
Qué debería incluir el mantenimiento de WooCommerce y casi nunca incluye
Una lista para su proveedor actual, cinco preguntas que caben en un correo.
- Quién tiene las licencias de pago y con qué cuenta se compraron. La respuesta "eso lo tiene la agencia" es mala, deberían ser suyas.
- Si existe entorno de pruebas y cuándo se sincronizó con producción. Uno de hace un año no lo es.
- Si alguien lleva los vencimientos de licencias y certificado, y quién recibe el aviso.
- Quién tiene acceso a servidor, panel de hosting y base de datos, y quién solo a WordPress. En una caída la diferencia es decisiva.
- Si hay copias de seguridad y si alguien ha restaurado alguna vez la tienda. Una copia sin probar es una suposición, no una protección.
En nuestros contratos la restauración se prueba y se registra cada trimestre, porque ahí suele verse que algo lleva meses sin funcionar.
La frontera entre soporte y SLA en el caso de WooCommerce
El soporte técnico es una bolsa de horas para los cambios que encarga usted: una regla de descuento, un campo más en el formulario, actualizaciones de plugins, un arreglo en la plantilla de correo, mover un feed. Usted lo notifica, nosotros lo hacemos, las horas salen de la bolsa y el consumo se ve en Gorilla Panel.
El SLA responde al otro tipo de suceso: la tienda o una función clave deja de funcionar y usted quiere saberlo antes que el cliente. La tienda se comprueba cada 60 segundos, una persona verifica cada alerta y un suceso crítico recibe diagnóstico y nota posterior. Garantizamos el tiempo de reacción, no el de resolución: la causa puede estar en el hosting o en una pasarela externa, fuera de nuestro control. La supervisión empieza en 210 EUR al mes. La diferencia la desarrollamos en el texto soporte técnico o SLA.
Una tienda WooCommerce necesita ambas por un motivo distinto al de una tienda SaaS: la actualización de plugins es el suceso tras el que algo falla con más frecuencia, y el mismo ciclo genera trabajo planificado y un riesgo que vigilar.
Asumir una tienda llevada antes por otro proveedor
No empezamos por los cambios, sino por fijar el estado real. Auditoría técnica: versiones, PHP, estado de la base de datos, forma de guardar los pedidos, modo de carrito y pago, código propio en el tema hijo. Inventario de plugins: gratuitos, de pago con licencia vigente, de pago con licencia caducada y abandonados. Accesos ordenados: servidor, panel de hosting, dominio, cuentas de compra, repositorio si existe.
Suelen ser de 8 a 16 horas y terminan en una lista de tareas, separada entre riesgo ahora y lo que puede esperar. Solo después tiene sentido hablar de paquete: solo entonces se sabe cuántas horas al mes consume esta tienda.
Compare los paquetes de soporte y niveles de SLA en /es/sla-help-desk y elija el que encaje con los cambios previstos para el próximo trimestre. Si prefiere empezar por datos, introduzca su dirección en Tester eCommerce: recibirá un diagnóstico gratuito del estado técnico, útil también con su proveedor actual.