Saltar al contenido principal
Si su equipo dedica tiempo a revisar documentos manualmente — comprobando campos, validando datos, haciendo screening de nombres — Omni puede automatizar gran parte de ese trabajo. Esta guía le ayuda a pensar cómo convertir sus Procedimientos Operativos Estándar (SOPs) existentes en workflows de Omni.

Identificar oportunidades de automatización

No todos los procesos son aptos para la automatización. Busque estas señales de que su proceso manual de revisión está listo para Omni:
SeñalPor qué importa
Verificaciones repetitivasLos mismos pasos de verificación se aplican a cada documento
Criterios consistentesLas decisiones de aprobación/rechazo siguen reglas definidas, no juicios subjetivos
Alto volumenSu equipo procesa decenas o cientos de documentos por día/semana
Riesgo de error humanoEl cansancio o la inconsistencia generan problemas no detectados
Inputs estructuradosLos documentos siguen un formato predecible (facturas, certificados de registro, formularios)

Procesos habituales que Omni puede automatizar

  • Verificación de facturas — Comprobar montos, fechas, detalles del proveedor, totales de partidas
  • Onboarding de proveedores — Validar documentos de registro empresarial y hacer screening contra listas AML
  • Revisión de formularios de compliance — Verificar que los campos requeridos estén presentes y sean válidos
  • Validación de registros empresariales — Extraer y cruzar datos de la empresa
  • Revisión de contratos — Verificar términos clave, fechas e información de las partes
  • Verificación de documentos de empleados — Validar certificaciones, licencias o documentos de identidad presentados
Omni funciona mejor con procesos que tienen reglas claras y documentables. Si su proceso de revisión depende mucho de juicio subjetivo o conocimiento institucional que no puede documentarse, puede que convenga automatizarlo de forma parcial en lugar de total.

Mapear su SOP a un workflow de Omni

Siga estos cinco pasos para convertir un proceso manual en un workflow de Omni.
1

Documente su proceso manual actual

Antes de construir nada en Omni, anote exactamente cómo su equipo maneja actualmente la revisión:
  • Quién realiza la revisión?
  • Qué documentos reciben?
  • Qué revisan en cada documento?
  • Qué decisiones toman (aprobar, rechazar, escalar)?
  • Adónde van los resultados después de la revisión?
Esto se convierte en su línea base. Traducirá cada punto a la configuración de Omni.
2

Identifique los documentos de entrada

Liste cada tipo de documento que se envía para revisión. Sea específico:
  • Es un PDF de factura? Un certificado de registro empresarial escaneado? Una hoja de cálculo?
  • Hay múltiples documentos por caso, o solo uno?
  • Los documentos necesitan cruzarse entre sí?
Omni admite JPG, PNG, PDF, TXT, DOC, DOCX, XLS, XLSX, BMP, TIFF, WEBP, CSV, HTML y MD. Hasta 5 items por folder. Si un caso involucra más de 5 documentos, agrupe documentos relacionados en múltiples folders dentro del mismo profile.
3

Defina criterios de pass/fail

Para cada verificación que realiza su equipo, anote los criterios exactos:
  • Qué hace que un documento sea aceptable? (p. ej., “Todos los campos requeridos están presentes y el total coincide con las partidas”)
  • Qué hace que un documento sea rechazado? (p. ej., “La fecha de la factura está en el futuro” o “El registro empresarial está vencido”)
  • Qué desencadena la escalación a un revisor senior? (p. ej., “El screening AML devuelve una coincidencia” o “Campos clave son ilegibles”)
Estos criterios se convierten en la lógica de decisión de su policy de Omni.
4

Escríbalo como una policy en lenguaje natural

Combine las verificaciones y criterios de los pasos anteriores en una declaración de policy estructurada. Use pasos numerados y lenguaje explícito.Plantilla:
Review the submitted [document type] by performing the following checks:
1. Extract [list of fields] from the document
2. Verify that [specific condition]
3. Check that [another condition]
4. [Additional verification steps]

Decision criteria:
- APPROVE if all checks pass and all required fields are present
- REJECT if [specific failure conditions]
- FLAG for manual review if [ambiguous conditions]
Consulte la Guía de redacción de policies para ejemplos detallados y buenas prácticas.
5

Defina qué datos necesita extraer

Decida qué datos estructurados necesitan sus sistemas downstream de cada revisión. Esto se convierte en su output schema.Pregúntese:
  • Qué campos espera su sistema backend?
  • Necesita los valores extraídos en bruto, o solo el resultado pass/fail?
  • La salida debe incluir las razones de la decisión?
