Despacho por comuna en WooCommerce: el problema de las tarifas de Chilexpress y Starken

El despacho es donde muchas tiendas WooCommerce chilenas se rompen en silencio. El catálogo carga, el carro funciona, el pago aprueba, y recién en el checkout aparece el problema real: WooCommerce no entiende qué es una comuna. Piensa en países, estados y, en el mejor de los casos, regiones. Chile tiene 16 regiones y 346 comunas, y el costo de un envío no depende de la región sino de la comuna exacta a la que va el paquete. Esa brecha entre cómo modela WooCommerce el territorio y cómo cotiza Chilexpress o Starken es el origen de casi todos los dolores de envío que vemos en una operación B2B.

Por qué el selector de comuna no viene de fábrica

WooCommerce trae un campo de estado/región y un campo de ciudad de texto libre. Para Chile eso significa que, sin intervención, el cliente escribe su comuna a mano. El resultado es predecible: "Ñuñoa", "Nunoa", "ñuñoa" y "NUNOA" conviven en la misma base de datos. Cuando después intentas calcular un flete o exportar las órdenes a la guía de despacho, no tienes un dato normalizado contra el cual cruzar tarifas. La comuna es la unidad de cálculo en Chile, y WooCommerce la trata como texto decorativo.

La base para resolverlo es un plugin que reemplace el campo libre por dos selectores encadenados: primero región, y según la región elegida, las comunas que le corresponden. El plugin Comunas de Chile hace exactamente esto: inyecta la división política completa al checkout y deja la comuna como un valor cerrado y consistente. No es opcional para una tienda seria. Es el cimiento sobre el que se apoya cualquier cálculo de tarifa posterior; sin un dato de comuna limpio, todo lo demás cotiza sobre arena.

El problema de los plugins de courier

El paso siguiente parece directo: instalar el plugin oficial del courier y dejar que cotice solo. En la práctica es donde más operaciones se accidentan. Varias de estas integraciones todavía conversan con servicios SOAP antiguos, lentos y sensibles a cualquier cambio del lado del courier. Cuando el endpoint se cae o responde fuera de tiempo, el checkout se queda sin opciones de envío y la venta se evapora justo en el momento de pagar.

A eso se suma la cobertura. Estos plugins suelen traer la tabla de ciudades o comunas que el courier tenía cargada al momento de la versión, y casi siempre hay comunas faltantes: localidades de regiones extremas, comunas nuevas, o nombres que el courier escribe distinto al estándar. Cuando un cliente de una comuna no mapeada llega al checkout, el plugin no devuelve tarifa. Si no hay un plan B, ese cliente no puede comprar. En B2B ese cliente sin tarifa puede ser justamente el mayorista de regiones que más te interesa.

Una integración de courier sin fallback no es una integración: es un punto único de falla conectado directo a tu checkout.

El costo de cobrar "a ojo"

Frente a esta fragilidad, la tentación es renunciar al cálculo real y poner un flete plano: un monto fijo para todo Chile, o dos o tres tramos gruesos. Es simple de configurar y nunca se cae. También es caro de las dos maneras posibles.

• Si fijas el flete bajo para no espantar la venta, pierdes margen en cada envío a regiones, donde el courier te cobra bastante más de lo que cobraste tú. En un negocio mayorista, con pesos y volúmenes altos, esa diferencia se acumula rápido.
• Si fijas el flete alto para cubrirte, encareces el envío a Santiago y a las comunas cercanas, que son la mayoría de tus pedidos, y empujas a esos clientes a abandonar el carro o a pedir por WhatsApp para que les coticen aparte.

Cobrar "a ojo" no es ahorrarse el problema: es trasladárselo a tu margen o a tu tasa de conversión. En una operación con volumen, ninguno de los dos es barato.

La solución por capas

El despacho confiable en Chile no se resuelve con un plugin, sino con tres capas que se cubren entre sí. Cada una asume que la siguiente puede fallar.

1. Selector región → comuna (la base)

Con Comunas de Chile o equivalente, el cliente elige su comuna de una lista cerrada. Esto normaliza el dato y habilita todo lo que viene después. Sin esta capa, las otras dos no tienen una llave limpia sobre la cual cotizar.

2. Tarifa por comuna desde el courier, con fallback

Sobre la comuna normalizada se calcula el costo real. Aquí conviene diseñar para la caída: si la API de Chilexpress, Starken o BlueX no responde, el sistema no deja al cliente sin envío, sino que recurre a una tabla de tarifas por comuna cargada localmente. La tabla es menos precisa que la consulta en vivo, pero cotiza siempre, y eso vale más en el checkout que la última cifra exacta. La regla es simple: el cliente nunca debe quedar sin opción de envío por un problema que no es suyo.

3. Validación de dirección

La última capa cuida lo que el cliente escribe. Validar que la comuna seleccionada sea coherente con la región, y que la dirección tenga la forma mínima que el courier exige, evita guías rechazadas y reenvíos. Un despacho que falla en la bodega del courier cuesta más que uno bien cotizado, porque ya gastaste el picking, el embalaje y el viaje.

Tabla de tarifas o API en vivo: el criterio

No toda tienda necesita consulta en vivo. La pregunta correcta no es cuál es más sofisticada, sino cuál corresponde a tu operación.

Situación	Conviene
Productos de peso y dimensiones estables, despacho a un set acotado de comunas, tarifas que cambian pocas veces al año	Tabla de tarifas por comuna
Catálogo con pesos muy variables, envíos a todo Chile, courier que ajusta precios con frecuencia o cobra por volumen	API en vivo (con tabla como fallback)
Operación mayorista con pedidos grandes donde un error de flete borra el margen de la orden	API en vivo, validada contra la guía real

Una tabla bien mantenida le gana a una API en vivo mal integrada. La consulta en vivo solo aporta cuando la variabilidad de tus envíos es real y cuando hay alguien que la cuide: la integración se mantiene, se prueba y se monitorea. Una API que nadie revisa termina siendo una tabla desactualizada con pasos extra y más superficie para fallar.

El despacho por comuna no es un detalle de configuración, es la capa donde se decide si la tienda gana o pierde plata en cada pedido. La diferencia entre una tienda que aguanta y una que se cae en el checkout no está en qué courier eligió, sino en si alguien diseñó las capas pensando en que cada una puede fallar. Esa es la parte que la demo no muestra y que recién se nota cuando llega el pedido de la comuna que el plugin no tenía.