Caso de estudio · TimbraBot · Conciliación bancaria-fiscal
Cerrar el mes es un problema de datos. Construimos el sistema que lo resuelve.
TimbraBot concilia movimientos bancarios contra el expediente fiscal. Lee el estado de cuenta de cualquier banco, propone cada vínculo con la evidencia que lo sostiene y dictamina la deducibilidad factura por factura. Una persona aprueba. Nadie teclea.
Respuesta en menos de 24 horas hábiles · Sin compromiso
El problema
El cierre de un despacho contable descansa en una comparación que nadie quiere hacer a mano: cada movimiento de cada cuenta bancaria, contra cada factura que la empresa emitió o recibió. Para un solo cliente con varias cuentas son cientos de renglones al mes. Para un despacho con quince clientes son miles, y todos caen en las mismas dos semanas.
El trabajo es mecánico pero no es simple. Una salida de dinero puede corresponder a una factura, al pago parcial de una factura emitida meses atrás, a la dispersión de nómina de cuarenta empleados, o a un traspaso entre dos cuentas del propio cliente, que no corresponde a ninguna factura. Quien lo hace lee una descripción bancaria redactada para un cajero, no para un contador, y tiene que decidir a cuál de cuatro mil facturas pertenece.
Lo caro no son las horas. Es que esas horas las gasta la gente con más experiencia del despacho, en la única ventana del mes en la que no las puede gastar en otra cosa. El cierre es un cuello de botella por construcción: no puede empezar hasta que llegan los estados de cuenta y no puede pasarse de la fecha de presentación. Cada cliente que el despacho suma ensancha el mismo embudo.
Y el error no es cosmético. Un movimiento vinculado a la factura equivocada produce una posición fiscal equivocada, en una declaración que va firmada. Un pago aplicado a una factura que después se canceló produce una deducción que no aguanta una revisión. Equivocarse no cuesta retrabajo: cuesta exposición.
Por qué era difícil
La primera barrera es el documento. Un estado de cuenta en México es un PDF diseñado para que lo lea una persona que lo tiene en la mano, y cada institución diseña el suyo. Las columnas se mueven. El cargo y el abono a veces son dos columnas, a veces una sola con signo, a veces una letra al final del renglón. Los encabezados se repiten a media página. Una transacción se parte en tres líneas. Hay instituciones que exportan un formato más cercano a una impresión de mainframe que a una tabla. No hay API, no hay esquema y no hay estándar: hay el archivo que el cliente descargó.
La segunda barrera es que el expediente fiscal no es una lista plana de facturas. Una factura pagada en una sola exhibición se salda contra un movimiento. Una factura a crédito se salda contra complementos de pago —documentos fiscales aparte, cada uno cubriendo una parte del saldo, a veces varios aplicados a la misma factura en fechas distintas, a veces uno cubriendo varias facturas a la vez—. La nómina se timbra por empleado y se paga en una sola dispersión. El dinero que se mueve entre cuentas del mismo cliente se ve idéntico a un pago a proveedor. Y una factura se puede cancelar ante el SAT después de haber sido conciliada, con una sustituta emitida en su lugar.
La tercera barrera es que la respuesta es un juicio, no una búsqueda. Los montos casi nunca cuadran al centavo, las fechas casi nunca coinciden, y el nombre de la contraparte en una descripción bancaria es la abreviatura que alguien tecleó en un formulario de transferencia. Dos proveedores distintos pueden producir la misma cifra el mismo día. Un sistema que empata por monto se equivoca con confianza y a escala, que es peor que ir lento.
Por eso un ERP no lo resuelve. Un ERP consume datos estructurados y da por hecho que la parte difícil ya se hizo. La parte difícil está antes: convertir un documento que nunca se pensó para ser leído por una máquina en un registro confiable, y después razonar sobre dos universos documentales que instituciones distintas diseñaron con propósitos distintos y que nunca se pensaron para cruzarse. Las herramientas genéricas de conciliación resuelven el último tramo del problema y te devuelven el primero.
El programa TimbraBot
TimbraBot es un programa de automatización en tres fases. Cada una se para sobre la anterior.
Fase 1 — Lectura
Qué resuelve: el dato de origen no existe en forma usable hasta que alguien lo produce.
El sistema recibe los estados de cuenta tal como vienen, en el acomodo que cada institución haya decidido usar, y extrae cada movimiento a un registro normalizado: fecha, descripción, monto, dirección, saldo. Los montos se manejan en centavos, nunca en punto flotante. Después la extracción se contrasta contra la propia aritmética del estado —saldo inicial, movimientos, saldo final— y cualquier estado cuyos saldos no cuadren se marca como no verificado en lugar de darse por bueno. Los movimientos no verificados quedan fuera de toda métrica, así que una lectura mala degrada la cobertura en vez de contaminar el resultado en silencio.
Del lado fiscal, el sistema toma el expediente de la empresa —facturas emitidas y recibidas, complementos de pago, recibos de nómina— y lo normaliza con la misma disciplina, con las claves necesarias para que el mismo documento fiscal pueda existir legítimamente como emitido de una empresa y recibido de otra.
Los documentos de origen se conservan, así que cualquier estado se puede volver a leer sin pedirle el archivo al cliente otra vez. La relectura está direccionada por contenido: si ni el documento ni la lógica de extracción cambiaron, el sistema no gasta una segunda lectura.
Qué cambia para el usuario: sube un archivo y recibe un registro. Nunca transcribe, y se le dice con claridad cuándo un documento no salió limpio.
Fase 2 — Conciliación masiva
Qué resuelve: cruzar miles de movimientos contra miles de facturas, bien, en el tiempo que hay.
El sistema pasa cada movimiento por un motor ordenado. Primero aparta lo que no corresponde a ninguna factura: comisiones bancarias, impuestos y traspasos espejo entre cuentas del propio cliente, que identifica encontrando el cargo y el abono correspondientes en dos cuentas de la misma empresa. Luego resuelve los complementos de pago, agrupando cada nodo de pago contra las facturas que salda y verificando que la dirección sea la correcta: un pago que la empresa recibió tiene que caer como abono, y uno que hizo, como cargo. Luego la nómina, primero como dispersión agregada contra la suma de los recibos del periodo, después empleado por empleado. Luego las facturas de una sola exhibición: por monto, por directorio de contrapartes, por RFC extraído de la descripción bancaria y por similitud de nombre cuando la descripción trae una abreviatura en lugar de un nombre.
Lo que el motor determinístico no puede resolver pasa a una capa de razonamiento, que ve únicamente los movimientos que quedaron y las facturas que siguen abiertas, y propone vínculos con una confianza declarada. Cada propuesta se vuelve a revisar del lado del servidor con código que tiene autoridad para rechazarla: la factura tiene que ser una de las que se ofrecieron, la dirección tiene que ser la correcta, el monto tiene que caer dentro de la tolerancia de ese tipo de vínculo, la fecha tiene que estar en rango, una aplicación parcial tiene que traer el importe aplicado, y la contraparte del lado bancario no puede contradecir a la de la factura. La misma factura no se puede consumir dos veces.
Una propuesta solo se acepta sin revisión humana cuando la confianza es alta y hay evidencia dura en la descripción: el RFC o la razón social de la contraparte. Todo lo demás se le presenta al contador como propuesta con su evidencia: qué facturas, qué folios fiscales, cómo se desglosa el monto y por qué el sistema lo cree.
Cada decisión del contador retroalimenta. Una aprobación le enseña al sistema que cierta descripción pertenece a cierta contraparte, y esa memoria se aplica en la siguiente corrida. Un rechazo le enseña lo contrario. Las correcciones y las cancelaciones se deshacen limpio en vez de marcarse como rechazo, para que el sistema no aprenda un negativo a partir de un movimiento contable.
Qué cambia para el usuario: deja de buscar y empieza a decidir. La bandeja viene ordenada por confianza, las decisiones se pueden tomar en lote, y lo que queda es el trabajo que sí requería a una persona.
Fase 3 — Inteligencia fiscal
Qué resuelve: un mes conciliado no es lo mismo que un mes defendible.
Sobre el resultado conciliado, el sistema dictamina cada factura de gasto: deducible, en riesgo o no deducible, y le adjunta la razón. Las reglas son las que deciden el resultado en la práctica. Un gasto por arriba del umbral de efectivo tuvo que pagarse por medio electrónico. Una factura cancelada no sostiene una deducción. Una factura a crédito solo está saldada cuando la evidencia lo dice, y el sistema gradúa esa evidencia: un complemento de pago que cierra el saldo, un complemento que cubre solo una parte, un pago que el banco confirma sin complemento emitido, un pago todavía por confirmar, o nada. El RFC receptor tiene que ser el de la empresa. La forma de pago declarada tiene que sobrevivir el contraste con lo que el banco realmente muestra.
Los pagos hechos fuera de la cuenta bancaria se tratan de forma explícita. Una factura liquidada en efectivo, con tarjeta o vía reembolso se puede marcar como tal con su nota, y esa evidencia entra a la misma escalera: visiblemente más débil que un pago confirmado por el banco, y nunca presentada como equivalente.
Las facturas canceladas ante el SAT después del hecho se sacan a la superficie con la sustituta propuesta a partir de dato duro —el folio de sustitución que trae la propia autoridad—, para que el vínculo se pueda mover a la sustituta, desligar o mantener, como decisión y no como hallazgo.
Cuando no se puede llegar a un veredicto porque falta un insumo, el sistema lo dice. Nunca fabrica un veredicto a partir de una ausencia.
Qué cambia para el usuario: el despacho deja de encontrar los problemas en la declaración y empieza a encontrarlos en el mes. Cada veredicto trae su razón, así que se puede defender o corregir antes de que importe.
Datos ilustrativos. Ninguna captura muestra información real de contribuyentes.
Dónde la IA es insustituible
Casi todo este sistema es código determinístico, a propósito. Hay dos problemas adentro que no se pueden resolver así, y son los dos donde un modelo hace un trabajo que ninguna regla haría.
Leer un documento que no tiene formato
No existe un estándar para el estado de cuenta bancario en México. Cada institución arma el suyo, lo cambia sin avisar y no le debe un esquema a nadie. La extracción por plantilla funciona hasta que el banco mueve una columna, y entonces falla en silencio, que en este dominio es la peor falla posible: una transacción que no se extrajo no se anuncia sola.
El sistema lee el estado como lo leería una persona: mira la página y deduce dónde están los movimientos, cuál columna es el cargo y cuál el abono, cómo codifica la dirección esa institución y dónde termina de verdad una transacción que se partió en varios renglones. Resuelve acomodos que ni siquiera son tablas. No está afinado banco por banco: está escrito para razonar sobre lo que hay en la página, que es lo que hace que una institución nueva sea un no-evento y no un proyecto.
Esa capacidad solo es segura por lo que la rodea. La extracción se verifica contra la aritmética del propio estado, en centavos, y la deduplicación sabe cuáles campos son de verdad únicos en ese acomodo: un número de referencia que identifica a una terminal de cobro y no a una transacción no puede usarse para colapsar dos ventas reales. Si los números no cierran, el estado se marca como no verificado y sus movimientos quedan fuera de toda métrica. El modelo hace la lectura. La aritmética decide si esa lectura es confiable.
El compilador de reglas
Esta es la pieza que cambia lo que el sistema es.
Todo despacho carga conocimiento que vive en la cabeza de una persona: las transferencias a ese nombre son renta, no un proveedor · lo que sale de esa cuenta es pago de un crédito y nunca lleva factura · cuando la descripción dice PROV y un número, es ese proveedor. Ese conocimiento es la diferencia entre un sistema que concilia medio mes y uno que concilia casi todo. En cada producto que ha intentado capturarlo, termina en un constructor de reglas con menús y operadores booleanos — y el contador, que es quien tiene el conocimiento, no lo usa, porque la interfaz la diseñó alguien que piensa en condiciones.
En TimbraBot el contador escribe la regla en español, en una caja de texto, como se la explicaría a un becario. El sistema la compila. Lo que sale no es un prompt ni una sugerencia: es un descriptor ejecutable que el motor determinístico aplica en cada corrida, antes de que intervenga ninguna capa de razonamiento. Lo que compila limpio se vuelve lógica determinística. Lo que es genuinamente ambiguo se lleva a la capa de razonamiento como contexto, en vez de descartarse. Las reglas nunca se borran cuando se apagan: se neutralizan, para que la historia de lo que el despacho decidió quede intacta.
El resultado es que la experiencia del despacho entra al motor sin un programador de por medio, y el sistema que termina el año es mejor que el que lo empezó — no porque el modelo haya mejorado, sino porque el despacho le enseñó.
Datos ilustrativos. Ninguna captura muestra información real de contribuyentes.
Arquitectura
El sistema está construido como cuatro etapas independientes con una base de datos como contrato entre ellas. Nada llama a un modelo sin una capa determinística delante y una capa de validación detrás.
Ingesta
Los documentos de origen aterrizan en almacenamiento privado y los procesa un servicio de extracción que entrega movimientos normalizados —no archivos— a todo lo que viene después. El motor nunca ve un PDF. Esa es la costura que vuelve irrelevante el origen del documento: un estado que sube un usuario, un expediente fiscal tomado de la autoridad y un archivo que llega por cualquier otra vía entran por un adaptador y salen como el mismo registro normalizado. La extracción está direccionada por contenido, así que reprocesar un documento que no cambió no cuesta nada. Las extracciones largas se aceptan de forma asíncrona y se reportan por sondeo, de modo que ni el navegador ni el proxy quedan en la ruta crítica.
Motor de conciliación
Una secuencia ordenada de pasos determinísticos: clasificación, traspasos espejo, complementos de pago agrupados por nodo de pago, nómina agregada, nómina individual, y facturas de una sola exhibición resueltas por monto, directorio de contrapartes, extracción de RFC y similitud de nombre. Cada paso consume lo que dejó el anterior. Las reglas compiladas del despacho se aplican aquí, como descriptores determinísticos, no como pistas.
Capa de razonamiento
Solo le llega el residuo, en bloques acotados, con el universo de candidatos recortado a lo que sigue abierto. Devuelve propuestas con confianza y una justificación declarada.
Capa de validación
Código del lado del servidor con derecho de veto sobre cada propuesta: identidad, dirección, tolerancia de monto según el tipo de vínculo, ventana de fechas, importe aplicado en las parciales, congruencia de contraparte y consumo único de cada factura dentro del bloque y entre bloques. La aprobación automática exige confianza alta y evidencia dura en la descripción. Todo lo demás se convierte en una propuesta para una persona. La explicación que ve el usuario se genera desde los datos validados —folios y desglose de monto—, no desde la prosa del modelo.
Memoria y reglas
Las aprobaciones y los rechazos los captura la propia base de datos por disparadores, hacia un almacén de descriptores que se consulta en la siguiente corrida. Las reglas escritas en español se compilan a ese mismo formato de descriptor, y por eso el conocimiento del despacho y el conocimiento aprendido los aplica la misma maquinaria.
Capa fiscal
Un motor de reglas determinístico evalúa la deducibilidad sobre el resultado conciliado y materializa el veredicto con sus razones y un hash de los insumos que lo produjeron. Cuando cambia cualquier insumo —un vínculo aprobado, una cancelación atendida, un pago registrado— el veredicto se recalcula. Un cambio en las reglas invalida el caché completo por construcción, así que un veredicto viejo no puede sobrevivir a un cambio en las reglas que lo produjeron.
Producción
Aplicación web en hosting administrado, Postgres con seguridad a nivel de renglón y acceso por invitación, almacenamiento privado de objetos para los documentos de origen, y una capa de orquestación autoalojada para los cuatro pipelines de backend. Los webhooks se autentican con tokens firmados por sesión; no hay ruta sin autenticar hacia los pipelines. La concurrencia se controla desde la base de datos para que la misma empresa no se procese dos veces a la vez, y una corrida que muere se barre en lugar de bloquear a la empresa para siempre.
Cómo opera hoy
TimbraBot opera en producción en BW Asesores, despacho contable de la Ciudad de México, donde un equipo de siete personas lo usa sobre quince empresas-cliente.
El ritmo de trabajo sigue al cierre. Los estados de cuenta entran conforme los bancos los publican y se suben conforme llegan; el expediente fiscal se carga por empresa. Cuando el mes de una empresa está completo, un usuario dispara la conciliación desde el tablero y el sistema recorre el periodo entero de una sola vez.
Lo que recibe de vuelta no es un reporte. Es una bandeja, ordenada por confianza, de propuestas por decidir: cada una con el movimiento, las facturas que saldaría, los folios fiscales y el desglose del monto. Las propuestas de confianza alta con evidencia dura ya vienen aplicadas. El resto se aprueba, se corrige o se rechaza, en lote cuando son obvias y de una en una cuando no. Una vista mensual organiza el mismo trabajo por periodo, con los veredictos de deducibilidad de ese mes al lado.
Las aprobaciones siempre las hace el personal del despacho. Es una regla del despliegue, no una limitación del sistema: cada aprobación enseña a la memoria, así que una aprobación hecha por alguien más le estaría enseñando al motor algo que el despacho no decidió.
Datos ilustrativos. Ninguna captura muestra información real de contribuyentes.
Resultado
- Empresas-cliente administradas en la plataforma
- 15
- Movimientos bancarios procesados
- 5,282
- Estados de cuenta leídos
- 199, de 54 cuentas en 10 instituciones financieras
- Documentos fiscales en alcance
- 7,436 facturas, 2,567 complementos de pago, 448 recibos de nómina
- Movimientos con la aritmética del estado verificada
- 4,479
- Facturas con veredicto de deducibilidad y su razón
- 3,611
- Vínculos banco-factura aprobados
- 1,817
- Vínculos tecleados a mano
- 0
Cómo se produjeron esos 1,817 vínculos — y por qué eso importa más que el total
1,702 los propuso el motor determinístico. 115 los propuso la capa de razonamiento. Cero se capturaron a mano.
Esa distribución es el diseño, no un accidente. La lógica determinística se lleva todo aquello donde la lógica determinística alcanza, porque es auditable, repetible y gratuita. La capa de razonamiento se reserva para el residuo donde ninguna regla puede decidir: una contraparte abreviada en una descripción bancaria, un monto que no amarra al centavo, un pago que hay que repartir entre varias facturas. Y cada una de esas propuestas pasa por una capa de validación con autoridad para rechazarla por identidad, dirección, monto, fecha o contraparte antes de llegar a una persona.
El número que cierra el argumento es el último. En todo el despliegue, ningún vínculo entre un movimiento bancario y una factura se ha tecleado desde cero. El sistema propone; el contador aprueba, corrige o rechaza. Esa es la diferencia entre software que asiste el trabajo y software que lo hace.
La capa de deducibilidad muestra la misma forma: de 3,611 facturas dictaminadas, 2,902 son deducibles, 468 no lo son, 178 quedan marcadas en riesgo y 63 caen fuera del alcance de las reglas — cada una con su razón específica, y los casos en riesgo diciéndole al despacho exactamente qué falta cuando todavía hay tiempo de conseguirlo.
Datos ilustrativos. Ninguna captura muestra información real de contribuyentes.
Qué lo hace replicable
TimbraBot resuelve conciliación. Lo que WASD construyó para resolverla no es específico de la conciliación.
La misma arquitectura aplica donde se cumplen tres condiciones a la vez: los documentos llegan en un formato que no controlas, las reglas de negocio que los gobiernan son duras y no negociables, y una respuesta equivocada sale cara. Eso describe la recepción de siniestros, el alta de proveedores y la aprobación de facturas, la documentación aduanal y de comercio exterior, la revisión de contratos y pólizas, la presentación regulatoria, y el procesamiento de expedientes clínicos o legales.
Cuatro componentes se portan directo:
La costura de ingesta.
Como el motor consume registros normalizados y nunca archivos, agregar un origen documental nuevo —otra institución, otro acomodo, otro canal de entrega— es un adaptador, no una reconstrucción.
Lectura con prueba aritmética.
Un modelo lee el documento; verificaciones determinísticas deciden si esa lectura es confiable. En cualquier lugar donde el documento cargue su propia consistencia interna —totales, saldos, partidas contra una suma— el mismo patrón convierte un problema de extracción sin límites en uno acotado.
Validación con derecho de veto.
La regla de que ninguna salida de un modelo llega a la base de datos sin pasar por código que puede rechazarla, con criterios propios del dominio, es la razón por la que a este sistema se le puede confiar una declaración. Es portable a cualquier decisión que un modelo proponga.
La experiencia entrando al motor en lenguaje llano.
Toda organización tiene reglas que viven en la cabeza de alguien y nunca llegan al software. Dejar que el experto las escriba con sus palabras y compilarlas a lógica ejecutable es el componente de mayor alcance — y el más difícil de comprar hecho.
WASD Studio
Dieciséis años construyendo software y experiencias digitales para corporativos en México, entre ellos Alsea, Coca-Cola FEMSA, L'Oréal y Heineken. TimbraBot es producto propio; el resto del trabajo se construye sobre el proceso de cada cliente.
Cómo está construido
Sección técnica. Todo lo anterior se sostiene sin ella.
Modelos y dónde se paran.
El sistema no está casado con una versión: cada ruta de llamada está instrumentada y toda migración de modelo pasa por la compuerta A/B que se describe abajo. Los modelos en operación son: la extracción documental corre en Claude Sonnet 5, con Claude Opus 5 como respaldo en la ruta de reintento; la adopción del resultado del respaldo está protegida, de modo que un reintento fallido nunca puede producir un resultado peor que la lectura primaria. La capa de razonamiento de la conciliación corre en Claude Sonnet 5. El compilador de reglas —de lenguaje natural a descriptores ejecutables— corre en Claude Haiku 4.5, dimensionado a la tarea.
Invocación.
Llamadas HTTP directas a la Messages API de Anthropic desde los nodos de código de la capa de orquestación, que corren en un sandbox sin resolución de paquetes — así que la ruta de llamada, la extracción del JSON y el SHA-256 que se usa para el direccionamiento por contenido están implementados en línea y probados contra una implementación de referencia. El pensamiento extendido se configura de forma explícita por ruta de llamada en lugar de dejarse al valor por omisión: apagado en las rutas normales de extracción y de matching, encendido únicamente en la ruta de reintento, donde una verificación aritmética fallida le da al modelo un oráculo concreto contra el cual trabajar. Sin uso de herramientas en las rutas productivas; el contrato es JSON estructurado, parseado con un extractor de delimitadores balanceados que sobrevive a texto alrededor del payload.
Prompting y manejo de contexto.
La capa de razonamiento se divide en bloques de cuarenta movimientos por llamada, con el universo de candidatos recortado a las facturas que siguen abiertas. Dentro del prompt, las entidades se direccionan por índices posicionales cortos en lugar de por sus identificadores de base de datos, con el mapeo del lado del servidor y traducción de regreso antes de validar: los identificadores nunca entran ni salen del contexto del modelo. Los registros candidatos se redujeron a los seis campos que la decisión realmente necesita. Esas dos medidas juntas bajaron 11.5% el input y 60% el output en corridas A/B medidas.
Validación como capa de primer nivel.
Ninguna salida del modelo se escribe a la base de datos. Cada propuesta se vuelve a derivar contra el conjunto de candidatos y se rechaza por cualquiera de: identificador desconocido, dirección equivocada, monto fuera de la tolerancia de su tipo de vínculo, fecha fuera de rango, importe aplicado faltante en una parcial, contradicción de contraparte, o factura ya consumida en este bloque o en uno anterior. Las búsquedas de esa capa se hacen sobre mapas sin prototipo, de modo que las entradas de contaminación de prototipo fallan estructuralmente y no por accidente. Los rechazos se cuentan por motivo, por corrida, y se persisten: la capa de validación está instrumentada como superficie de producto, no como salida de depuración.
Ingeniería de costo en producción.
Cada llamada al modelo se registra con modelo, conteos de tokens, contadores de caché y razón de paro, incluidas las llamadas fallidas, y se costea por modelo mediante vistas de base de datos. Las migraciones de modelo pasan por compuerta: un harness A/B offline byte a byte reproduce documentos reales de producción por el modelo vigente y por el candidato, con doble línea base para separar el cambio real de la varianza entre corridas, y una compuerta dura de paridad sobre el caso más denso conocido antes de desplegar. El trabajo redundante se elimina en lugar de optimizarse: la extracción está direccionada por contenido, así que reprocesar un documento sin cambios cuesta cero llamadas. Las corridas concurrentes de la misma empresa se bloquean desde la base de datos.
Claude Code en la construcción.
El código se desarrolló con Claude Code de punta a punta: la aplicación web, los cuatro pipelines de backend, las migraciones SQL y las suites de pruebas. El despliegue del backend y las migraciones de base de datos se ejecutan de forma programática a través de servidores MCP para la plataforma de orquestación y para la base de datos, que es lo que vuelve verificable el despliegue de un workflow: el código publicado se compara byte a byte contra la fuente antes de entrar en vivo, y la autenticación de cada webhook se confirma por sondeo después de cada despliegue.
Construimos sistemas que operan donde equivocarse sale caro.
TimbraBot lee documentos que nadie estandarizó, decide con reglas que no se doblan, y pone a una persona frente a cada decisión que lo amerita. Corre en producción, sobre dinero real, todos los meses.
Páginas relacionadas
Si tienes un proceso así —documentos que no controlas, reglas que no se doblan y ningún margen para una respuesta equivocada— esa es la conversación que queremos tener.
Cuéntanos tu reto de capacitación y te respondemos en menos de 24 horas hábiles.
Respuesta en menos de 24 horas hábiles · Sin compromiso
¿Prefieres una conversación directa?
Escríbenos por WhatsApp