No doy luz verde a un software multi carrier solo porque genera etiquetas: primero exijo probar el 100% de los flujos obligatorios y cerrar las fallas críticas.
En este checklist reúno lo que reviso antes de lanzar y durante el uso:
Mi criterio es simple: <u>si una falla impide despachar, compromete datos o duplica cargos, freno el lanzamiento</u>. La meta no es conectar más carriers, sino poder cumplir cada envío y saber qué hacer cuando algo falla.
Checklist de software multi carrier: del control al lanzamiento
Con el flujo base validado, auditá los contratos de datos que lo sostienen.
Exigí un mapeo aprobado. La tienda, el OMS, el WMS, el ERP y la plataforma de envíos deben compartir los ID de pedido y envío, SKU, cantidades, dirección, código postal, servicio, peso, dimensiones, valor declarado, costo y fecha prometida. Incluí también reservas de stock, cancelaciones, reintegros y devoluciones. En la interfaz, usá ; en la API, respetá el formato numérico definido.
Evidencia: catálogo de campos, payloads y trazas de éxito y error por flujo. Responsable: IT, con Operaciones. Go: 100% de los flujos obligatorios mapeados y probados, sin errores críticos abiertos.
| Punto de integración | Origen | Destino | Autenticación | Disparador | Regla de reintento | Responsable de monitoreo |
|---|---|---|---|---|---|---|
| Cotización | Tienda/OMS | Agregador o carrier | API key/OAuth | Checkout o simulación | Retroceso exponencial; no reintentar datos inválidos | IT |
| Creación de envío | OMS/WMS | Carrier | Credencial de alcance mínimo | Pedido listo para despachar | Clave idempotente fija; un solo reintento hasta el límite documentado | IT + Operaciones |
| Etiqueta | Carrier | OMS/WMS | Token del ambiente | Respuesta de creación | Reconciliar antes de crear otra etiqueta | Depósito |
| Tracking | Carrier | OMS/Atención al Cliente | Firma o token de consulta | Evento o consulta programada | Deduplicación y cola de fallos | IT |
| Costos y devoluciones | Plataforma/OMS | ERP/WMS | Credencial por ambiente | Costo confirmado o devolución aprobada | Reconciliación por identificador único | Operaciones + Finanzas |
Separá ambientes, credenciales, endpoints, cuentas, webhooks y datos de prueba. Guardá los secretos en un gestor de secretos, nunca en el código ni en los logs. Documentá los permisos mínimos y cómo rotar y revocar las credenciales.
Para las llamadas salientes, definí timeouts, límites y reintentos con retroceso exponencial y jitter. No reintentes automáticamente direcciones inválidas ni credenciales rechazadas. Si repetís una creación, conservá la misma clave idempotente.
Evidencia: matriz de ambientes y registros de fallas controladas, con respuestas HTTP, referencias externas y estado final. Responsable: IT. Go: ninguna credencial productiva funciona en pruebas, ningún pedido de prueba llega al carrier real y los reintentos generan cero envíos duplicados.
Con los campos alineados, revisá los eventos y webhooks.
Unificá códigos de servicio, estados, ubicaciones y excepciones. Conservá el payload original, el ID del evento y las horas de emisión y recepción. Usá ISO 8601 con zona explícita y, para el equipo, DD/MM/AAAA HH:mm.
Cuando haya firmas disponibles, verificalas sobre el cuerpo original. Persistí cada evento antes de responder y deduplicá antes de procesar.
Probá duplicados, demoras, eventos fuera de orden, firmas inválidas, campos faltantes y caídas. Un evento tardío no debe cambiar el estado de entregado a en tránsito. Documentá el polling de respaldo: frecuencia, ventana, protección ante rate limits y límite de consultas.
Evidencia: logs y matriz de pruebas. Responsable: IT. Go: cero envíos o mensajes duplicados, cero retrocesos incorrectos y eventos inválidos aislados en cuarentena o DLQ para revisión. Cualquier falla de integridad bloquea el lanzamiento.
Después, comprobá que esas señales activen las reglas y promesas correctas.
Versioná las reglas por código postal, provincia, depósito, bultos, peso, dimensiones, restricciones, valor declarado, tarifa, capacidad y fecha solicitada. Cada regla debe definir el servicio elegible y la promesa al cliente.
Probá los límites exactos, los destinos sin cobertura y los pedidos fuera del horario de corte. Calculá las fechas con America/Argentina/Buenos_Aires, los feriados argentinos aplicables y los calendarios de retiro vigentes. No sumes días corridos a un SLA expresado en días hábiles.
| Condición | Servicio elegido | Respaldo | Promesa al cliente | Escalamiento |
|---|---|---|---|---|
| Más de un servicio cumple plazo y capacidad | Más barato elegible | Preferido elegible | Fecha desde el retiro confirmado | Operaciones si cambia la capacidad |
| La fecha solicitada exige menor tránsito | Más rápido elegible | Otro que cumpla la fecha | Fecha validada contra el compromiso contratado | Operaciones y Finanzas si excede presupuesto |
| Si el cliente eligió un servicio | Servicio elegido habilitado | Alternativa aprobada | Condiciones del servicio confirmado | Atención al Cliente antes de modificarlo |
| Carrier caído o sin cupo | Respaldo elegible | Revisión manual | Recalcular antes de comunicar | IT y Operaciones |
| Restricción de producto o destino | Sin etiqueta automática | Revisión manual | Pendiente de validación | Depósito y Atención al Cliente |
Evidencia: decisiones reproducibles con entradas, versión de regla, servicio, costo y fecha. Contrastalas con el compromiso del carrier y los retiros reales del piloto. Responsable: Operaciones, con aprobación de Depósito, Atención al Cliente, Finanzas e IT. Go: 100% de los casos elegibles tienen una promesa válida; 0% de los restringidos recibe etiqueta automática; cada excepción tiene responsable. Separá los resultados de CABA, GBA e interior y bloqueá las reglas que seleccionen servicios no elegibles.
Con las reglas y promesas aprobadas, validá el circuito físico, los webhooks y las excepciones. Probá de punta a punta cada carrier y servicio: incluí destinos de CABA y del interior, datos válidos e inválidos, sandbox y producción controlada.
Registrá las entradas, los resultados y la evidencia de cada prueba. El responsable principal coordina con IT, Operaciones, Depósito, Finanzas y Atención al Cliente, según corresponda.
| Escenario | Resultado esperado | Evidencia requerida | Severidad si falla | Responsable principal |
|---|---|---|---|---|
| Cotización y reserva | El servicio y el costo coinciden con lo aprobado | Cotización, reserva y comprobante de costo | Mayor | Operaciones |
| Impresión y manifiesto | Etiqueta legible; bultos y documentos completos | Impresión real, escaneo y manifiesto | Crítica | Depósito |
| Envío dividido o parcial | Cada bulto tiene tracking propio | Pedido, bultos y cumplimiento parcial | Mayor | Depósito |
| Cancelación, corrección y reimpresión | Se anula lo anterior cuando corresponde, sin duplicar el envío ni el cargo | Etiquetas, anulaciones y cargos | Crítica | IT |
| Retiro, entrega e intento fallido | El estado y la próxima acción están visibles | Retiro real, tracking público, escaneos y mensajes | Mayor | Operaciones |
| Devolución y recepción | Se cumplen la autorización, la inspección y el reintegro o cambio | Autorización, recepción en depósito y registro financiero | Crítica | Depósito |
| Pico e indisponibilidad del carrier | El sistema se recupera dentro de los umbrales, sin pérdidas ni duplicados | Métricas, colas y conciliación | Crítica | IT |
Con estos casos cubiertos, verificá la salida física y la lectura de las etiquetas en depósito.
No apruebes solo el PDF: imprimí y escaneá con el hardware real de cada estación. Revisá el tamaño y la orientación exigidos, el remitente, el destinatario, el servicio, las condiciones de facturación, el peso y las dimensiones. Agregá la documentación aduanera cuando corresponda.
Depósito e IT deben aprobar la salida impresa y los logs de envíos divididos, cumplimiento parcial, cancelaciones, correcciones y reimpresiones. Una etiqueta ilegible, un documento obligatorio faltante o un envío duplicado bloquean el lanzamiento.
Seguí en el software todo el recorrido, desde la etiqueta hasta la recepción en depósito. Incluí retiro, tránsito, intento fallido, entrega, excepción y devolución al remitente.
Aunque falle el tracking, la devolución debe seguir el circuito previsto. Comprobá la autorización, el motivo, la etiqueta, la inspección y el disparador del reintegro o cambio. Recibir un paquete no debe generar un reintegro automático sin la validación prevista.
Operaciones, Depósito, Finanzas y Atención al Cliente deben aprobar sus pasos y contar con procedimientos para resolver direcciones incorrectas, demoras, daños y falta de capacidad.
Separá el SLA del software del compromiso logístico del carrier. Antes de probar, definí umbrales, ventana de medición, alertas y responsables para cotizaciones, etiquetas, demora de webhooks, actualización del tracking, disponibilidad y tiempos de respuesta y resolución de soporte. Medí las latencias p50 y p95 en operación normal y en hora pico: el promedio solo no alcanza para aprobar.
Simulá timeouts, cotizaciones fallidas, errores 429, impresoras detenidas e indisponibilidad del carrier. Usá logs, colas y conciliación para demostrar que el sistema se recupera sin pérdidas ni duplicados y que cada evento queda trazado.
La alternativa de respaldo debe respetar las restricciones: si no hay un servicio elegible, el pedido queda retenido. IT y Operaciones aprueban la recuperación, con la conformidad de Depósito y Atención al Cliente. Las fallas críticas abiertas o los umbrales incumplidos bloquean el avance.
Con los flujos validados, prepará los controles de auditoría, soporte y reversión antes del lanzamiento.
TI debe aprobar una matriz de permisos por rol, con MFA y acceso mínimo. Depósito imprime etiquetas; Finanzas aprueba reintegros; solo el personal autorizado cambia credenciales e integraciones. Definí los plazos de retención y eliminación de datos personales, la capacitación por turno y una matriz de escalamiento con responsables, suplentes, severidades y plazos.
Centralizá los logs y protegelos contra modificaciones. Cada cambio de permisos, reglas o configuración debe incluir fecha, hora, responsable, valores anteriores y nuevos, y resultado. Registrá la rotación de credenciales, nunca sus valores. TI conserva la evidencia de accesos y valida la retención con Seguridad.
Una vez auditados los accesos y la trazabilidad, validá la atención al cliente y la derivación humana.
Atención al Cliente debe aprobar los textos, los permisos del canal, las plantillas, los límites de aprobación y el responsable de cada derivación. Si usás Burbuxa, verificá qué eventos recibe del stack conectado y cómo deriva la atención.
Probá confirmaciones, demoras, intentos fallidos, devoluciones y reintegros. En cada caso, el operador debe recibir el historial y el estado actualizado. Vinculá cada mensaje con un solo evento y suprimí los duplicados y los avisos pendientes después de la entrega o resolución. En WhatsApp, verificá la automatización y las plantillas aprobadas para mensajes iniciados por la empresa fuera de la ventana de atención de 24 horas.
Limitá el piloto por depósito, región o grupo de carriers. Documentá el volumen máximo, la ventana de observación, los umbrales de avance y quién puede detenerlo. Asigná personas concretas a la guardia operativa y técnica, con cobertura durante todo el piloto. Antes de ampliar el alcance, compará los resultados con los umbrales aprobados.
Usá estos criterios para decidir si el piloto pasa a producción.
| Criterio | Evidencia requerida | Responsable | Decisión go/no-go |
|---|---|---|---|
| Permisos y auditoría | Matriz aprobada, MFA y revisión de accesos | TI/Seguridad | Bloquea por privilegios excesivos o falta de trazabilidad |
| Capacitación y soporte | Evaluación práctica, simulacro y cobertura por turno | Operaciones | Bloquea por cobertura insuficiente |
| Mensajes y derivación | Plantillas aprobadas, supresión de avisos y derivación humana probada | Atención al Cliente | Bloquea por mensajes duplicados o sin aprobar |
| Piloto y monitoreo | Límites, alertas, métricas y ventana de observación | Operaciones | Bloquea sin umbrales |
| Reversión | Ejecución documentada y respaldo manual disponible | TI | Bloquea sin prueba de reversión |
| Bloqueos críticos | Registro de defectos de seguridad, datos, carrier o impacto al cliente | Comité de lanzamiento | Bloquea con defectos críticos abiertos |
Ensayá la reversión antes de habilitar envíos reales: detené nuevos envíos automáticos, restaurá la versión aprobada y activá el circuito manual. Operaciones solo autoriza el lanzamiento con todos los criterios obligatorios aprobados y sin bloqueos críticos. Registrá versión, fecha, hora, alcance, responsables y autoridad para revertir.
Con el sistema en marcha, pasá de la validación inicial al control de la operación. Mantené evidencia actualizada de integraciones, etiquetas, ruteo, tracking, devoluciones, SLA, permisos y soporte. Revisá todo semanalmente durante los primeros 30 días y, después, una vez por mes. Cada trimestre, revisá también carriers, contratos y reglas de ruteo.
Enfocate en las métricas de producción y las excepciones reales:
Si un indicador se desvía, actuá de inmediato. Operaciones mantiene el tablero y el registro de acciones, con causa, impacto, responsable, vencimiento y evidencia de corrección. Si se supera un umbral, corregí, pausá la expansión o revertí el cambio según la gravedad y la autoridad definida. Que la alerta baje no alcanza para cerrar una acción: verificá que el problema esté resuelto.
Cada cambio de carrier, tarifa, regla, integración o depósito exige repetir las pruebas afectadas: etiquetas, cancelación, webhooks, tracking, devoluciones, facturación y avisos al cliente. Considerá implementar una automatización de WhatsApp para TiendaNube para agilizar estas notificaciones. Guardá la fecha, el resultado y la aprobación de esas pruebas, y actualizá el checklist para que refleje la operación real.
Priorizá el control y la seguridad antes de automatizar flujos complejos. Primero, restringí los accesos y configurá permisos por roles (RBAC) para limitar el impacto de posibles incidentes.
Después, verificá que el contenido respete los formatos locales: moneda ($ 1.234,56), fechas (DD/MM/AAAA) y zona horaria (GMT-3).
Antes del lanzamiento, probá el proceso completo con una compra real. Así podés confirmar que tu tienda y los canales de mensajería estén sincronizados.
No hay una cantidad fija de envíos para validar el piloto. Antes de pasar a producción, hacé pruebas de punta a punta: revisá los datos, las reglas de negocio, los importes en pesos argentinos (ARS), los reembolsos, los cambios con actualización de stock y las derivaciones a un agente con el historial completo.
Simulá picos de tráfico y comprobá que el stock se actualice en menos de 60 segundos y que los pedidos se confirmen en menos de 5 minutos. En todos los casos, respetá el consentimiento del usuario.
El abono mensual es solo una parte del costo. Sumá el desarrollo, la integración, el mantenimiento, la configuración y las pruebas de punta a punta y bajo carga. El esfuerzo técnico depende de si usás una integración nativa o a medida.
Contemplá también el tiempo para probar fallas, reintentos y controles de reembolsos y descuentos. Antes del lanzamiento, documentá las pruebas con datos reales en un entorno de pruebas y verificá que los montos y estados coincidan.