Diseñe el JSON output schema para que coincida exactamente con estos requisitos.

Ejemplos del mundo real

Estos ejemplos muestran cómo los procesos de revisión manual se traducen en workflows de Omni.

Ejemplo 1: Revisión de facturas

Un miembro del equipo de finanzas abre cada PDF de factura y verifica manualmente:
  • Que el nombre del proveedor y el número de factura estén presentes
  • Que la fecha de factura sea razonable (no en el futuro, no mayor a 90 días)
  • Que los montos de las partidas sumen el total indicado
  • Que los cálculos de impuestos sean correctos
  • Que no haya números de factura duplicados en el sistema
Tiempo por factura: 5-10 minutos. Tasa de error: ~3% (errores de cálculo no detectados, duplicados pasados por alto).
Policy:
Verify the submitted invoice document by:
1. Extracting vendor name, invoice number, invoice date, line items, subtotal, tax, and total amount
2. Verifying all required fields are present and non-empty
3. Validating that the invoice date is not in the future and not older than 90 days
4. Checking that the sum of line item amounts equals the stated subtotal
5. Verifying that tax is calculated correctly based on the subtotal
6. Approve if all checks pass; reject if amounts do not match or required fields are missing; flag for manual review if date is borderline
Engines: Text Verifier - Glove (extraer y validar todos los campos)Output schema:
{
  "invoice": {
    "vendorName": "string",
    "invoiceNumber": "string",
    "invoiceDate": "string",
    "lineItems": ["string"],
    "subtotal": "number",
    "tax": "number",
    "totalAmount": "number"
  },
  "validation": {
    "allFieldsPresent": "boolean",
    "dateValid": "boolean",
    "amountsMatch": "boolean",
    "taxCorrect": "boolean"
  },
  "decision": {
    "result": "APPROVE | REJECT | MANUAL_REVIEW",
    "verificationStatus": "pending_review | approved | rejected",
    "reasons": ["string"]
  }
}
Resultado: El tiempo de revisión baja de 5-10 minutos a segundos para facturas sencillas. El equipo solo maneja los casos marcados manualmente.

Ejemplo 2: Onboarding de proveedores

Cuando se incorpora un nuevo proveedor, un oficial de compliance:
  • Revisa el certificado de registro empresarial buscando nombre de la empresa, número de registro y fecha de constitución
  • Verifica el documento de identidad del representante
  • Busca manualmente el nombre del representante en bases de datos AML/sanciones
  • Cruza los datos de la empresa entre documentos
  • Registra los resultados en una hoja de cálculo
Tiempo por proveedor: 20-30 minutos. Cuello de botella: la búsqueda AML es lenta y la consulta manual es propensa a errores.
Policy:
Verify vendor onboarding documents by:
1. Extracting company name, registration number, incorporation date, and representative name from the business registration certificate
2. Screening the representative's name against AML/sanctions watchlists
3. Cross-validating the representative name between the business registration and any submitted identity documents
4. Checking that the business registration is not expired
5. Approve if no AML matches found, all fields are consistent, and registration is valid; reject if AML screening returns a high-risk match; flag for manual review if AML returns a partial match or fields are inconsistent
Engines: Text Verifier - Glove + AML Search - PersonOutput schema:
{
  "company": {
    "name": "string",
    "registrationNumber": "string",
    "incorporationDate": "string",
    "representativeName": "string"
  },
  "amlScreening": {
    "screened": "boolean",
    "matchFound": "boolean",
    "riskLevel": "string",
    "matchDetails": "string"
  },
  "validation": {
    "fieldsConsistent": "boolean",
    "registrationValid": "boolean"
  },
  "decision": {
    "result": "APPROVE | REJECT | MANUAL_REVIEW",
    "verificationStatus": "pending_review | approved | rejected",
    "reasons": ["string"]
  }
}
Resultado: El screening AML es automático e instantáneo. Los casos limpios se aprueban automáticamente. El oficial de compliance se enfoca solo en los proveedores marcados.

Ejemplo 3: Verificación de documentos de compliance

Un equipo de compliance revisa documentos regulatorios presentados:
  • Verifica que todas las secciones requeridas estén presentes (encabezado, firma, fechas, números de licencia)
  • Comprueba que las fechas de vencimiento estén en el futuro
  • Confirma que el documento está dirigido a la entidad correcta
  • Valida que los números de referencia coincidan con los registros internos
