Cómo montar un programa de garantías en Shopify (el playbook del operador)

La mayoría de marcas en Shopify venden una garantía sin haber decidido nunca qué es realmente su garantía. La PDP dice "garantía de por vida" o "hecho para durar" — y un año después llega la primera tanda de reclamaciones al inbox y nadie sabe contestar la pregunta básica: ¿qué le debemos exactamente a este cliente?

El coste aparece en tres sitios. (1) CS se gasta 20–40 minutos por reclamación improvisando una decisión por email. (2) Se emiten reembolsos por cosas que deberían haber sido un reemplazo de 7$. (3) Los clientes recurrentes se van porque el email de reclamación rechazada parecía una amenaza legal.

Un programa de garantías no es un centro de coste de CX. Bien hecho, es una palanca de margen — convierte el "te debemos algo" en un workflow estructurado con coste-por-reclamación predecible, un rastro de auditoría y un mecanismo de retención integrado. Este es el playbook que usamos con marcas que llevan Ecombone Warranty Claims, ordenado tal y como lo haríamos si arrancáramos tu programa de garantías mañana.

Paso 1 — Decide qué garantía ofreces realmente

Antes de la política, antes del tooling, antes de una sola plantilla de email: decide qué estás prometiendo. La mayoría de marcas se salta este paso y lo paga después.

Las cuatro preguntas que tienes que responder por escrito:

1. Duración. ¿De por vida? ¿Limitada a 12 meses? ¿24 meses? ¿5 años? Distintos productos en tu catálogo pueden tener distintas duraciones — apparel a 12 meses, hardware a 24, joyería de por vida es un split habitual.
2. Qué cubre. ¿Solo defectos de fabricación? ¿O también desgaste por uso normal? ¿O daño accidental? Cada cosa que añades multiplica aproximadamente el volumen de reclamaciones.
3. Qué se excluye. Sé explícito de forma agresiva. "Mal uso," "reparaciones por terceros," "pérdida o robo," "desgaste estético que no afecta a la función." La ambigüedad es de lo que vive el fraude en reclamaciones.
4. Quién la lleva. ¿Solo el comprador original, o transferible? Solo-comprador-original es mucho más fácil de aplicar (compruebas el pedido), pero las garantías transferibles son un flex de marketing si te aguantas el coste.

Una plantilla útil:

¿Garantía extendida como add-on de pago? Vale la pena considerarlo si tu AOV está por encima de ~120$ y tu categoría tiene ansiedad real por modos de fallo (electrónica, outdoor, hogar premium). Se attachea a un 8–15% de pedidos a 70–85% de margen y sube el AOV. No lo metas el día uno — pon limpia primero la garantía gratuita, después capa la de pago encima.

Paso 2 — Escribe la política que el cliente leerá Y que tu CS team puede aplicar

Una política que vive solo en el footer en gris a 8pt no es una política. Es deniability plausible. Escríbela como operador, no como abogado.

Lo que tiene que contener, en lenguaje llano:

• Duración, por categoría de producto si hace falta.
• Qué se cubre y qué se excluye, la lista exacta del Paso 1.
• Ventana de reclamación — en cuántos días desde la compra debe presentarse la reclamación. 90 días es generoso, 365 es estándar, "en cualquier momento dentro del periodo de garantía" es lo mejor para confianza pero lo más difícil de operar.
• Prueba requerida — número de pedido, foto del defecto, foto del producto completo, foto del packaging si aplica. Sé específico sobre qué fotos.
• Tipos de resolución que ofreces — Reemplazo, Reembolso, Saldo en tienda — y cuál se ofrece cuándo.
• Tiempo de respuesta — "respondemos en 2 días laborables" es una promesa que construye confianza si la cumples de verdad.

Hospédala en una página dedicada /pages/warranty enlazada desde el footer, con un bloque de resumen de dos líneas en cada PDP y una sección en el email de confirmación de pedido. La colocación en PDP es la que la mayoría de marcas se salta y no debería — un badge de "garantía de 12 meses" en un producto de 90$ es palanca de conversión, no solo un disclosure de CX.

Paso 3 — Construye el intake de reclamaciones: manual vs self-service

Tienes dos arquitecturas. Elige a propósito.

Intake manual / por email. El cliente escribe a soporte, adjunta foto (o no), el agente de CS lee, pide info que falta, decide, contesta. Funciona a poco volumen. Se rompe a escala. Sin rastro de auditoría, sin motor de reglas, sin analítica — y el cliente espera 3–5 días la respuesta.

Portal self-service. El cliente mete número de pedido + email, elige el artículo, elige un motivo, sube fotos, envía. El portal evalúa contra reglas y o auto-resuelve, marca para revisión, o rechaza con un motivo. CS solo gestiona la zona gris.

La cuenta a 50 reclamaciones/mes:

