Interactive automation demos

Supplier invoices arrive as PDFs and photos across several mailboxes. Someone opens each one, retypes the supplier, number, date, VAT and total into a spreadsheet or the accounting system, then chases approvals over chat. The work is invisible until something is paid twice or a deadline is missed.

Mailbox → manual download → manual retyping → ad-hoc chat approval → manual entry into accounting → month-end reconciliation from memory.

A watched inbox feeds an extraction pipeline. OCR plus an LLM pull the fields into a strict schema, deterministic code validates them, and anything uncertain or above a threshold goes to a human approval queue before it is exported. Nothing reaches the accounting system unapproved.

1. Trigger — IMAP/Gmail watcher on a dedicated inbox, attachment filter by MIME type and size
2. Extract — OCR for scans and photos → LLM extraction into a fixed JSON schema (supplier, VAT ID, invoice number, dates, currency, net, VAT, total, line items)
3. Validate — Deterministic checks in code, not in the model: arithmetic, VAT-ID format, duplicate invoice number per supplier, due date sanity, currency allow-list
4. Route — Confidence score and amount threshold decide auto-pass vs. human approval queue
5. Approve — Approval message with the parsed fields and a link to the original file; approve / correct / reject
6. Export — Approved records appended to the accounting export (Sheets/CSV/API) with the source file reference
7. Report — Daily digest: processed, held for review, rejected, duplicates caught

Reads unstructured documents and proposes structured fields. Classifies document type. Flags low-confidence extractions. It never decides that an invoice is payable.

Approves or corrects every record above the configured threshold, and every low-confidence one. Owns the chart of accounts, VAT treatment and the decision to pay. Final financial and accounting decisions remain under human control.

Per-step retries with exponential backoff on transient API failures. Poison-message queue: a document that fails three times is parked with the raw payload and the error, never silently dropped. Arithmetic and duplicate failures always route to a human rather than being auto-corrected. Every run writes a structured log line with the document id.

Least-privilege API credentials held in the automation platform, never in a frontend. Originals stay in the client's own storage. Only extracted fields, not full documents, are sent to the model, and PII fields can be masked before extraction. Access to the approval queue is role-based. Full audit trail of who approved what and when.

Enquiries land in a website form, WhatsApp and a shared inbox. They are copied into a spreadsheet when someone remembers. Nobody can say how many arrived last week, which were answered, or which quietly went cold.

Three inboxes → manual copy into a spreadsheet → manual reply → follow-up only if someone remembers → no shared pipeline view.

One intake webhook normalises every channel into a single lead schema. An LLM asks the qualifying questions and scores fit; the CRM record, calendar slot, owner notification and follow-up sequence are then created deterministically. Complex or unusual enquiries are handed to a person with the full conversation attached.

1. Intake — One webhook endpoint; per-channel adapters normalise website, WhatsApp and email into a single lead schema
2. Dedupe — Match on email and phone hash before creating anything; existing leads are updated, not duplicated
3. Qualify — Short LLM-driven exchange: what they need, timeline, budget band, decision role — mapped to a structured score
4. Enrich — Optional company lookup from the email domain
5. Create — CRM contact plus deal at the correct pipeline stage, with the source channel and full transcript attached
6. Schedule — Calendar availability check and booking when the lead asks for a call
7. Notify — Owner alert with the qualification summary; SLA timer starts
8. Follow up — Scheduled nudges that stop immediately on any human reply

Conducts the qualifying conversation, summarises intent, proposes a score and pipeline stage, drafts the first reply. It does not decide pricing or make commitments.

Owns pricing, scope and any promise to the client. Reviews the proposed stage for anything above a value threshold. Takes over the conversation the moment the lead asks something outside the defined scope.

Idempotency key per intake event so a retried webhook cannot create a second deal. If the CRM API is down the lead is queued and retried, and the owner is notified that a lead is pending rather than lost. Failed calendar bookings fall back to sending the human's booking link. Follow-ups are cancelled on any inbound human message.

Webhook signature verification and rate limiting on the intake endpoint. Contact data is stored in the client's CRM, not in the automation layer. Transcripts are retained for a configurable window and then purged. Credentials scoped per integration; no secret ever reaches the browser.

Posting is done by hand, in bursts, whenever someone has time. Drafting, resizing, scheduling and reporting are spread across people and tools, so the calendar has gaps and nobody can compare what worked.

Ad-hoc ideas in chat → manual writing → manual resizing → manual posting → screenshots pasted into a monthly report.

Source material lands in one intake. An LLM drafts per-platform variants against a brand brief; every draft goes through a human approval queue before anything is scheduled. Publishing uses official platform APIs only, and results flow back into a single report.

1. Intake — Ideas, assets and briefs arrive via a form or a watched folder and become a content item
2. Draft — LLM produces per-platform variants against a stored brand brief: tone, claims to avoid, CTA rules, length limits
3. Assets — Per-platform crops and alt text generated for each variant
4. Approve — Nothing publishes without an explicit human approval; edits are captured and fed back into the brief
5. Schedule — Approved items placed on the calendar with per-platform timing rules
6. Publish — Official platform APIs only, with per-platform rate limiting
7. Collect — Reach, engagement and clicks pulled back on a schedule
8. Report — Weekly summary comparing performance by format and topic

Drafts copy variants, proposes hashtags and alt text, summarises performance. It never publishes and never invents a statistic or a claim about the business.

Approves or rewrites every item before it is scheduled. Owns brand voice, factual claims and anything regulated. Can pull a scheduled item at any time.

Publishing failures retry with backoff and then surface in the approval channel with the platform error text. A rejected or expired item never silently republishes. Token expiry raises an alert before the next scheduled slot rather than failing at post time.

Platform tokens stored in the automation platform with per-platform scopes and rotation reminders. Only official APIs are used — no scraping, no automation that violates platform terms. Approval actions are attributed to a named person and logged.