Tiempo por documento: 10-15 minutos. Riesgo: documentos vencidos ocasionalmente se filtran durante períodos de alto volumen.
Policy:
Review the submitted compliance document by:
1. Extracting the document type, issuing authority, issue date, expiration date, license number, and entity name
2. Verifying that all required sections are present: header, body, signature block, and dates
3. Checking that the expiration date is in the future
4. Validating that the entity name matches the expected entity
5. Approve if all sections are present, the document is not expired, and entity names match; reject if the document is expired or missing required sections; flag for manual review if the entity name is a partial match
Engines: Text Verifier - Glove (validar completitud y corrección de campos)Output schema:
{
  "document": {
    "type": "string",
    "issuingAuthority": "string",
    "issueDate": "string",
    "expirationDate": "string",
    "licenseNumber": "string",
    "entityName": "string"
  },
  "validation": {
    "allSectionsPresent": "boolean",
    "notExpired": "boolean",
    "entityNameMatch": "boolean"
  },
  "decision": {
    "result": "APPROVE | REJECT | MANUAL_REVIEW",
    "verificationStatus": "pending_review | approved | rejected",
    "reasons": ["string"]
  }
}
Resultado: Los documentos vencidos se detectan automáticamente. Los revisores solo manejan casos límite donde los nombres coinciden parcialmente o las secciones son ambiguas.

Diseñar output schemas efectivos

Su output schema determina qué datos estructurados obtiene de cada análisis. Diséñelo pensando en sus sistemas downstream. Todo output schema debería incluir estos tres bloques:
BloquePropósitoCampos de ejemplo
Datos extraídosValores en bruto obtenidos de los documentosvendorName, invoiceNumber, registrationDate
Resultados de validaciónPass/fail por verificación con razonesamountsMatch, dateValid, fieldsConsistent
DecisiónVeredicto final y estado de routingresult, verificationStatus, reasons
Si omite el bloque de decisión, tendrá que escribir su propia lógica de decisión basada en los resultados de validación en bruto. Incluir un bloque de decisión permite que el agente de IA tome la decisión final basándose en los criterios de su policy.

Routing con verificationStatus

Cada análisis expone verificationStatus: approved, pending_review o rejected. Ramifique sus integraciones basándose en ese enum.
verificationStatusAcción recomendada
approvedAceptar automáticamente y registrar en sus sistemas
pending_reviewEnviar a una cola humana con los hallazgos de IA y datos extraídos
rejectedDenegar o cerrar el caso según su policy
Este enfoque significa que Omni no reemplaza completamente a su equipo de revisión. Aprueba automáticamente los casos directos y envía los ambiguos o fallidos a la cola correcta con contexto.
Monitoree la frecuencia con que aparece cada estado y compare con los resultados manuales. Ajuste el lenguaje de la policy o su output schema cuando las tasas de pending_review o rejected se desvíen de las expectativas.

Patrón de implementación

if verificationStatus == "approved":
    → auto-accept, record in system
elif verificationStatus == "pending_review":
    → send to reviewer queue with AI findings highlighted
else:  # rejected
    → denial flow or manual escalation per policy
Integre esta lógica en su backend después de recuperar los resultados del análisis de la Omni API.

Medir el éxito

Después de desplegar un workflow de Omni, monitoree estas métricas para medir el impacto:
MétricaCómo medirObjetivo
Reducción del tiempo de revisiónTiempo promedio por caso antes vs. despuésReducción del 50-80% para casos auto-aprobados
Tasa de errorPorcentaje de decisiones incorrectas (compare resultados de Omni con verificaciones manuales puntuales)Igual o menor que la tasa de error manual
ThroughputCasos procesados por día/semanaAumento significativo por el procesamiento automático
Tasa de escalaciónPorcentaje de casos enviados a revisión humanaDebería disminuir con el tiempo a medida que refina las policies

Enfoque de despliegue recomendado

1

Piloto con un solo workflow

Elija su proceso de revisión de mayor volumen y más basado en reglas. Cree un workflow de Omni para él y ejecútelo en paralelo con su proceso manual durante 1-2 semanas.
2

Compare resultados

Verifique las decisiones de Omni contra las decisiones manuales de su equipo. Busque discrepancias e investigue si Omni o el revisor humano tenía razón.
3

Refine la policy

Basándose en la comparación, ajuste el lenguaje de su policy, output schema o umbrales de puntuación. Pequeños cambios suelen producir mejoras significativas.
4

Expanda gradualmente

Una vez validada la precisión, deje que Omni maneje el proceso de punta a punta. Luego pase a automatizar procesos de revisión adicionales.

Siguientes pasos

Crear un workflow

Guía paso a paso para construir su primer workflow en el dashboard.

Guía de redacción de policies

Buenas prácticas para redactar policies de verificación efectivas.