Eso son ~8,5 horas de CS al mes — aproximadamente 250–400$ — recuperadas por una suscripción de app de 19–49$/mes. La cuenta se vuelve más asimétrica cuantas más reclamaciones procesas. Más allá del trabajo: un portal te da el rastro de auditoría que convierte la garantía de caja negra en dataset.

Paso 4 — El motor de reglas: este es el punto de palanca

Esta es la parte que la mayoría de marcas infraconstruye. Sin reglas, cada reclamación es un juicio. Con reglas, el 60–80% de reclamaciones se auto-deciden y tu CS team solo toca los edge cases reales.

Piensa en el motor de reglas como una lista if-then ordenada por prioridad. La primera regla que matchea gana. Eliges el orden explícitamente — las reglas genéricas van al final, las específicas van arriba.

Una lista de reglas real, en orden de prioridad:

1. SI claim_reason = "defecto de costura"
   Y product_tag CONTIENE "core_apparel"
   Y days_since_purchase <= 30
   Y photo_evidence = true
   → AUTO-APROBAR Reemplazo

2. SI claim_reason = "dañado a la llegada"
   Y days_since_purchase <= 14
   Y photo_evidence = true
   → AUTO-APROBAR Reemplazo

3. SI product_tag CONTIENE "lifetime_warranty"
   Y claim_reason EN ("cierre", "piedra", "baño")
   Y photo_evidence = true
   → ENRUTAR A REVISIÓN MANUAL (alta prioridad)

4. SI days_since_purchase > 365
   Y product_tag NO CONTIENE "lifetime_warranty"
   → AUTO-RECHAZAR con motivo "fuera de la ventana de garantía"

5. SI photo_evidence = false
   → AUTO-RECHAZAR con motivo "se requiere prueba fotográfica, por favor reenvía"

6. TODO LO DEMÁS → REVISIÓN MANUAL

Lee esa lista de arriba abajo: las reclamaciones triviales válidas se auto-resuelven en segundos, el abuso obvio se rechaza con un motivo claro, las reclamaciones de por vida / alto valor se enrutan rápido a un humano, todo lo demás entra en cola para revisión. El motor de reglas en Ecombone Warranty Claims matchea exactamente sobre estos inputs — motivo de reclamación, tags de producto, días desde compra, flag de garantía de por vida — porque esta es la estructura que funciona en operación. Dos horas de setup de reglas eliminan el 60–70% de tu futuro tiempo de CS en garantías.

Paso 5 — Política de fotos y evidencias

La palanca anti-fraude más efectiva en un programa de garantías es hacer que la prueba sea obligatoria y específica.

Mala petición: "por favor envía una foto del problema."

Buena petición:

• Una foto en primer plano del defecto (enfocada, bien iluminada).
• Una foto del producto completo para ver que es el artículo de tu pedido.
• Una foto del packaging o de la etiqueta de envío si el producto llegó dañado.

Especificar qué fotos mata el 60–70% de las reclamaciones fraudulentas o especulativas de bajo esfuerzo. El cliente que se lo está inventando no tiene la segunda y la tercera foto. El cliente con un problema real ya tiene las tres en el móvil.

Specs operativas: acepta JPEG, PNG, WebP; capa el tamaño de archivo a 5MB por imagen; permite 1–5 fotos por reclamación; guárdalas contra el registro de la reclamación para siempre (tu rastro de auditoría cuando llegue un chargeback más adelante). El portal debería negarse a avanzar el formulario sin las fotos requeridas — "se requiere prueba fotográfica" como sugerencia blanda es funcionalmente igual que no requerirla.

Paso 6 — Defaults de resolución: la lógica del operador

Cuando apruebas una reclamación, tienes tres tipos de resolución. Elige el que tu matemática soporte, no el que el cliente pida.

Reemplazo. Envía otra unidad. Coste = tu COGS. En un producto de 50$ con 30% de COGS, el reemplazo te cuesta ~15$ más el envío de retorno si pides la unidad defectuosa de vuelta.

Saldo en tienda. Emite un código de un solo uso. Coste = el margen futuro al que renuncias cuando lo canjea. Con un bonus del +10% ("50$ pagados, 55$ de saldo"), tu coste real es el margen perdido sobre 5$ — normalmente 2–3$ — si y solo si canjea y convierte.

Reembolso. Dinero de vuelta a la tarjeta. Coste = revenue completo. En un producto de 50$, un reembolso es un golpe de 50$. La peor opción para margen, pero a veces la única correcta.

La matriz de decisión que recomendamos:

La matemática es todo el juego. Un producto de 50$ con 30% de COGS:

• Reemplazo → 15$ de coste.
• Saldo en tienda al +10% → ~3$ de coste esperado.
• Reembolso → 50$ de coste.

