Cabizz · Operación · Mapa de procesos

Los cuatro procesos que el administrador gestiona

Disputas de entrega, contracargos, reseñas y verificación de edad. Qué es cada uno, en qué casos se dispara, por qué estados pasa y qué hace concretamente el administrador en cada punto.

27 de julio de 2026 Panel: admin-services Verificado contra código y migraciones

Lo primero: dónde viven estos procesos

Los cuatro se gestionan desde admin-services, el panel global de Cabizz —no desde los paneles de comercio—. Aunque en el menú aparecen agrupados bajo Restaurants, las cuatro pantallas son transversales: cada una trae un selector de vertical y cubre los tres verticales de consumo.

Proceso Fork Discount Cheers Go Bye Bye Junk Union Driver
Disputas de entrega aporta prueba
Contracargos suscripción
Reseñas y moderación es calificado
Verificación de edad no aplicano aplica es verificador

La verificación de edad no se activa por vertical sino por producto: se dispara cuando un ítem está marcado age_restricted. Hoy solo Cheers Go los tiene, pero nada impide que otro vertical marque uno y el flujo se active.

Cómo se encadenan

No son cuatro islas. Un mismo pedido puede recorrer tres de ellos, y la disputa interna es la que alimenta con evidencia al contracargo.

Repartidor Marca la entrega hecha El pedido queda esperando al cliente
Cliente · sí Confirma entrega Califica comercio y repartidor Pedido cerrado
Cliente · no Disputa la entrega Admin toma el caso y reúne evidencia Resuelve con un código
Si va al banco Contracargo en Stripe La disputa interna se adjunta como prueba
Edad Producto restringido Verificación en la entrega Constancia · o rechazo con reembolso

Los expedientes

01 · DISPUTA

Disputa de entrega

auth.order_delivery_disputes
Concepto

El cliente sostiene que la entrega no ocurrió como se acordó. Es un reclamo interno: se resuelve entre el cliente, el comercio, el repartidor y Cabizz, sin que intervenga ningún banco. Es la instancia que evita el contracargo.

Quién la dispara, y en qué momento exacto

La dispara el cliente, y solo puede hacerlo en un punto del ciclo del pedido: cuando el repartidor ya marcó la entrega como hecha y el pedido queda esperando la confirmación del cliente. Ahí, en Mis Pedidos, aparecen dos botones juntos:

Confirmar entrega Cierra el pedido y abre la calificación
o
Disputar entrega Pide un motivo escrito y abre el expediente

No es "quejarse más tarde": es la alternativa a confirmar. Son las dos salidas de la misma bifurcación. Si el cliente confirma, el pedido sale de ese estado y el botón de disputar desaparece.

Condiciones que habilitan el botón

El servidor decide si el botón se ve. Tienen que cumplirse las tres:

  1. El pedido está en estado 8, esperando confirmación del cliente. Antes no —todavía no hay nada que disputar—; después tampoco.
  2. Es un pedido con entrega a domicilio. Los retiros en el local no se disputan por esta vía: no hubo reparto que cuestionar.
  3. Ese pedido tiene menos de dos disputas. El tope es 2, para que la instancia no se use como canal de presión indefinido.
Casos que motivan la disputa
  • El pedido nunca llegó, pero figura como entregado
  • Llegó incompleto: faltan ítems del pedido
  • El producto llegó dañado, derramado o en mal estado
  • Se entregó a otra persona o en otra dirección
  • El repartidor marcó la entrega sin que ocurriera

El cliente elige el motivo escribiéndolo: el campo es obligatorio y no se puede enviar vacío. No hay lista de opciones — el texto libre es lo primero que lee el administrador cuando toma el caso.

Estados
1OPEN 2UNDER_REVIEW 3RESOLVED 4ESCALATED 5WITHDRAWN
Con qué se cierra
1REFUNDED_FULL 2REFUNDED_PARTIAL 3REDELIVERED 4REJECTED_EVIDENCE 5REJECTED_ABUSE 6NO_ACTION
Qué hace el administrador
  1. Toma el caso. Al reclamarlo queda asignado a su nombre y se marca la primera respuesta, que es lo que mide el acuerdo de servicio.
  2. Reúne la evidencia. Seis tipos, y tres se adjuntan solos: foto del cliente, foto del repartidor, traza GPS, export del chat, carga manual del admin y constancia de entrega.
  3. Resuelve con un código. No es texto libre: elige entre reembolso total, parcial, reenvío, rechazo por evidencia, rechazo por abuso o sin acción.
  4. Vigila el reloj. Las disputas vencidas se escalan automáticamente al estado 4 por un proceso programado.
