Business automation playbooks

The problem

People copy invoice, order or form details into another system, then spend more time finding omissions, resolving conflicting values and checking revisions.

Choose the simplest useful approach

Start with a structured form or an existing export when available. Use deterministic labels for consistent documents. Add OCR or model-assisted extraction only where the variation warrants it; a chat window is not a required interface.

A working delivery sequence

1. Define each field, type and source location; retain the original document reference and revision.
2. Extract into a review queue. Leave absent values, conflicting candidates and uncertain results visible rather than inventing replacements.
3. Validate totals and identifiers, reconcile duplicate deliveries, and export only the reviewed version to the destination system.

What to measure

Reviewed field correctness, omitted values, review minutes, correction effort and end-to-end completion per document. Compare like-for-like document types, including difficult and unreadable examples.

Start with working checks

• Try Document DeskFree workspace: one document, two pages; a separate $79 offline edition is available.
• Measure extracted fieldsCompare reviewed scalar values with supplied outputs; this check does not extract documents.

Take it further

One agreed workflow, tests, exceptions and handoff under a written quote. Model usage and deployment are identified separately.

The problem

Useful instructions live across PDFs, shared drives and old revisions. Staff search repeatedly, and a confident answer may quote a document that is obsolete or unavailable to that person.

Choose the simplest useful approach

Fix version ownership and ordinary search first. Use retrieval-assisted AI for synthesis across approved material when it adds value. A local deployment can be considered alongside a private cloud; neither alone establishes accuracy or permission handling.

A working delivery sequence

1. Name the document owners, permitted readers and revision policy. Establish a representative set of questions with reviewed source evidence.
2. Index the intended versions and enforce access before retrieval. Keep source links and a no-answer path when the required evidence is absent.
3. Measure retrieval separately from the generated answer, including conflicting revisions and unauthorized-document tests. Track corrections without overwriting the earlier evaluation.

What to measure

Retrieval recall and ranking, answer correctness against reviewed evidence, missing-document coverage, resolution time and review effort. A retrieval score alone does not prove a grounded final answer.

Start with working checks

• Evaluate document retrievalJudged document IDs and ranked results; no document content or model calls.
• Check index delivery metadataSupplied snapshot timestamps and counts; not a live index inspection.

Take it further

A quoted pilot defines sources, access, evaluation and operating handoff. Local AI hardware, hosting and model costs are separately identified.

The problem

One system says a record changed while another still has the previous version. A recent import does not establish complete coverage, and retries can create duplicate updates.

Choose the simplest useful approach

Use the vendor-supported export, native connector or ordinary scheduled synchronization if it meets the requirement. A custom connector is useful when identity, transformations, audit history or exceptions need behavior the existing tools do not provide.

A working delivery sequence

1. Define stable record IDs, expected partitions, ownership and covered-through timestamps. Distinguish a known zero count from an unknown delivery.
2. Compare versions, validate the transformation and inspect ambiguous records. Preserve the original source and receipt times.
3. Apply idempotent updates, record business effects and reconcile failed or late deliveries. Keep a clearly dated previous version available without calling it current.

What to measure

Changed records reconciled, missing partitions, stale content, collection delay, duplicate effects, exception age and operator correction time. Do not equate a successful request with a completed business update.

Start with working checks

• Check data feed healthExplicit cutoff and customer-supplied limits; no continuous monitoring.
• Compare CSV exportsSmall local comparisons; custom mapping and a production sync are separate work.
• Inspect retry effectsRecorded attempts and effect counts; no live replay or connector.

Take it further

One agreed input, transformation and inspectable output. A multi-system connector, monitoring and ongoing operation require a separate scope and quote.

The problem

Incoming requests need classification, missing information, an owner and a follow-up. The wrong route can be more costly than leaving an uncertain case for review.

Choose the simplest useful approach

Use explicit forms, rules or existing helpdesk routing for predictable requests. Add classification or extraction for genuinely varied content; keep unusual, incomplete and consequential cases in a human review queue.

A working delivery sequence

1. Define useful categories, owners and the outcome expected from each route. Label representative examples before comparing implementations.
2. Separate classification from execution. Record abstentions and unknown cases, and preserve which rule or model version proposed each action.
3. Use bounded tool actions with appropriate approvals, idempotency and recorded outcomes. Reconcile failed attempts and preserve a manual path.

What to measure

Per-class precision and recall, wrong-owner transfers, abstentions, resolution time, review minutes, duplicate effects and completed handoffs. Track rare but costly errors separately from aggregate accuracy.

Start with working checks

• Measure routing decisionsSingle-label reference decisions; scores do not establish reliable future performance.
• Inspect recorded actionsSerial recorded tool calls; not a live agent runner or workflow approval.
• Test intended tool permissionsSupplied labels and expected rules; not authenticated live authorization.

Take it further

One defined workflow under a written quote. External actions, operating responsibility and recurring costs are agreed separately.

The problem

A renamed tool, required argument or changed response breaks an integration. A successful schema check still cannot prove that authentication, side effects or retries behave correctly in production.

Choose the simplest useful approach

Prefer existing client libraries and provider-supported connectors where they fit. Combine static contract checks with integration tests and a bounded rollout instead of treating one lint result as release permission.

A working delivery sequence

1. Retain before/after contracts and representative payloads. Name the consumers, authentication boundary and business effects.
2. Review compatibility, negative authorization cases, failures and repeated delivery. Measure recorded outcomes using stable case IDs.
3. Ship the agreed change with versioning, rollback and operating notes. Verify real authentication and tool execution separately from local contract or policy simulation.

What to measure

Compatibility findings, rejected invalid payloads, incorrect grants, duplicate effects, missing telemetry and completed business actions. Compare recorded costs and latency without assuming the same workload.

Start with working checks

• Check API and payload contractsFree bounded browser checks; integration execution remains separate.
• Compare MCP catalog changesComplete supplied tool catalogs; not an OAuth or runtime conformance certification.
• Test intended tool permissionsDefault-deny policy simulation only; real identity must be checked in the implementation.

Take it further

One-time offline software with CLI, SDK, private CI and five local MCP checks. Feed, policy, extraction, retrieval and recorded-agent analyzers remain separate free tools. Custom integration is separately quoted.

The problem

A job, quote or approval passes through email and several spreadsheets. People cannot see the current owner, missing evidence or the next action without asking someone.

Choose the simplest useful approach

A better shared form, existing project tool or conventional application may solve the task without AI. Add model assistance only to a bounded step such as extracting a request or drafting a reviewed summary.

A working delivery sequence

1. Map the current handoff, record identifiers, roles and exceptions. Identify the smallest end-to-end slice that helps a real user.
2. Build usable intake, state transitions, attachments and an owner queue. Keep access, audit history, exports and recovery explicit.
3. Test actual user tasks, failed dependencies and restore behavior. Include deployment, operating notes and an agreed maintenance boundary.

What to measure

Cycle time, repeat data entry, missing evidence, stalled handoffs, review effort and completed jobs. Freed time is additional capacity unless the organization actually reduces paid costs.

Start with working checks

• Organize a request in the free betaPublished beta usage and retention limits apply; not a custom production app.
• Compare workflow effort and costsUser-supplied assumptions, not measured savings or a quote.

Take it further

Written milestones, acceptance tests, ownership and handoff. Licenses, hosting, migration and support are separately stated.