El mercado local de la plaza reunía a dieciocho puestos, una caja común para gastos y un pequeño servicio de pedidos anticipados. Cada martes, una aplicación preparaba los cobros: sumaba las ventas anotadas por los puestos, descontaba la cuota de limpieza y enviaba recordatorios si faltaba un pago. Durante el verano, dos comerciantes advirtieron un problema. La aplicación había cobrado dos veces a una clienta que cambió su cesta por teléfono y había marcado como retrasado el pago de una frutería cuyo banco había estado cerrado por una incidencia técnica. La propuesta inmediata fue añadir más automatización: bloquear cuentas, recalcular penalizaciones y cruzar todos los movimientos con el historial de compras. Antes de hacerlo, el mercado decidió revisar qué estaba autorizada a decidir la herramienta.
La pregunta no era si los cobros debían hacerse a mano o con software. Era qué controles podían reducir errores sin transformar una relación comercial cercana en una máquina de sospechas. Una automatización de cobros trabaja con datos sensibles: importes, productos, frecuencia de compra, devoluciones y, a veces, incidencias que explican una excepción. Si todo ello se usa para clasificar a clientes o vendedores, el sistema puede castigar circunstancias que no son un incumplimiento. La revisión debía proteger el dinero compartido y, al mismo tiempo, dejar claro que una alerta no era una sentencia sobre una persona.
Empezar por el recorrido de un cobro#
La comisión dibujó el recorrido completo de un pedido. Una clienta elegía productos, el puesto confirmaba disponibilidad, la caja registraba el importe, el sistema iniciaba el cargo y alguien conciliaba el extracto. En cada paso preguntaron qué fallo era plausible y quién podía comprobarlo. Un importe mal transcrito podía detectarse comparando el pedido y el recibo. Un cargo duplicado podía verse por fecha, referencia y cantidad. Pero una sustitución de producto, una recogida aplazada o una transferencia bancaria lenta requerían información que la aplicación no poseía.
La comisión dibujó el recorrido completo de un pedido. Una clienta elegía productos, el puesto confirmaba disponibilidad, la caja registraba el importe, el sistema iniciaba el cargo y alguien conciliaba el extracto.
Ese mapa corrigió una confusión habitual: no todos los eventos con el mismo resultado son iguales. Un saldo pendiente puede significar que una tarjeta fue rechazada, que se aprobó un pago fraccionado o que la persona acordó pagar al recoger una cesta solidaria. Tratar los tres casos como morosidad puede resultar eficiente en una pantalla y profundamente injusto en el mercado. Por eso cada regla debía indicar el hecho que detectaba, la explicación que no podía inferir y el paso humano previsto antes de enviar una consecuencia.
Reglas para documentos y transacciones, no para reputaciones#
La primera revisión mantuvo reglas automáticas muy concretas. La aplicación podía señalar dos cargos con la misma referencia y el mismo importe dentro de un periodo corto. Podía comparar el total cobrado con el pedido confirmado, avisar si una devolución superaba lo autorizado y detectar una cuota aplicada dos veces. Estos avisos eran útiles porque se referían a una transacción identificable. La pantalla mostraba los dos registros que justificaban la alerta y permitía corregir el dato sin abrir un expediente personal.
Lo que el sistema no haría era construir una puntuación de fiabilidad. No ordenaría a las personas por número de cambios de pedido, no convertiría una consulta a atención en un “riesgo” y no importaría conversaciones de mensajería para explicar retrasos. La diferencia es decisiva. Las reglas documentales ayudan a reparar una discrepancia; los perfiles intentan predecir el valor o la intención de alguien a partir de rastros que suelen tener contextos incompletos.
La responsable de caja añadió una regla de lenguaje: la aplicación debía decir “revisar posible duplicado” y no “cobro fraudulento”. Las palabras condicionan la respuesta humana. Si un aviso se presenta como acusación, quien lo recibe buscará pruebas de culpa. Si se presenta como comparación pendiente, buscará primero una causa y una corrección. La interfaz también mostraba quién podía resolver cada incidencia y en qué plazo, para que nadie quedara atrapado entre un mensaje automático y una caja que no sabe quién debe intervenir.
Una cola de excepción con personas responsables#
Las alertas que no se resolvían con un dato exacto entraban en una cola de excepción. Dos personas rotaban cada semana: una representaba a los puestos y otra a la caja común. Veían solo lo necesario para decidir. Si una clienta había pedido cambiar calabacines por tomates, podían consultar el pedido y la anotación de sustitución, no su historial entero de compras. Si un puesto había solicitado una demora, verificaban el acuerdo y la fecha prevista, no todos sus movimientos bancarios.
La cola tenía tres salidas sencillas: corregir el cargo, pedir una aclaración proporcionada o confirmar que no hacía falta actuar. No incluía una opción de sancionar automáticamente. Cualquier bloqueo temporal exigía una segunda revisión y un motivo comunicable. Esta decisión redujo la tentación de usar la automatización como atajo para conversaciones incómodas. También dejó una trazabilidad útil: no “Lucía fue problemática”, sino “el cobro 482 se corrigió porque la cesta original fue sustituida y el total cambió”. El registro describe una decisión comprobable, no una etiqueta que persigue a alguien.
Para evitar que las mismas personas controlaran siempre casos de sus vecinos o competidores, la rotación excluía conflictos directos. Cuando un caso era delicado, se asignaba a una tercera persona elegida por sorteo entre quienes habían recibido formación básica. Esa formación no consistía en prometer neutralidad abstracta. Enseñaba a distinguir dato, interpretación y decisión; a pedir solo información necesaria; y a reconocer cuándo una regla estaba produciendo demasiados falsos positivos.
Probar antes de castigar#
Antes de activar cualquier cambio, el mercado lo probaba cuatro semanas en modo observación. La regla podía generar avisos, pero no mandar recordatorios más duros ni alterar el saldo visible para clientes. Al final del periodo, la comisión examinaba cuántos avisos eran verdaderos errores, cuántos se resolvían con una corrección simple y cuántos reflejaban una situación legítima que la regla no entendía. Ese ensayo convirtió la configuración en una hipótesis verificable.
Una prueba fue especialmente reveladora. La propuesta de señalar pagos “inusualmente tardíos” detectó casi todos los cobros de un grupo de mayores que pagaba los jueves en caja, conforme a un acuerdo explícito. La regla no había descubierto un riesgo: había descubierto que su definición de normalidad ignoraba una práctica accesible del propio mercado. Se retiró. En cambio, una regla sobre referencias repetidas encontró cuatro duplicados reales causados por una integración que reintentaba el cargo al perder conexión. La reparación fue técnica y no requirió pedir explicaciones a las clientas afectadas.
Los resultados se compartieron en una reunión breve y en un tablón digital. Publicar el número de falsas alertas importaba tanto como publicar los errores hallados. Ayudaba a que el sistema no adquiriera una autoridad exagerada por el mero hecho de producir números. Si una regla molesta a muchas personas para resolver pocos casos, quizá debe cambiarse, aunque sea barata de mantener.
Datos mínimos, plazos claros y una salida comprensible#
El acuerdo final especificó datos y plazos. Para conciliar un cobro se conservaban pedido, importe, referencia, fecha, estado y motivo de corrección. Los detalles de una conversación solo se guardaban si eran imprescindibles para resolver ese caso y se eliminaban al cerrarlo, salvo obligación contable. Las alertas resueltas no alimentaban análisis de conducta futura. Cada persona podía ver el motivo de una incidencia, aportar una corrección y pedir que una revisión humana comprobara la decisión.
También se acordó qué ocurría cuando la automatización fallaba. Debía existir un canal de pago alternativo y una persona de contacto que pudiera congelar una acción mientras se revisaba. Una buena salida no es un formulario interminable ni una respuesta que llega después de que el puesto haya perdido una venta. Es la posibilidad real de detener un cobro erróneo, entender qué dato lo produjo y recuperar la posición sin tener que demostrar que una máquina fue injusta.
El mercado no renunció a automatizar. Renunció a imaginar que automatizar equivalía a delegar el juicio. Conservó reglas estrechas para detectar duplicados y descuadres, una cola humana para contextos y pruebas temporales para nuevas ideas. La próxima vez que alguien proponga añadir una regla, deberá traer un ejemplo del error que quiere prevenir, los datos mínimos que usará, la tasa de falsos positivos que aceptará y la reparación disponible. Ese pequeño expediente es un mejor control que cualquier perfil de confianza: obliga a que cada automatización explique por qué merece existir.