Acuerdo de servicio: 24 h para la primera respuesta y 72 h para resolver. El panel muestra un distintivo por disputa y métricas agregadas. Vencido el plazo, el sistema escala solo — nadie tiene que acordarse.
Panel · admin-services → Disputes · detalle en DisputeDetail
Lo abre el cliente desde POST /myorders/{id}/dispute-delivery
Admin · /disputes/{id}/claim · /evidence · /resolve · /disputes/sla-metrics
02 · CONTRACARGO

Contracargo de tarjeta

payment.stripe_disputes
Concepto

El titular de la tarjeta desconoce el cobro ante su banco, no ante Cabizz. El banco retira el dinero de forma preventiva y abre un plazo para presentar descargo. Es el único de los cuatro procesos donde el reloj lo pone un tercero y vencerlo significa perder la plata automáticamente.

Casos en los que ocurre
  • El titular denuncia un cargo fraudulento: no reconoce la compra
  • Sostiene que el producto nunca llegó — típicamente después de una disputa interna que no lo dejó conforme
  • Reclama que lo recibido no era lo descrito
  • Un cobro duplicado
  • Una suscripción que dice haber cancelado y se le siguió cobrando
Estados

No son códigos de Cabizz: se guardan los literales que envía Stripe, para que el panel nunca contradiga lo que dice la pasarela.

needs_response warning_needs_response under_review won lost
Qué hace el administrador
  1. Mira el vencimiento primero. Cada contracargo trae fecha límite. Es el único criterio de prioridad que importa: el resto se ordena solo.
  2. Revisa la evidencia armada. El sistema previsualiza el descargo antes de enviarlo. Si el pedido ya tuvo una disputa interna, esa queda vinculada y su evidencia —GPS, chat, constancia de entrega— entra al descargo.
  3. Envía el descargo a Stripe antes del vencimiento. Se registra la fecha de envío.
  4. Espera el fallo del banco. Nadie más interviene: el resultado llega como won o lost.
Regla firme: al cliente no se le notifica nunca. Está decidido y documentado. Contactarlo durante un contracargo puede interpretarse como presión sobre el titular y agrava el caso ante el banco. Toda la gestión es entre Cabizz y Stripe.
Panel · admin-services → Chargebacks · detalle en ChargebackDetail
Entra solo por webhook de Stripe, con ingesta idempotente
Admin · /disputes/stripe · /{id}/evidence-preview · /{id}/submit-evidence · /open-count
03 · RESEÑAS

Reseñas y moderación

auth.order_ratings · order_rating_replies · order_rating_reports
Concepto

Tras confirmar la entrega, el cliente califica dos cosas por separado: el comercio y el repartidor. La moderación no existe para maquillar promedios, sino para separar la crítica legítima —que debe verse y contar— del contenido inadmisible o el fraude.

Casos en los que se modera
  • La reseña incluye datos de contacto o información personal
  • Contiene lenguaje ofensivo o discriminatorio
  • Un tercero la reporta y entra a la cola de revisión
  • Se detecta un patrón de fraude: reseñas coordinadas para hundir o inflar a un negocio
  • El comercio quiere responder públicamente — una sola vez por reseña
Estados
1visible 2oculta 3reportada 4descartada
Qué hace el administrador
  1. Atiende la cola de reportes. Cada reseña reportada llega con el motivo de quien la reportó.
  2. Decide entre ocultar y descartar. Son cosas distintas y la diferencia es la clave de todo este proceso — ver la regla de abajo.
  3. Filtra por objetivo. Puede ver solo las del comercio o solo las del repartidor, y por vertical.
  4. Deja que el comercio responda. Una respuesta por reseña, sin edición posterior.
