Portfolio · anonymised workflow proof
Anonymised build patterns from real workflow systems: voice agents, ticket intelligence, policy copilots, audio-to-actions workflows, SEO/schema tools and risk-controlled automation.
Flagship systems
These are the strongest implementation patterns: the kind of system that needs architecture, integrations, logs, fallbacks and human handoff rather than a single prompt.
Twilio-style call handling, realtime AI, knowledge-base lookup, Zendesk-style ticket creation and human transfer. One anonymised 90-day dataset showed 6,814 calls and 59% no-transfer containment.
Open use casePrivate transcription-run proof for turning long recordings, calls and voice notes into searchable transcripts, summaries, owners and review queues.
Open use caseTicket summaries, categorisation, KB gap analysis and safe help-centre operations. One anonymised benchmark mapped 24,166 tickets over 90 days, with 71% in new-business or order-ops demand.
Open use casePaperwork auto-filing, PO/reference extraction and exception queues. One anonymised benchmark mapped 4,866 supplier tickets over 90 days, with only about 2.6% as genuine problem tickets.
Open use caseVoice/API lead capture, quote-context extraction and problem-vs-sales routing. One anonymised 90-day benchmark mapped 6,810 sales enquiries and 3,531 quote-tagged tickets.
Open use caseSource-bounded Q&A plus weighted project-investor-supplier matching. One clean-energy architecture proof modelled 29 projects, 15 investor mandates, 14 supplier profiles and explainable scoring.
Open use caseVoice-agent benchmark
From an anonymised live voice-agent dataset: 6,814 calls over 90 days, 3,995 marked AI-solved without human transfer, and 2,773 transferred to a person. That is a 59% no-transfer rate, with a safer commercial model of roughly half handled until the new workflow has its own baseline.
Real operational volume, not a ten-call demo.
About 59% were marked solved without human transfer in that window.
Handled calls × minutes avoided × staff cost, minus AI/telephony/support. Example: ~£2k/month labour-equivalent at 5 minutes and £18/hour.
Audio-to-actions architecture proof
One private recorder-takeout workflow is useful as implementation proof: it shows manifests, batch transcription, progress state, chunking, empty-output tracking and reviewable transcript artifacts without exposing private audio content.
Text plus JSON transcript files prove the workflow produced searchable and machine-readable review material.
The progress layer tracks completion explicitly instead of relying on a one-off script run.
Low-value recordings are classified separately so humans know what did not produce usable content.
Long audio and model-limit failures are surfaced in logs, making the pipeline maintainable.
Support-desk benchmark
One anonymised 90-day support dataset showed 24,166 tickets. The useful work was not guessing replies; it was identifying which themes, channels and teams created the pressure.
Enough volume to find repeated operational patterns, not just anecdotal support pain.
New business and existing-order work dominated the queue, making summaries, routing and clean handoffs higher-value than generic chatbot replies.
Voice plus live chat created half of all tickets, so call/chat summaries and KB gap detection become operational levers.
Supplier-comms benchmark
In one anonymised supplier-communications audit, the majority of volume was routine paperwork. The valuable workflow was auto-linking confirmations and surfacing the small problem set fast.
About 20% of support volume and enough to justify a dedicated rules-plus-AI triage layer.
Asynchronous supplier messages are ideal for queued parsing, classification and reference matching.
Most items can be filed; failed collection, delay/no-show and failed delivery need human escalation.
Sales/quote benchmark
The anonymised audit showed high quote demand, voice/API intake dominance and a meaningful share of “sales” tickets that were actually mixed with support or operations issues.
Enough volume to justify structured capture and routing instead of free-text notes.
Quote context should be captured cleanly before a human picks up the lead.
Delivery, transport, collection, refund and equipment signals need different queues from fresh quotes.
Policy/matching architecture proof
One clean-energy platform build pattern modelled projects, investor mandates, supplier profiles and country policy briefs before adding AI answers or shortlists.
Structured project facts included technology, stage, MW size, CAPEX, grid status and tags.
Mandates and capabilities were stored separately so matches could be scored and explained.
Semantic similarity, geography, technology and size/ticket fit were combined instead of relying on keyword search alone.
The copilot uses policy brief fields, checklist extraction, disclaimers, rate limits and usage logging.
Trading/risk automation architecture proof
One private financial-automation lab pattern is useful as engineering proof: it shows market-data ingestion, simulation, risk gates, journaling and review dashboards without making trading-performance claims.
Trade journal rows prove the workflow produced structured operational records, not just console logs.
Risk events are recorded separately with action taken, making limit breaches and interventions reviewable.
Strategy logic is tested against historical windows before it is trusted in a live-style workflow.
The public-safe value is the control architecture: dry runs, limits, dashboards, alerts and audit trail.
Reusable tool systems
These are practical, productisable systems for SMEs: they work as lead magnets, internal admin tools, SEO support layers or maintained operational helpers.
URL-first metadata, FAQ and JSON-LD tooling backed by 3 SEO AI endpoints, 21 page-snapshot fields, safe schema fallbacks and no unsupported price/review/NAP generation.
Open use caseTopic maps, article briefs, researched drafts, generated header assets, schema blocks, internal links and deployment QA as one workflow.
Open use caseCalculators, checkers, product selectors and niche advisors that answer a visitor’s practical question and route the next step.
Open use caseTranscribe calls, meetings and voice notes, then extract summaries, owners and follow-up tasks for human review.
Open use caseRisk limits, market-data ingestion, SQLite journals, reconciliation and dashboards for high-impact automation labs. No investment-advice or returns claim.
Open use casePuppeteer/Lighthouse scan runner, issue scoring, report dashboard, sitemap crawl, JSON-LD validation and mobile browser QA gates.
Open use caseURL-first schema proof
The implementation pattern uses live-page snapshots, guardrail prompts and fallbacks so the output starts from what is actually visible on the page, not from invented business facts.
Separate generators handle metadata/Open Graph, FAQ blocks and JSON-LD schema so each output can be reviewed independently.
The crawler captures final URL, status, content type, title, meta description, canonical, robots, language, headings, text sample, word count and social metadata.
Allowed outputs are WebPage, Article, FAQPage, LocalBusiness, Product, Service and BreadcrumbList, with Auto choosing the safest type.
The prompt rules block unsupported prices, ratings, phone numbers and addresses unless they are present in the page snapshot or supplied by the business.
Technical SEO deploy QA proof
The scanner/reporting pattern turns checks into structured records: what was crawled, what failed, how severe it is and what needs to be reviewed before a page is called live.
Meta tags, performance, images, links, SSL, content depth, mobile viewport and robots/noindex checks.
Missing titles, descriptions, H1s, alt text, SSL, viewport, noindex and placeholder-link issues become prioritised report items.
Sites, scans, issues, templates, comparisons and queue records support historical reports rather than one-off notes.
Final release checks include live-domain HTTP, sitemap, JSON-LD, console/network and mobile overflow/screenshot verification.
Public-safe proof
The public site uses architecture, workflow shape, component lists and safety boundaries. It does not publish private repo paths, call data, client phone numbers, ticket IDs, credentials, unverified testimonials or made-up savings figures.
Next step
Send the workflow or page you want to improve. We will map the first useful version, the data boundary and the review point.