Si reembolsas reflejamente cada reclamación, estás pagando 3–15× más por reclamación de lo que necesitas. Por defecto, Reemplazo cuando el stock lo permita; Saldo en tienda cuando no; Reembolso solo cuando el cliente convierte el reembolso en el único resultado aceptable. El portal debería mostrar Reemplazo primero, Saldo en tienda segundo (con el bonus), Reembolso tercero. Los defaults mueven la aguja.

Paso 7 — Automatización de emails: confirmación, resuelta, rechazada

Tres emails. Cada uno tiene un trabajo.

Reclamación recibida (confirmación). Se envía en el momento que el formulario se envía. Trabajo: reducir ansiedad. Diles: la tenemos, este es el ID de la reclamación, esto es lo que pasa después, este es el plazo. Un párrafo. Sin lenguaje legal.

Reclamación resuelta (aprobada). Se envía cuando se emite la resolución. Trabajo: entregar la buena noticia limpiamente. Si es Reemplazo: número de seguimiento. Si es Saldo en tienda: el código, con una línea clara de "úsalo en lo que quieras de la tienda". Si es Reembolso: el importe y los plazos del banco ("3–5 días laborables para que aparezca en tu extracto").

Reclamación rechazada. Este es el email que la mayoría de marcas escribe mal y donde pierden clientes para siempre.

La versión equivocada:

Tu reclamación ha sido denegada según el apartado 4.2 de nuestra política de garantía. Esta decisión es firme.

La versión correcta:

Hola [nombre], hemos revisado tu reclamación y por desgracia queda fuera de lo que podemos cubrir bajo nuestra garantía — este es el motivo concreto: [motivo en una frase]. Sabemos que no es lo que esperabas escuchar. Si tienes más contexto o fotos distintas, contesta a este email y le echamos otro vistazo.

Esa segunda versión no te cuesta nada y salva la relación quizá un 30% de las veces. La línea de "contesta con más contexto" es crítica — convierte una puerta cerrada en una conversación, y las reclamaciones genuinamente válidas que se auto-rechazaron por una regla demasiado tight afloran aquí. Customiza los tres; las plantillas por defecto se leen todas igual y la voz de tu marca es el diferenciador más barato que tienes.

Paso 8 — Mide las métricas correctas

Si no puedes medir tu programa de garantías, no puedes mejorarlo. El dashboard mínimo:

• Reclamaciones totales (por mes, por trimestre, por año). La línea de tendencia importa más que el número absoluto.
• Tasa de resolución — % de reclamaciones aprobadas (vs rechazadas vs pendientes). Una tasa de resolución por encima del 90% significa que tu política está demasiado floja o tus reglas son demasiado generosas. Por debajo del 60% significa que algo va mal con la calibración de expectativas del cliente (la PDP, la página de política o el propio producto).
• Reclamaciones por país. Un pico en una geografía suele significar un problema logístico (daño en tránsito en una ruta concreta) o un cluster de fraude.
• Reclamaciones por tipo de resolución. Si estás reembolsando el 60% de reclamaciones, tus defaults de resolución están mal. Si estás reemplazando el 90%, probablemente te estés comiendo margen que no tienes que comerte.
• Top productos por tasa de reclamación. Esta es la métrica oro. Un SKU con una tasa de reclamación 3× tu media te está flaggeando un problema de QC semanas o meses antes de que tus reviews lo pillen. Pillalo aquí, arréglalo en el proveedor, evita la retirada.
• Impacto en COGS — coste-total-de-resolución, desglosado por tipo de resolución. Esto es lo que llevas a tu CFO cuando pides presupuesto de QC.

La mayoría de marcas en Shopify no tienen estos números porque su garantía vive en un inbox. Las marcas que sí los tienen, operan la garantía como un loop de feedback operativo hacia producto, sourcing y packaging — no como un afterthought de CS.

A dónde ir desde aquí

Un programa de garantías es una de las pocas inversiones de CX que se paga sola dos veces: es palanca de retención (las experiencias de garantía limpias recompran a tasas significativamente más altas) y señal de feedback (tus SKUs más reclamados son tu roadmap de QC, gratis).

La pieza de infraestructura es para lo que construimos Ecombone Warranty Claims: el motor de reglas ordenado por prioridad, los tres tipos de resolución (Reemplazo vía draft order de 0$, Reembolso a través de Shopify, Saldo en tienda como código de un solo uso), subida de fotos hasta 5MB en JPEG/PNG/WebP, notificaciones por email customizables, multi-divisa, roles de equipo y la analítica descrita arriba. Hay un free tier para tiendas con menos de 10 reclamaciones/mes para que puedas correr el playbook end-to-end antes de soltar un dólar.

Si tu garantía vive ahora mismo en un inbox y un spreadsheet, la estás pagando en horas de CS, reembolsos sobre-emitidos y problemas de QC que estás pillando demasiado tarde. Empieza por el Paso 1 hoy: decide, por escrito, qué ofreces realmente.