Ocultar no es lo mismo que borrar del promedio. Si una reseña se oculta por su contenido —un insulto, un teléfono— la estrella sigue contando: el cliente tuvo una mala experiencia real y el negocio debe cargar con ella. Solo el fraude confirmado saca la calificación del promedio. Es la diferencia entre moderar y falsear.
Ventanas de tiempo: el cliente tiene 14 días para calificar y 24 horas para editar lo que escribió. Después queda firme.
Panel global · admin-services → Reviews (con columna de objetivo y filtro por vertical)
Panel del comercio · BusinessReviews — solo las suyas, y puede responder
El repartidor ve la propia en union-driver → Mi cuenta → Perfil
Admin · /admin/reviews · /{id}/status · /{id}/reports
04 · EDAD

Verificación de edad

auth.age_verification
Concepto

Cuando el pedido incluye un producto restringido, alguien tiene que comprobar la edad del comprador en el momento de la entrega, no al momento de comprar. Lo que se guarda es una constancia de que la verificación ocurrió — quién verificó, con qué documento y con qué resultado. La foto del documento no se guarda ni se sube.

Casos en los que ocurre
  • El pedido contiene al menos un ítem marcado age_restricted
  • El umbral lo fija el país, no la app: 18 o 21 años según jurisdicción, y queda congelado en la constancia
  • Entrega a domicilio — verifica el repartidor
  • Retiro en el local — verifica el personal del comercio
Cómo puede terminar
passverificado failunderage failno_document failrefused failillegible failname_mismatch

Un fail lleva el pedido al estado de rechazo por edad, que dispara la devolución de la parte restringida. El resto del pedido puede entregarse.

Qué hace el administrador
  1. Consulta las constancias. Es el registro que respalda a Cabizz ante un control: quién verificó, cuándo, con qué documento y qué umbral aplicó.
  2. Revisa anomalías. El panel tiene una vista aparte para patrones sospechosos — un mismo verificador aprobando todo, rechazos en cadena, documentos repetidos.
  3. Exporta el registro cuando lo pide una auditoría o un requerimiento regulatorio.
  4. Valida la cobertura. Que los productos que deben estar marcados lo estén: el flujo solo se dispara si el ítem tiene la marca.
La constancia es la defensa legal, no la foto. Se registra el tipo de documento, la fecha de nacimiento vista, la edad derivada en el servidor y el umbral del país en ese momento. Guardar la imagen del documento sería un pasivo de datos personales sin ningún beneficio probatorio adicional.
Panel · admin-services → Age verifications · /anomalies · /export
Verifican · union-driver (entrega) y panel del comercio (retiro en mostrador)
API · /orders/{id}/age-verification · /age-verification/reject · /admin/age-verifications

Lo que conviene tener claro

La disputa interna es la que protege el margen. Un cliente insatisfecho que encuentra respuesta en la app no va al banco. Cada disputa bien resuelta es un contracargo que no ocurre — y el contracargo, además de la plata, cuesta comisión y reputación con la pasarela.

Los cuatro procesos tienen reloj, pero solo uno es inapelable. Las disputas se escalan solas, las reseñas tienen ventanas de edición, la verificación de edad ocurre en el instante de la entrega. El contracargo es el único donde el plazo lo fija un tercero y vencerlo significa perder sin discusión.

Tres de los cuatro dependen de que alguien mire el panel. Solo el contracargo entra por sí solo, vía webhook. Las disputas, los reportes de reseñas y las anomalías de edad esperan a que un administrador entre a buscarlas.

Recomendaciones

Nada de esto está implementado. Son oportunidades que aparecieron al mapear los cuatro procesos contra el código, ordenadas por proceso. Ninguna es un defecto: el sistema funciona sin ellas.

Disputas Esfuerzo S

Tipificar el motivo, sin quitar el texto libre

Hoy el cliente escribe el motivo en un campo obligatorio de texto libre. Eso es bueno para el administrador que toma el caso —lee el problema con las palabras del cliente— pero impide medir: no se puede responder "cuántas disputas fueron por producto faltante" ni detectar si un comercio concentra un tipo de falla.

La solución ya tiene precedente adentro del propio sistema: las reseñas piden motivos tipificados cuando la calificación es baja, y conviven con el comentario libre. Replicar ese patrón en disputas —una categoría obligatoria más el texto— da estadística sin perder contexto.

Disputas Esfuerzo S

Decirle al cliente que llegó a su límite

Un pedido admite como máximo dos disputas. Al llegar al tope, el servidor simplemente deja de habilitar el botón. Desde el lado del cliente eso se ve como un botón que desapareció sin explicación — y esa ambigüedad es la que empuja a la gente al banco, que es exactamente el desenlace que este proceso existe para evitar.

Contracargos Esfuerzo S

Avisar antes del vencimiento, no esperar a que alguien mire

Es el único de los cuatro procesos donde el plazo lo fija un tercero y vencerlo significa perder sin discusión. Hoy entra solo por webhook y después se queda quieto hasta que un administrador abra la pantalla.

Las disputas ya tienen un proceso programado que las escala al vencerse. La misma mecánica aplicada a los contracargos —un aviso a 72 y a 24 horas del due_by— convierte el riesgo más caro del sistema en algo que se agenda solo.

Contracargos Esfuerzo M

Medir cuántos contracargos evitó la disputa interna

El vínculo entre un contracargo y su disputa previa ya se guarda. Falta darlo vuelta y usarlo como métrica: qué proporción de disputas resueltas no terminó en contracargo.

Es el número que justifica todo el esfuerzo de atender disputas rápido, y hoy no existe en ningún tablero. Sin él, la instancia interna parece un costo; con él, se ve como lo que es.

Reseñas Esfuerzo S

Mostrar la calificación en la ficha del repartidor

El promedio del repartidor se calcula, se guarda y el propio conductor lo ve en su app. Pero la ficha del rider en el panel no lo muestra: para saber cómo califican a alguien hay que ir a Reseñas y filtrar a mano por objetivo.

Es el único vacío real que quedó del análisis de paridad, y el dato ya está listo — solo falta traerlo a la pantalla donde se lo busca.

Reseñas Decisión

Dejar por escrito cuándo es fraude

La distinción entre ocultar y descartar del promedio es la regla más delicada del proceso, y hoy depende del criterio de quien modera. Sacar una calificación del promedio de un negocio es una decisión con consecuencia económica.

Conviene fijar por escrito qué configura fraude —reseñas coordinadas, cuentas creadas para eso, competencia— y qué no, por más molesta que sea la crítica.

Edad Esfuerzo S

Auditar qué productos deberían estar marcados y no lo están

Todo el proceso depende de una marca por producto. Si un ítem restringido no está marcado, el flujo nunca se dispara: el pedido sale, se entrega y no queda constancia de nada. Y no hay error, ni alerta, ni rastro — el sistema hace exactamente lo que se le pidió.

Es el único riesgo regulatorio silencioso de los cuatro procesos. Un chequeo periódico sobre el catálogo de Cheers Go —por categoría, por palabra clave— lo cierra.

Edad Esfuerzo M

Dar al comercio acceso a sus propias constancias

La reportería vive solo en el panel global. Si a un local le llega una inspección, hoy depende de que alguien de Cabizz le exporte el registro.

El comercio es quien enfrenta al inspector: debería poder mostrar sus constancias sin intermediarios.

Transversal Esfuerzo S

Sacar las cuatro pantallas del módulo Restaurants

Las cuatro son transversales y traen selector de vertical, pero cuelgan del grupo Restaurants por un efecto secundario de cómo se dieron de alta. Eso hace creer que son exclusivas de ese vertical y que a Cheers Go y Bye Bye Junk les falta algo — cuando ya las tienen.

Moverlas a un módulo propio —Operaciones o Transversal— es un cambio de dato, no de código: solo reasignar el módulo de esas páginas.

Transversal Esfuerzo M

Tres de los cuatro esperan a que alguien mire

Solo el contracargo entra por sí solo. Las disputas nuevas, los reportes de reseñas y las anomalías de edad se quedan esperando a que un administrador abra la pantalla correcta. Si nadie entra un fin de semana largo, un acuerdo de servicio de 24 horas se vence sin que nadie lo haya visto.

El escalado automático de disputas ya demuestra que la infraestructura de procesos programados está y funciona. Extenderla a un aviso por bandeja —qué hay pendiente y hace cuánto— cierra el punto ciego de los tres.

Documento de operación · verificado contra el código de app-api-v2, las migraciones y las pantallas de admin-services al 27 de julio de 2026. Los códigos de estado, los motivos de cierre y los tipos de evidencia son los valores reales que persiste la base, no una descripción aproximada.