# Spark — full content > The AI operating layer for modern professional services firms. ## Home URL: https://www.sparkconsulting.tech/ Spark is the AI operating layer for modern professional services firms. We design and build custom automation systems for finance, legal and professional services businesses that can't afford downtime or sloppy work. ### What we do We map where AI and automation create value, build production-grade systems against your real data, and keep them healthy once live. Jersey-based, serving the UK. - Fixed pricing, no hourly billing - Senior-led delivery, end to end - Engagements from four weeks - Jersey-based, serving the UK ### Our approach From discovery to operating system, in four considered steps. - Discovery — map processes end to end and find the highest-leverage points for automation. - Design — a specification any engineer could pick up, and a clear ROI model for the board. - Build — built and tested against real data. Working systems only, no vapourware demos. - Operate — go live with training, documentation, and monitoring of every critical path. ## Services URL: https://www.sparkconsulting.tech/services Three engagements designed for finance, legal and professional services firms: a costed AI roadmap, a fixed-scope build sprint, and an embedded operating partner retainer. ### AI & Automation Roadmap From £15k · 4–6 weeks. A short, focused engagement to map where AI and automation create the most value across your firm — and produce a costed plan you can act on. ### AI & Automation Build Sprint From £40k · 8–12 weeks. A fixed-scope sprint to deliver one or two production-grade automations or AI workflows that take real work off your team. ### AI & Automation Operating Partner From £6k/month · monthly retainer. We act as your fractional AI and automation lead — running the roadmap, shipping new systems, and keeping what's live healthy. ## AI & Automation Roadmap URL: https://www.sparkconsulting.tech/services/roadmap A 4–6 week engagement that produces a costed AI and automation roadmap for professional services firms: operating model audit, opportunity scoring, target architecture and a board-ready plan. ### What you get A clear-eyed audit of your operating model, a scored list of automation opportunities, a target architecture, and a costed plan you can take to the board. - Operating model audit - Opportunity scoring and prioritisation - Target architecture - Board-ready, costed plan ### Pricing From £15k. Fixed price, 4–6 weeks. ## AI & Automation Build Sprint URL: https://www.sparkconsulting.tech/services/build-sprint An 8–12 week fixed-scope sprint to ship production-grade AI and automation systems for professional services firms: real integrations, operator tooling, audit trails and 60 days of stabilisation. ### What you get One or two production-grade automations built and tested against your real data, with the tooling your operators need and a stabilisation period after go-live. - Real integrations, not demos - Operator tooling and audit trails - 60 days of stabilisation included ### Pricing From £40k. Fixed scope, 8–12 weeks. ## AI & Automation Operating Partner URL: https://www.sparkconsulting.tech/services/operating-partner A monthly retainer where Spark acts as your fractional AI and automation lead — running the roadmap, shipping new systems each quarter, and keeping live systems healthy. ### What you get Continuous roadmap delivery, new systems shipped each quarter, monitoring of everything live, and quarterly board reporting. - Fractional AI & automation leadership - Quarterly shipping - Monitoring of live systems - Quarterly board reporting ### Pricing From £6k/month. Ongoing engagement. ## Automation ROI Calculator URL: https://www.sparkconsulting.tech/roi-calculator Estimate the annual billable value your firm loses to manual administrative work — and how much of it automation could recover. A quick, three-step calculator for professional services firms. ### How it works Tell us your firm profile, the administrative friction points that eat your team's week, and roughly how many hours each fee earner loses to them. We estimate the annual lost billable value and an illustrative recovery projection. - Step 1 — fee earners and average hourly billable rate - Step 2 — which administrative tasks create friction - Step 3 — hours lost per fee earner each week ## About URL: https://www.sparkconsulting.tech/about Spark is a lean, senior studio of automation and AI specialists based in Jersey, Channel Islands. Built by operators, for operators. ### Founder Spark was founded by Seb Lawson, who has spent the last decade building and scaling technology companies — from Zipline (autonomous drone delivery) to JustPark (scaled to exit in London). Now based in Jersey, he is also Head of Innovation at Digital Jersey. ### How the studio is built Founder-led, with a senior bench. Seb leads every engagement personally, supported by a vetted network of senior contract specialists in automation engineering, AI and data, and delivery — brought in per engagement as the work demands. No junior handoffs. ### How we work We eat our own cooking: every automation system we sell runs our own studio first. Based in Jersey, serving professional services firms and growing businesses across the UK. ## Contact URL: https://www.sparkconsulting.tech/contact Book a free 30-minute discovery call with Spark. No commitment, no sales pitch — a structured conversation about your processes and automation potential. ### What to expect Thirty minutes, structured, no pitch. You describe your current state, we explore solutions with real ROI numbers, and you leave with clear next steps. ## FAQ URL: https://www.sparkconsulting.tech/faq Common questions about Spark's automation services, pricing, timelines, security, and process. ### How is this different from a traditional agency? Traditional agencies bill hourly and scope loosely. We offer fixed pricing and transparent timelines: a Roadmap in 4–6 weeks, a Build Sprint in 8–12. Senior delivery, not large-team overhead. ### What if the automation doesn't work as expected? Every project starts with a blueprint you approve before we build. We test against your real data, Build Sprints include 60 days of stabilisation support, and we make it right or refund if we can't deliver what we promised. ### How do you handle our data? We sign NDAs before discovery. Client data is encrypted, segregated by project, and never used outside your engagement. Security documentation available on request. ## State of AI & Automation URL: https://www.sparkconsulting.tech/automation-research Spark's research into how businesses across the UK and Channel Islands are putting AI and automation to work — and what the smart ones are doing differently. ### The report Adoption trends, where value is being created, and practical takeaways for professional services firms. Read the full State of AI & Automation report. ## How we work URL: https://www.sparkconsulting.tech/how-we-work How Spark delivers AI and automation: a four-phase process — discovery, design, build and operate — built for regulated professional services firms. ### The process The same four phases sit under every engagement. - Discovery — map the operating model end to end and find the highest-leverage automation. - Design — a specification any engineer could pick up and a costed ROI model for the board. - Build — built and tested against your real data, with human-in-the-loop checkpoints and audit trails. - Operate — go live with training, documentation and monitoring of every critical path. ### Workshop with Claude We run live working sessions with Claude in the room — designing, prototyping and pressure-testing an automation against your real scenarios before we build it for production. ### Principles The rules we don't break. - Working systems only — no vapourware demos. - Human-in-the-loop by design. - Built and tested on your real data. - Auditable end to end. - Senior operators, no junior handoffs. - We eat our own cooking. ## Our stack URL: https://www.sparkconsulting.tech/tools The AI and automation tools Spark builds with — Claude, GPT and Gemini for reasoning; n8n, Make and Zapier for automation; Vapi and ElevenLabs for voice. Platform-agnostic by principle, opinionated by default. ### Reasoning & language Models for the judgement-based work — reading documents, drafting, triage. - Claude (Anthropic) — our default for document-heavy, regulated work. Spark is a Claude partner: workshops, training, rollout and custom builds. - OpenAI GPT — where its speed, tooling or ecosystem fits. - Google Gemini — long-context tasks and Google Workspace firms. ### Automation & orchestration The plumbing that connects your systems. - n8n — our default orchestrator; self-hostable and fully auditable. - Make — hosted, visual automation when it fits. - Zapier — quick connections across the long tail of SaaS. ### Voice & content For calls and content at scale. - Vapi — AI voice agents for inbound and outbound calls. - ElevenLabs — natural voice generation. ### Where it plugs in We connect to the systems you already run — HubSpot, Notion, Slack and hundreds more. If it has an API, we can connect it. ## Claude partner — workshops, training & implementation URL: https://www.sparkconsulting.tech/tools/claude Spark is a Claude partner. Leadership briefings, hands-on Claude workshops, team training, firm-wide rollout, custom Claude API systems and agents via MCP — for regulated professional services firms. ### What it is Claude is a family of large language models from Anthropic, strong at careful reading, following instructions precisely, and knowing when to defer to a human. It's the model we reach for first on regulated, document-heavy work — and the one we know best. ### Claude partner Spark is a Claude partner. We implement Claude for firms, run hands-on Claude workshops and training, and build our own studio on it — sales, delivery and operations. Nothing we recommend is theoretical. ### Ways to work with us Whether your firm is Claude-curious or already building, there's an engagement shaped to where you are. - Leadership briefings — capability, risk, governance and cost for boards and executives, in plain language. - Hands-on workshops — live sessions with Claude in the room, prototyping against your real scenarios. - Team training & enablement — role-based training with prompt patterns, verification habits and a safe-use policy. - Firm-wide Claude rollout — workspace setup, permissions, usage policy, data governance and internal champions. - Custom Claude systems — production builds on the Claude API, human-in-the-loop and logged end to end. - Agents, MCP & Claude Code — agents connected to your systems through the Model Context Protocol, inside auditable boundaries. - Evaluation & assurance — benchmarks on your own documents and model-risk documentation for your regulator. - Ongoing partnership — your Claude estate kept current under an Operating Partner retainer. ### Where we put it to work Document reading and extraction, first-pass drafting, triage and classification, periodic reviews and monitoring, meeting minutes and board packs, and grounded knowledge lookup across your own precedents. ## Implement OpenAI GPT URL: https://www.sparkconsulting.tech/tools/gpt How Spark helps firms implement OpenAI's GPT models — extraction, drafting and tool-connected workflows, benchmarked against alternatives, with full audit trails. ### What it is GPT is OpenAI's family of large language models, with a broad ecosystem of tools, features and integrations. We reach for it where those fit a particular job better than the alternatives. ### How we help you implement it Where GPT's speed, function-calling or ecosystem is the better fit, we build it into an auditable workflow connected to your systems, and benchmark it against Claude and Gemini on your actual task so the choice is evidence-based. ### Where we put it to work Three ways it earns its place. - Structured extraction — turning messy documents and emails into clean data. - Content generation — drafting and repurposing content at volume for human review. - Tool-connected workflows — letting the model look things up and take actions under logged rules. ## Implement Google Gemini URL: https://www.sparkconsulting.tech/tools/gemini How Spark helps firms implement Google Gemini — long-document analysis and Workspace-native automation, built into governed workflows with full audit trails. ### What it is Gemini is Google's family of large language models, strong on long-context tasks and tightly integrated with Google Workspace and Cloud. ### How we help you implement it If your firm already runs on Google Workspace, we build Gemini into governed workflows close to where your documents and email live, and use it where a task genuinely needs its long context window. ### Where we put it to work Three ways it earns its place. - Long-document analysis — reading and summarising very long documents in one pass. - Workspace-native automation — across Docs, Sheets, Gmail and Drive. - Research and synthesis — pulling many sources into a drafted, checkable summary. ## n8n implementation, training & managed automation URL: https://www.sparkconsulting.tech/tools/n8n Spark designs, deploys and runs n8n for firms — self-hosted deployment, production workflow builds, migration from Zapier/Make, team training and managed operation. Auditable automation you own. ### What it is n8n is a workflow-automation platform that connects your tools and runs multi-step processes. Because it can be self-hosted, your data and workflow logic can stay entirely under your control. ### Ways to work with us From a first workflow to a firm-wide automation estate your own team can run. - Process mapping & automation design — which processes deserve automation, and a blueprint before anything is built. - Self-hosted deployment — n8n in your own environment with access control, backups and an upgrade path. - Workflow build & integration — production workflows with error handling, approval gates and Claude at the judgement steps. - Migration & consolidation — scattered Zapier zaps, Make scenarios and scripts brought into one auditable estate. - Team training & handover — your operations team trained to run and extend the workflows. No lock-in. - Managed operation — we monitor, fix and evolve the estate under an Operating Partner retainer. ### Where we put it to work System-to-system integration, scheduled and triggered processes, AI orchestration with human sign-off, client onboarding pipelines, reporting and document assembly, and exception alerting. ## Implement Make URL: https://www.sparkconsulting.tech/tools/make How Spark implements Make — fast, hosted, visual automation connected to your systems, with the error handling and logging to keep it reliable in production. ### What it is Make is a hosted, visual automation platform for connecting apps and building multi-step workflows without managing infrastructure. ### How we help you implement it Where a hosted platform and fast iteration suit the brief, we design and build the scenarios, connect them to your tools, and add the error handling and logging that keep them reliable in production — and steer you to n8n where data control matters more. ### Where we put it to work Three ways it earns its place. - App-to-app workflows — connecting the SaaS tools your team uses. - Notifications and routing — getting the right information to the right place automatically. - Rapid prototypes — proving value quickly before hardening. ## Implement Zapier URL: https://www.sparkconsulting.tech/tools/zapier How Spark implements Zapier — fast, reliable connections across your SaaS tools, built properly with error handling so they quietly work instead of silently failing. ### What it is Zapier is a widely-used automation service that connects thousands of SaaS apps with lightweight, trigger-based workflows. ### How we help you implement it For the many small connections that make a firm run, we build Zapier workflows properly, with sensible error handling so they quietly work — and move a workflow to n8n where it grows complex or needs tight data control. ### Where we put it to work Three ways it earns its place. - Long-tail app connections — wiring together niche tools without native integrations. - Form and intake automation — turning submissions into records, tasks and notifications. - Quick wins — removing small, repetitive manual steps fast. ## Vapi voice agents — design, implementation & tuning URL: https://www.sparkconsulting.tech/tools/vapi Spark designs, pilots and runs Vapi voice agents for firms — call-flow workshops, calendar and CRM integration, compliance guardrails, human handoff and ongoing tuning. ### What it is Vapi is a platform for building AI voice agents that can handle inbound and outbound phone calls and connect to your back-end systems. ### Ways to work with us From designing the first call flow to running voice agents your clients actually like talking to. - Call-flow design workshop — mapping your call types and designing what the agent handles, says, and must never promise. - Pilot on one call type — proven against real scenarios before it goes near your main line. - Full implementation & integration — telephony, calendar and CRM wired up, with live transfer to your team. - Compliance & guardrails — AI disclosure, consent and recording handled properly, every call transcribed and logged. - Tuning & monitoring — transcripts reviewed, resolution measured, flows improved week on week. - Natural voice, on brand — paired with ElevenLabs where voice quality matters. ### Where we put it to work Inbound call handling, outbound follow-up, qualification and intake, after-hours coverage, reminders and rescheduling, and call summaries logged into your CRM. ## Implement ElevenLabs URL: https://www.sparkconsulting.tech/tools/elevenlabs How Spark implements ElevenLabs — natural, on-brand AI voice for call agents and produced audio, with cost controls and clear AI disclosure built in. ### What it is ElevenLabs is a platform for generating natural, high-quality AI voices, used both in live voice agents and for produced audio content. ### How we help you implement it Where voice quality matters, we use ElevenLabs and build it into the workflow around it — usually paired with Vapi for live calls or an automated pipeline for content — with consistent on-brand voices, cost controls and clear AI disclosure. ### Where we put it to work Three ways it earns its place. - Natural voice for agents — a voice that sounds human and on-brand. - Produced audio content — turning written content into polished audio at volume. - Multilingual voice — reaching clients in more than one language. ## What is AI automation? URL: https://www.sparkconsulting.tech/what-is-ai-automation A plain-English guide to AI automation for professional services firms: what it is, what it isn't, where it creates value, and how to start — without the hype. ### In plain terms AI automation is two things working together: automation is the deterministic plumbing that moves data and runs repeatable steps; AI is the judgement layer that reads documents, drafts work and reasons over messy inputs. Together they let a firm automate most of the assembly, reading and drafting in a process, with people reviewing and approving the output. ### What it is In practice, AI automation means: - Connecting the systems you already run so data moves without re-keying. - AI reading documents and drafting first-pass work for a human to check. - Repeatable checks and assembly on a schedule, with an audit trail. - People kept in control of anything that carries risk or judgement. ### What it isn't It is not: - A single tool you buy and switch on. - Replacing your team or your systems wholesale. - A demo that impresses but never survives real cases. - Removing humans from regulated decisions. ### Where it creates value Onboarding, document-heavy drafting, reconciliation and monitoring, and triage and routing are the usual highest-value areas in professional services. ### How to start Start with a plan, not a tool. A short Roadmap decides what's worth automating; the ROI calculator gives a rough sense of the prize. ## Sectors URL: https://www.sparkconsulting.tech/sectors Spark builds AI and automation systems for regulated, document-heavy professional services firms — trust and corporate services, fund administration and beyond. ### Where we go deep We build dedicated playbooks for the sectors we know best. - Trust & corporate services — KYC, client take-on, transaction monitoring, periodic reviews. - Fund administration — investor onboarding, NAV, capital calls, investor reporting. ### We also work across Wealth & private client, legal & professional services, compliance & risk, and insurance & re-insurance. ## Trust & corporate services URL: https://www.sparkconsulting.tech/sectors/trust-corporate-services AI and automation for trust and corporate services firms — automate KYC, client take-on, transaction monitoring and periodic reviews, with full audit trails. ### The problem Trust and corporate services administrators lose their week to chasing KYC documents, re-keying data, assembling review files and preparing four-eyes checks — high-volume, high-scrutiny, rarely billable work that AI and automation are well suited to, provided every step stays auditable. ### Where automation helps Four places we take real work off the desk. - Client take-on and KYC / CDD — collect and read documents, extract data, screen, and draft a risk assessment for review. - Transaction monitoring and payment review — check instructions against mandates, flag anomalies, and assemble the evidence pack. - Periodic and trigger-event reviews — pull the file together and draft a review pack ready for sign-off. - Minutes, resolutions and board packs — draft from meeting notes in your house style. ### Governance Every engagement is covered by NDA, data is segregated by client, and every automated step is logged so you can evidence it to a regulator or auditor. A human signs off where it matters. ## Fund administration URL: https://www.sparkconsulting.tech/sectors/fund-administration AI and automation for fund administrators — automate investor onboarding, NAV reconciliation, capital calls and investor reporting, with full audit trails. ### The problem Every reporting cycle, fund administration teams gather the same data, reconcile it, chase exceptions and assemble the same investor documents under deadline pressure. The volume scales with assets under administration; headcount can't keep up. Most of it is structured, repeatable work — the natural home for automation. ### Where automation helps Four places we take real work off the desk. - Investor onboarding and AML — read subscription documents, screen, and draft the onboarding record. - NAV preparation and reconciliation — gather prices and positions, reconcile, and surface only the exceptions. - Capital calls and distributions — generate and personalise notices from the underlying calculations. - Investor and regulatory reporting — assemble reports and returns from source data, drafted into your templates. ### Governance Every engagement is covered by NDA, data is segregated by client, and every automated step is logged for audit. A human reviews and approves the output. ## Writing ### The JFSC's AI guidance: what it actually means for your firm URL: https://www.sparkconsulting.tech/blog/jfsc-ai-guidance-what-it-means Published: 2026-07-13 · Author: Seb Lawson · Governance & compliance The headline is simple. The JFSC is not going to stop you using AI. It is going to ask who signed it off, whether you can explain what it does, and what happens when it gets something wrong. If you can answer those three questions on any given system, you are most of the way there. The Commission set out its position in AI in financial services: enabling innovation with confidence, and it sits inside a wider 2026 to 2030 strategy that pairs strong regulation with a deliberately business-friendly stance. The tone is pragmatic. AI is already reshaping how firms operate, Jersey competes internationally for the same work, and the regulator would rather help firms adopt it well than watch them either freeze or wing it. It is principles-based rather than a prescriptive rulebook, which is good news and a trap at the same time. Good, because it is proportionate. A trap, because principles put the thinking back on you. ## The four things it expects Strip out the framing and the guidance leans on four ideas that recur across the Commission's public statements and the broader work of the Jersey AI Council. 1. Governance and accountability. Someone senior owns the AI, by name. The board understands what is running, why, and what it could get wrong. This is not a committee you convene once. It is a standing line of responsibility. 2. AI-literate leadership. The people accountable actually understand the technology's limits. You cannot govern what you do not understand, and 'the vendor said it was fine' is not a control. 3. Explainability. You can describe, in plain terms, how a system reaches an output and why. Large language models return the most likely answer given the input, not the same answer every time, so consistency and traceability have to be engineered in rather than assumed. 4. Meaningful human oversight. A person can review, override, and stop the system, and that oversight is real rather than a tick-box. The level of oversight should scale with how much damage the use case could do. None of this is exotic. If you run a regulated firm, you already apply the same logic to outsourcing, to your AML framework, and to any material third-party dependency. AI is a new object inside an old discipline. ## Proportionate is the operative word The guidance does not treat every use of AI the same, and neither should you. A model that drafts an internal file note is not the model that decides whether to onboard a client. The oversight, testing, and documentation you put around a system should track the harm it could cause if it fails. A useful test: sort every AI use case into three buckets. Low stakes, where a wrong output is an inconvenience. Medium, where a human catches it before it matters. High, where a wrong output reaches a client, a regulator, or a payment. Most firms find 80 percent of their genuinely useful cases sit in the first two buckets, which is exactly where you should start. ## What this does not mean It does not mean you need an AI policy the length of your AML handbook before you switch anything on. It does not mean every tool needs a bespoke risk assessment signed in triplicate. And it does not mean waiting. The Commission has been explicit that it welcomes early conversations and would rather engage with firms that are moving thoughtfully than reward those sitting on their hands. Standing still is its own risk, and it is not the one the guidance is worried about. ## Four moves worth making in the next 90 days 1. Name an owner. Put one senior person's name against AI adoption. Not IT alone, not a working group. A person with a seat at the table. 2. Build an AI register. A single list of every AI tool in use, what it does, what data it touches, and which risk bucket it sits in. Most firms are surprised by what is already running once they look. A first pass takes about a day. 3. Write one page, not fifty. A short AI use policy that says what is allowed, what needs sign-off, and what is off limits. One page people read beats fifty nobody opens. 4. Make oversight and audit real on your highest-stakes case. Pick the one use case that could actually hurt if it failed, and build the human checkpoint and the audit trail properly. Prove the pattern once, then reuse it. We wrote separately about building an AI audit trail and about what human-in-the-loop actually requires, because those two are where firms most often wave their hands. Both are worth getting right before a supervisor asks. ## How we read it This guidance rewards firms that treat AI as an operational discipline rather than a science project. That is the whole of our approach. We scope the smallest painful workflow, build it so the audit trail exists from day one, log every change, and keep a human in the loop where it counts. The regulator nods rather than flinches, because the governance was not bolted on at the end. If you want a grounded view of your own position, our AI governance work for Channel Islands firms covers the framework in more depth, and a discovery call will get you a candid read on where you actually stand. No deck, no hype. Just what to fix first and what it is worth. One caveat, stated plainly. Regulatory guidance evolves, and the exact wording and scope of what the JFSC publishes may move. Treat this as our interpretation of the Commission's stated direction, not as legal advice, and check the primary source before you rely on any specific point. ### Where to start with AI: pick the smallest painful workflow first URL: https://www.sparkconsulting.tech/blog/where-to-start-with-ai Published: 2026-07-06 · Author: Seb Lawson · Adoption & strategy Start with the smallest painful workflow you can name. Not the biggest opportunity, not the flashiest demo, not the thing a vendor put in front of you. The narrow, repetitive, annoying task that a specific person does every week and quietly resents. That is where AI earns its keep, and it is where you learn what your firm can actually absorb. Most firms get this backwards. They open with a strategy workshop, a long list of possibilities, and a plan to transform three departments at once. Six months later there is a deck and no working system. The firms that get value do the opposite. They ship one small thing, measure it, and use what they learn to pick the next one. Momentum beats ambition every time. ## Why smallest and most painful wins Small means you can finish it. A workflow you can describe in two sentences is a workflow you can build, test, and put a human check around in weeks rather than quarters. Painful means someone will actually use it, because they already feel the cost of doing it by hand. Pick something nobody minds doing and adoption dies on contact. Pick something that ruins a Tuesday afternoon every week and people will pull it into their work without being asked. There is a risk argument too. A small, well-chosen first workflow keeps you in the low and medium stakes buckets, where a wrong output is an inconvenience or gets caught by a human before it matters. You get to learn the discipline, the audit trail, the sign-off, the prompt versioning, on something that cannot hurt a client, a payment, or a regulatory return. We wrote about that risk tiering in our AI governance framework. ## How to find it Do not run a survey. Sit with the two or three people who do the most repetitive work and ask one question: what do you do every week that feels like it should not need a person. Then look for the four markers of a good first candidate. - High frequency. It happens daily or weekly, not twice a year. Frequency is what turns small time savings into real numbers. - Rules you can write down. The task follows a pattern a competent new joiner could learn in a morning. If the logic lives only in one person's head and changes every time, it is not your first case. - Structured or semi-structured inputs. Documents, emails, spreadsheets, forms. Messy is fine. Genuinely unpredictable is not. - A tolerable failure mode. If the system gets one in twenty wrong, a human catches it and the cost is small. That is a starting point. If one wrong output reaches a client unchecked, that is a later case, not a first one. In regulated firms the same handful of workflows come up again and again. Client take-on and KYC document gathering. Extracting figures from statements and reports. First-draft file notes and letters. Investor and NAV reporting packs. Triaging a shared inbox. None of these are exotic. All of them are painful, frequent, and rule-bound, which is exactly the point. ## Put a number on it before you build A workflow is only worth automating if you can say what it is worth. Before any build, write the number down. Take the hours the task consumes each week, multiply by the loaded cost of the person doing it, and annualise. A task that eats six hours a week of a person on a fifty pound loaded hourly rate is costing you the better part of sixteen thousand pounds a year, and that is before you count the errors and the delay. If you cannot put a number on the outcome, it is not the right first workflow. We keep a simple ROI calculator and a fuller method in how to measure AI ROI. ## One workflow, not ten The discipline is to resist the second idea until the first one is live and measured. Ship one workflow. Watch it run for a fortnight. Confirm the hours it saved and the errors it removed. Only then pick the next, and let the pattern you proved carry over: the same audit trail, the same human checkpoint, the same way of versioning prompts. This is how a firm builds capability instead of a graveyard of pilots. It is also why so many pilots never reach production, which we covered in why AI pilots fail. ## What good looks like in six weeks A first workflow scoped, built, and running in production inside four to six weeks, with a named owner, a human sign-off where it counts, and a changelog from day one. That is the shape of our AI and automation roadmap, which starts from £15k and is built precisely so the first thing you ship is the smallest painful workflow rather than the biggest slide. If you want a candid read on which workflow to start with, book a discovery call. We will look at your week, find the task that hurts most and risks least, and tell you what it is worth to fix. No deck, no hype. Just the first move worth making. ### RAG explained: how retrieval makes business AI reliable URL: https://www.sparkconsulting.tech/blog/rag-explained Published: 2026-06-25 · Author: Seb Lawson · Technology, explained RAG is how you stop an AI making things up. A general-purpose model like Claude or GPT knows a great deal about the world and nothing at all about your firm. Ask it about your onboarding policy and it will guess, confidently, because guessing is what these models do when they have no source. Retrieval-augmented generation closes that gap. It finds the relevant passages from your own documents and hands them to the model at the moment of the question, so the answer is built from your material rather than the model's memory. That one change is the difference between a party trick and a tool a regulated firm can put in front of staff. ## What the letters actually mean Retrieval-augmented generation is three steps in a trench coat. Retrieval: search your documents for the passages most relevant to the question. Augmented: paste those passages into the prompt alongside the question. Generation: let the model write an answer using that supplied context. The model still does the writing. What changes is that it is now writing from evidence you chose, not from a hazy statistical recollection of the entire internet. The retrieval step usually leans on something called a vector search. Your documents are chopped into chunks, each chunk is turned into a list of numbers that captures its meaning, and the same is done to the question. The system then finds the chunks whose meaning sits closest to the question, even when the wording is different. Ask about 'proof of address' and it will surface the paragraph about 'residential verification documents' without you having to match the exact phrase. That is the part keyword search never managed. ## Why it reduces hallucination A model hallucinates when it is asked for something it does not know and has no way to say so. Left to its own devices it produces the most plausible-sounding answer, which is often wrong in ways that read perfectly. RAG removes the vacuum. Instead of 'what do you know about our fee policy', the model is effectively asked 'here are the three relevant paragraphs from our fee policy, now answer'. The scope narrows, the source is present, and a well-instructed system will say 'that is not covered in the documents provided' rather than invent. You never get to zero. You get from unacceptable to manageable, and for most business work that is the whole game. ## Why citations matter more than the answer The quiet superpower of RAG is that it can show its working. Because the answer was built from specific retrieved passages, the system can tell you which document and which section each claim came from. For a regulated firm that is not a nice-to-have. It is the difference between an output a supervisor can inspect and a black box nobody can defend. A staff member reading a RAG answer can click through to the source clause and confirm it in seconds, which means the human check stays real rather than becoming a rubber stamp. We think citations should be non-negotiable in any system that touches client work, and we build them in from day one. ## When your firm actually needs it You need RAG when the right answer lives in your own material and changes over time: policies, procedures, contracts, past correspondence, a knowledge base, a filing cabinet of PDFs. The classic cases in our world are a staff assistant that answers 'how do we handle this' from the firm's own procedures, a tool that pulls the relevant clauses out of a long agreement, or a search layer over years of client files. If the useful knowledge is yours and specific, RAG is usually the honest answer. You do not need it for everything. Summarising a document you have already pasted in needs no retrieval, because the source is right there. Drafting from a template, translating, reformatting, tone-fixing: none of these are RAG problems. And RAG is not a substitute for structured data. If the question is 'what is the NAV', that belongs in a database query, not a document search. Reaching for RAG when a simple lookup would do is a common and expensive mistake. ## Where it goes wrong RAG is only as good as what it retrieves. Feed it messy, duplicated, out-of-date documents and it will faithfully ground its answers in your mess. Garbage in, confidently cited garbage out. The unglamorous work is in the retrieval: chunking documents sensibly, keeping the source current, and testing that the right passages actually surface for real questions. Most RAG projects that disappoint were under-built on that side and over-built on the chatbot. A related discipline is getting clean data out of the documents in the first place, which we cover in AI document extraction. ## How we build it We treat RAG as plumbing, not magic. Scope the smallest set of documents that answers a real, repeated question. Get retrieval accurate before worrying about the wording of answers. Insist on citations. Keep a human in the loop wherever the output could reach a client or a regulator. Models such as Claude handle the generation step well because they follow the instruction to stay inside the supplied sources and to admit when something is not there, which is exactly the behaviour you want in regulated work. If you have a shelf of documents that staff keep asking about, that is a RAG-shaped problem and a good first build. A Roadmap from £15k over four to six weeks will tell you whether it is worth doing and what it is worth, or book a discovery call for a candid read on where retrieval would earn its keep and where a simpler tool would do the job. ### AI governance for Channel Islands firms: getting ahead of the JFSC URL: https://www.sparkconsulting.tech/blog/ai-governance-jersey-jfsc Published: 2026-06-18 · Author: Seb Lawson · Governance & compliance Most AI governance fails in the same way. A firm writes a long policy, files it, and changes nothing about how work is actually done. The policy is for the auditor. The work is for everyone else. A regulator can tell the difference in about ten minutes, and so can your team. Governance that holds up is smaller and more boring than that. It is a handful of controls that are visible, owned, and used every day. The JFSC's principles-based approach rewards exactly this: not the thickest binder, but the clearest line of responsibility. Here is the framework we put in place, and roughly what each part costs to stand up. ## 1. A named owner and a real mandate One senior person owns AI adoption, by name, with a seat at the table and the authority to stop a system going live. Not the IT team on its own. Not a committee that meets quarterly. When something goes wrong, the regulator will ask who decided, and 'the working group' is not an answer. This costs nothing but a decision, and it is the single highest-leverage control you have. ## 2. An AI register A single, current list of every AI system in use: what it does, what data it touches, who owns it, and how much damage it could do if it failed. Most firms discover more shadow AI than they expected once they look, because staff have quietly adopted tools that were never assessed. A first version takes about a day to build and immediately tells you where the risk actually sits. ## 3. Risk tiering, so effort tracks harm Sort each use case into low, medium, or high stakes by what a wrong output could reach. A drafted internal note is low. A client-facing letter with a human check is medium. Anything that touches onboarding decisions, a payment, or a regulatory return is high. The controls, testing, and documentation scale with the tier. This is what proportionate means in practice, and it stops you spending high-stakes effort on low-stakes tools. ## 4. Human oversight where it counts For every high-stakes case, a person reviews and can override the output before it takes effect, and that review is genuine rather than a rubber stamp. We covered the difference in detail in human-in-the-loop AI. The short version: if the human cannot realistically catch an error in the time they are given, you do not have oversight, you have theatre. ## 5. An audit trail by default Every material AI decision leaves a record: the input, the model and prompt version, the output, and who approved it. Built in from the start this is nearly free. Retrofitted after a supervisor asks, it is painful and sometimes impossible. Our piece on building an AI audit trail sets out exactly what to capture. ## 6. A one-page policy people read What is allowed, what needs sign-off, what is off limits, and who to ask. One page. The fifty-page version exists to protect the firm on paper. The one-page version actually changes behaviour, which is the only thing that protects you in reality. ## What this looks like on a timeline A firm of 20 to 250 people can stand up the whole framework in four to six weeks without pausing any live work. Week one, name the owner and draft the register. Weeks two and three, tier the use cases and write the one-page policy. Weeks four to six, make oversight and audit real on the two or three highest-stakes systems. After that it is maintenance, not a project. This is the spine of our AI and automation roadmap, and it is why the systems we build for trust and corporate services and fund administration firms tend to survive contact with a regulator. Governance is not the tax you pay for using AI. Done early, it is the thing that lets you use it at all. If you want a candid read on where your firm stands, book a discovery call. ### AI for KYC and client take-on in trust and corporate services URL: https://www.sparkconsulting.tech/blog/ai-for-kyc-client-take-on Published: 2026-06-11 · Author: Seb Lawson · Sector playbooks Client take-on is the slowest, least billable stretch of a trust administrator's month, and it is the one AI shortens most. Collect the documents, read them, extract the data points, run the screening, draft the risk assessment: almost all of it is structured, repeatable work sitting behind a human decision. Automate the assembly and the drafting, keep the judgement and the sign-off with a person, and a take-on that used to run over days lands in hours. In our experience the manual effort on a standard onboarding drops by 60 to 70 percent, and the wait is measured in hours rather than a fortnight of chasing. This is the workflow we build most often for trust and corporate services firms, because the pain is universal and the shape of the fix is well understood. Here is how it breaks down, and where the human has to stay. ## Document collection stops being a chase Most take-on delay is not analysis. It is waiting. Waiting for a passport, a proof of address, a structure chart, a source-of-funds explanation that never arrives in one go. An automation can send the request list, track what has come back, read each document on arrival, and chase the gaps on a schedule without an administrator holding the whole thing in their head. The system knows what a complete file looks like and tells you exactly what is still missing. That single change, turning a manual chase into a tracked queue, often recovers more time than the clever extraction that follows. ## Extraction and verification, checked not trusted Once a document arrives, AI reads it and pulls out the fields your onboarding system needs: names, dates, addresses, ownership percentages, the shape of the structure. This is the same document extraction engine that powers the rest of the back office, tuned to the forms you actually receive. The important word is verification. The model proposes; it does not decide. Where a passport photo is unreadable or an address does not match, the case is flagged rather than guessed. High-confidence fields flow through, low-confidence fields wait for a human. Getting that threshold right is most of the work, and it is why we test against your own historic files before anything goes live. ## Screening and risk-scoring, assembled for a reviewer Screening against sanctions, PEP and adverse-media lists is already largely automated in most firms. The value AI adds is upstream and downstream: pulling the right names and entities out of the structure so nothing is screened by hand, and then assembling the hits into an evidence pack a reviewer can actually work through. Instead of a raw list of 40 possible matches, the reviewer sees each one summarised, ranked by relevance, with the underlying source one click away. A first-pass risk assessment gets drafted from the same inputs, in your house rating logic, ready for a human to accept, adjust or reject. The draft is a starting point, never the verdict. ## The decision stays human, and that is the point Nothing here approves a client. The system does the collection, the reading, the screening and the drafting; a named person makes the call. This is not a compliance nicety, it is the design. The JFSC expects meaningful human oversight that scales with how much damage a use case could do, and onboarding a client is about as high-stakes as it gets. So the human checkpoint is real: the reviewer sees the evidence, can override any machine output, and signs the decision themselves. If a wrong output could reach a regulator or open the door to dirty money, a person stands between the model and the outcome. ## The audit trail is there from the first click Every take-on leaves a complete record: which documents came in and when, what the model extracted, what it flagged, which screening ran against which lists, the draft risk assessment, and who approved the final decision, with the prompt and model version logged alongside. Built in from the start this is nearly free. Bolted on after a supervisor asks, it is painful and often impossible to reconstruct. We covered exactly what to capture in building an AI audit trail. For a regulated firm this is the difference between a system a supervisor nods at and one that gets you a finding. ## Periodic reviews reuse the same machine The best part is that take-on and periodic review are the same workflow pointed at different moments. Once the collection, extraction, screening and drafting are built for onboarding, a trigger-event or scheduled review reuses all of it: refresh the documents, re-run the screening, pull out what has changed since last time, and draft the review pack ready for sign-off ahead of the deadline. Firms that dread the periodic review backlog find it stops being a backlog. The pack assembles itself; the administrator reviews and approves. Build once, use twice. ## What it takes to stand up A working take-on assistant on one client type is a Build Sprint, typically 8 to 12 weeks from a fixed price of £40k, and it is worth scoping the whole thing in a Roadmap first so you automate the right client type in the right order. Start narrow. Pick your highest-volume, most painful onboarding flow, prove the pattern with the audit trail and the human checkpoint working properly, then extend it to the next structure and to periodic reviews. That is how the numbers land and how the regulator stays comfortable. If client take-on is eating your team's week, a discovery call will get you a candid read on which part to automate first and what it is worth. No deck, no hype. Just the smallest painful workflow and a number against it. ### How to measure ROI on AI automation, with a worked example URL: https://www.sparkconsulting.tech/blog/how-to-measure-ai-roi Published: 2026-06-02 · Author: Seb Lawson · Adoption & strategy AI ROI is simpler than the market wants you to believe. Three things move the number: hours saved, errors removed, and capacity freed. Put a figure on each, subtract what the system costs to build and run, and you have your answer. If you cannot do that sum for a given workflow, you are not ready to build it yet. The reason ROI feels slippery is that most firms measure the wrong thing. They count licences and forget loaded cost. They count the demo and forget the run rate. They talk about time saved but never actually time the task before and after. Measure properly and the picture is usually clear within the first month of a workflow going live. ## The three levers Every credible AI business case pulls on at least one of these. The best pull on all three. - Hours saved. The time a task took by hand, minus the time it takes with the system and its human check, multiplied by the loaded hourly cost of the person doing it. Loaded cost, not salary. Salary plus employer costs, plus overhead, is usually 1.3 to 1.5 times the headline figure. - Errors removed. The cost of the mistakes the old process made: rework, corrections, an apology to a client, in the worst case a breach to report. Harder to price precisely, but real. Estimate a per-error cost and a rate, and be conservative. - Capacity freed. The work your team can now take on without hiring, or the growth you can absorb without adding headcount. This is often the largest number and the one firms forget, because it does not show up as a cost line, it shows up as a hire you did not make. ## The formula Annual benefit is hours saved per year times loaded hourly cost, plus errors removed per year times cost per error, plus the value of any capacity freed. Annual cost is the build cost amortised over its useful life, plus the running cost: model usage, tooling, and the maintenance the system needs to stay honest. Net benefit is the first minus the second. Payback is the build cost divided by the monthly net benefit. Keep it that plain. ## A worked example Take a trust and corporate services team drowning in client take-on. Gathering and checking KYC documents for new entities takes an administrator about eight hours per case, and the team onboards roughly ten cases a month. That is 80 hours a month, or 960 hours a year, on one workflow. Build an assisted pipeline: documents extracted and checked against a checklist automatically, gaps flagged, a first-pass summary drafted, and a human reviewing and signing off every case. In our experience this kind of workflow takes the eight hours per case down to about three, because the person is now checking and approving rather than gathering and typing. Call it five hours saved per case, fifty hours a month, 600 hours a year. Now the maths. At a loaded cost of £45 an hour, 600 hours saved is £27,000 a year. The old process missed a required document or logged something wrong on maybe one case in ten, each costing a few hours of rework and the occasional awkward client email; call that conservatively £4,000 a year avoided. And the freed capacity lets the team take on more onboarding without a new hire, which was the actual bottleneck. Ignore that entirely and you are still at £31,000 a year of hard benefit. Against that, a build of this shape sits in the region of £40k as a Build Sprint, plus running costs of a few hundred pounds a month for model usage and tooling. Amortise the build over three years and add the run rate, and net benefit lands comfortably in five figures a year, with payback inside the first eighteen months and often sooner once freed capacity is counted. That is the pattern behind our KYC and client take-on work. ## The mistakes that flatter or wreck the number Two errors show up constantly. The first is counting time saved that nobody actually recovers, because the freed hours just evaporate into slack rather than into more work or fewer hours. If you cannot say where the saved time goes, discount it. The second is forgetting the human check in the cost. Oversight takes time, and a business case that assumes zero review is measuring a system you should not run. Price the checkpoint in. It is cheaper than the alternative. ## Measure it after, not just before A business case is a forecast. The number that matters is the one you confirm a month after go-live, by timing the task again and counting the errors again. Build the measurement in from day one: log every run, every human override, every correction. That same log is your audit trail, which is why we treat measurement and governance as the same job, covered in building an AI audit trail. If you want to sketch your own number in five minutes, use the ROI calculator. If you want it built and proven, a Build Sprint from £40k ships the workflow and the measurement together. And if you would rather just talk it through, book a discovery call and we will put a real number on your most painful workflow. ### Agents, chatbots and automations: what the difference actually is URL: https://www.sparkconsulting.tech/blog/ai-agents-chatbots-automations Published: 2026-05-27 · Author: Seb Lawson · Technology, explained These three words are not interchangeable, and treating them as if they are is how firms overspend. A chatbot talks to a person. An automation runs a fixed sequence of steps without anyone asking it to. An agent decides what to do next by itself. Different shapes, different costs, different risks. The expensive, fashionable option is the agent, and most of the value in a professional services firm sits in the boring automation nobody is tweeting about. Get the category right and the project usually works. Get it wrong and you have bought a self-driving car to fetch the post. ## A chatbot: it answers A chatbot is a conversation. A person asks something in plain language, the system replies. That is the whole of it. The good ones are grounded in your own documents so the answers are accurate and can be traced back to a source, which is the retrieval approach we cover in RAG explained. The weak ones are grounded in nothing and will happily invent a policy that does not exist. Chatbots fit where a human needs an answer from a body of knowledge: an internal assistant over your procedures, a client-facing helper on your website, a search layer over years of files. What a chatbot does not do is act. It tells you the fee is due. It does not raise the invoice. The moment you want something to happen in the real world, you have left chatbot territory. ## An automation: it runs An automation is a fixed path that runs on a trigger. When an email lands, extract the attachment, pull out the key fields, drop them into the system, flag anything odd for a human. Every step is defined in advance. It does the same thing the same way every time, which is precisely what makes it trustworthy and cheap to run. There is often AI inside an automation, doing the one clever step a rules engine cannot, like reading a scanned document. But the path around that step is fixed and predictable. This is where most of the real return lives. The repetitive, rules-bound, high-volume back-office work that eats your team's week is almost always an automation problem. It is unglamorous, it is measurable, and it pays back fast. If you only ever do one AI thing, it should probably be this. We wrote a fuller primer in what AI automation actually is. ## An agent: it decides An agent is given a goal and works out the steps itself. Instead of a fixed path, it has a set of tools and the freedom to choose which to use, in what order, until the goal is met. 'Research this counterparty and draft a summary' might have the agent search, read, cross-check, and write, deciding each move as it goes. When the task genuinely varies every time and cannot be reduced to a fixed sequence, that flexibility is the point. That same flexibility is the risk. An agent that chooses its own path can choose a wrong one, and the more it can do without asking, the more damage a wrong choice makes. In regulated work that is a live concern, not a hypothetical. Agents are the right tool for genuinely open-ended tasks. They are the wrong tool for a process you could have written down as steps, which, honestly, is most processes. The industry is selling agents hard right now. Be sceptical when the job on the table has a fixed shape. ## How to tell which you need Ask two questions. First, does a human need to have a conversation, or does something need to happen? Conversation points to a chatbot. Something happening points to automation or an agent. Second, is the path the same every time, or does it genuinely differ? Same path is an automation. Genuinely different every time is an agent. Most firms discover their pressing problems are chatbots and automations, and that the agent can wait until those are earning. - Chatbot when a person needs a grounded, traceable answer from your knowledge. - Automation when a defined process runs the same way on a trigger, with a human checking the exceptions. - Agent when the task is genuinely open-ended and the steps cannot be fixed in advance, and you have built the oversight to match. ## Why the label matters commercially Because it sets the cost, the risk and the governance. An automation with a human checking exceptions is cheap to run, easy to audit, and easy to explain to a regulator. An agent making its own decisions needs far more oversight, testing and change control before it goes near client work, and it should. Buying the agent for a job the automation does better is the single most common way we see AI budgets wasted. The related question of building it yourself, buying it, or wiring together no-code tools is covered in build, buy or no-code. If you are not sure which of the three your problem is, that is the useful first conversation, and it usually takes an hour. A Roadmap from £15k will sort your ideas into the right category and put a number on each. Or book a discovery call and we will tell you plainly whether you need the clever thing or the boring one. Usually the boring one, and usually that is good news. ### Automating NAV and investor reporting in fund administration URL: https://www.sparkconsulting.tech/blog/automating-nav-investor-reporting-fund-administration Published: 2026-05-20 · Author: Seb Lawson · Sector playbooks The NAV cycle is a deadline machine, and most of what your team does inside it is assembly. Gather prices and positions from the same places, reconcile them, chase the exceptions, then draft the same investor documents under the same monthly or quarterly pressure. Automate the assembly and the reconciliation, let AI handle the messy documents and the first drafts, and surface only the exceptions that need a person. Done well, the manual effort on a reporting cycle drops by half or more, and the late nights at period end stop being the norm. The numbers still get checked and signed by a human. That never changes. This is the core of the work we build for fund administrators, and it splits cleanly into three jobs: get the data right, reconcile it, then draft from it. Here is each one, and where the human stays in the loop. ## Data validation before anything else A NAV is only as good as the data feeding it, and the data arrives in a mess: custodian statements as PDFs, price files in three formats, a manager's spreadsheet with a column moved since last month. The first win is turning all of that into clean, structured data automatically, which is the same document extraction problem the whole back office shares. Prices, positions, cash movements and corporate actions get read, normalised and validated against expectations before they touch the NAV. A price that has moved 40 percent overnight or a position that appeared from nowhere gets flagged at the door, not discovered three steps later when it is far more expensive to unpick. ## Reconciliation that surfaces only the exceptions Reconciliation is where administrators lose their evenings, and it is the most automatable step in the whole cycle. Matching positions and cash across custodians, the accounting system and the manager's records is rule-based work at heart. Automation runs the match, applies your tolerances, and presents only what breaks: the handful of genuine exceptions, each one with the two sides laid side by side and a plausible explanation drafted. Instead of an analyst working through a thousand matched lines to find the five that do not, they open a queue of five. The tedious 95 percent runs itself; the human attention goes where the judgement actually is. ## Drafting investor reports and capital call notices Once the numbers are locked, the documents write themselves from source, into your templates. Quarterly investor reports, capital call notices, distribution notices and regulatory returns are all structured outputs built from data you already hold. AI drafts each one, personalised per investor, with the figures pulled straight from the validated model rather than re-keyed. A capital call that took an afternoon of copy-paste per investor becomes a batch generated in minutes and reviewed as a set. The commentary in an investor report can be drafted too, in your house tone, for the fund controller to edit rather than write from a blank page. Drafting is the machine's job. Sign-off is not. ## The checks are the whole point None of this releases a NAV or sends an investor notice on its own. Every number the automation produces is checked against your model, and every document waits for a human to review and approve before it goes out. This is not caution for its own sake. Getting a capital call amount wrong or publishing a NAV with a stale price is the kind of failure that reaches investors and regulators, which puts it squarely in the high-stakes tier where meaningful human oversight is not optional. The reviewer sees the exceptions, the drafts and the underlying figures, can override anything, and signs the release themselves. The automation removes the assembly, not the accountability. ## An audit trail the depositary can inspect Every cycle leaves a complete, inspectable record: which data came in from where, what was flagged and why, how each exception was resolved and by whom, and who approved the final NAV and each investor document, with the prompt and model version logged. For a regulated fund administrator, and for the depositary and auditors sitting behind you, that trail is not a nice-to-have. Build it in from day one and it is nearly free. Retrofit it after a query and it is painful, sometimes impossible. It is the difference between a fast cycle you can defend and a fast cycle you cannot. ## Where to start Do not try to automate the whole cycle at once. Pick the single most painful step, usually the reconciliation or the investor report drafting, and prove the pattern there with the checks and the audit trail working properly. A working system on one fund type is typically a Build Sprint, 8 to 12 weeks from a fixed £40k, and it pays to scope the sequence in a Roadmap first so you build in the order that returns the most soonest. Prove it once, then roll it across fund types and across the cycle. If your reporting cycle runs on late nights and manual assembly, a discovery call will get you a straight read on which step to automate first and what it is worth in hours recovered per cycle. No deck. Just the number. ### Building an AI audit trail: how regulated firms keep AI decisions defensible URL: https://www.sparkconsulting.tech/blog/building-an-ai-audit-trail Published: 2026-05-12 · Author: Seb Lawson · Governance & compliance An AI audit trail is five fields and a habit. For every material decision a system helps make, you record the input it received, the model and prompt version that produced the output, the output itself, who approved it, and when. Capture those from the first day a system goes live and you can defend any decision it touched. Skip them, and you are reconstructing history you no longer have. This is the single control regulated firms most often wave their hands at. Everyone agrees they should be able to explain an AI output. Far fewer have wired up the plumbing that makes it possible after the fact. The gap only shows when a client complains, a supervisor asks, or a decision goes wrong, which is exactly the moment you cannot afford to shrug. ## The five things to capture Keep the record boring and complete. If you can reconstruct what happened without asking a person to remember, you have enough. 1. The input. What actually went into the model: the document, the client data, the query, the context retrieved. Not a paraphrase. The real thing, or a stable reference to it. 2. The model and prompt version. Which model, which version, and which prompt. A prompt is code. When it changes, the behaviour changes, and you need to know which version produced which output. We wrote about why in prompt versioning. 3. The output. What the system returned, verbatim, before any human edited it. The edited final version matters too, but the raw output is what proves what the model did. 4. The approver. Who reviewed it, who signed it off, and whether they changed anything. A name, not a role. 'Reviewed by compliance' is not an approver. 5. The timestamp. When each step happened. Input received, output generated, human approved. Order and timing are half the story when something is contested. That is the whole schema. Five fields, logged automatically, on every decision that could reach a client, a payment, or a regulatory return. Low-stakes uses, like a first draft of an internal note, do not need the full treatment. Match the record to the risk, the same way the JFSC's guidance expects effort to track harm. ## Why retrofitting is painful Built in from the start, an audit trail is nearly free. The system writes each field as it works, and nobody has to remember anything. Bolted on after a supervisor asks, it is expensive and sometimes impossible. You cannot log a prompt version you never recorded. You cannot recover the input if it was overwritten. You cannot prove who approved something when the system never asked for a name. In our experience most firms that skip this end up rebuilding the workflow anyway, usually under time pressure, and often after the exact incident the trail would have explained. Two weeks of clean logging design at the start saves a scramble later. That is the trade, and it is not close. > You cannot log a prompt version you never recorded. Build the trail before you need it, because you will need it on the day you least expect. ## What a supervisor actually wants to see A regulator is not trying to catch you using AI. They are trying to establish whether you are in control of it. When they ask about a specific decision, they want a short, honest answer to three questions. What did the system do? Who checked it? And what would have happened if it got it wrong? A clean audit trail answers all three in minutes. What unsettles a supervisor is not a mistake. Firms make mistakes. It is the inability to explain one. A firm that can pull the input, show the prompt version, point to the human who approved it, and demonstrate the checkpoint that would have caught an error, looks like a firm in control. A firm that says 'the AI did it and we are not sure how' does not. ## Make it real on one workflow first Do not try to instrument every system at once. Pick your highest-stakes AI workflow, the one that could actually hurt if it failed, and build the five-field trail properly there. Prove the pattern, then reuse it. In our work this is a fortnight of effort on a well-scoped case, and it is the part of an AI and automation roadmap that most reliably survives contact with a regulator. The audit trail is only half the control. The other half is the human doing the approving, and whether that review is genuine or theatre. We covered that in human-in-the-loop AI. Get both right on one workflow and you have a template for every AI system you build after it. If you want a candid read on whether your current AI decisions are defensible, book a discovery call. We will look at one live workflow, tell you what is missing, and put a number on what it takes to fix. No deck, no hype. Just what to capture and why. ### Build, buy or no-code: choosing the right automation approach URL: https://www.sparkconsulting.tech/blog/build-buy-or-no-code Published: 2026-05-06 · Author: Seb Lawson · Adoption & strategy There is no universally right answer to build, buy, or no-code. There is only the right answer for a specific workflow, at a specific firm, at a specific stage. Get the workflow clear first and the choice usually makes itself. Pick the approach before you understand the work and you will pay for it twice. The three options are not rivals so much as tools for different jobs. Buy an off-the-shelf product when a good one exists for a common problem. Use a no-code platform when the logic is yours but the plumbing is standard. Build custom when the workflow is core, unusual, or has to satisfy controls that a generic tool cannot. Most firms end up with a mix, and that is the correct outcome. ## When buying wins Buy when your problem is a solved problem and someone reputable has already solved it. Email security, document storage, an established KYC screening provider: you are not going to out-build a specialist, and you should not try. The trade is that you accept their roadmap, their data handling, and their limits. Read the data processing terms before you sign, especially where client data leaves the island, and check that the vendor can give you the audit evidence a supervisor will eventually ask for. If they cannot tell you how the model behaves or where the data sits, that is a reason to hesitate. ## When no-code wins No-code wins when the logic is specific to you but the building blocks are standard: move data between systems, watch an inbox, call an AI model, route the result, log it. Platforms like n8n, Make, and Zapier let you assemble that in days, not months, and change it just as fast when the process shifts. That speed is the whole point. You can ship a first version, learn from it, and iterate without a development cycle for every tweak. For regulated firms the three are not interchangeable. Zapier is the quickest to start and the most opinionated, which is fine for light, standard integrations. Make gives you more control over complex logic at a similar level of ease. n8n is the one we most often reach for when auditability and control matter, because it can be self-hosted, which keeps data where you can see it and gives you a genuine log of every run. When client data cannot leave a controlled environment, self-hosted n8n is frequently the honest answer. ## When building wins Build custom when the workflow is core to how you make money, genuinely unusual, or bound by controls no off-the-shelf tool respects. A bespoke NAV and investor reporting pipeline, an extraction workflow tuned to your document set, an agent that has to leave a specific audit trail: these are worth owning. The upside is fit and control. You decide the data handling, the human checkpoints, the logging, and the prompt versioning, and nobody can change the rules from under you. The cost is that you own it, including the maintenance. ## Total cost of ownership, honestly The sticker price is the smallest part of the decision. What actually separates the three options over three years is this. - Run rate. Buying is a predictable subscription. No-code adds platform fees plus model usage. Custom adds hosting and the model usage, but no per-seat tax as you grow. - Change cost. No-code is cheapest to change, which matters most while a process is still moving. Bought tools change only when the vendor allows it. Custom changes cost developer time but have no ceiling. - Lock-in. Bought tools lock you into a vendor. Hosted no-code locks you into a platform, though self-hosted options like n8n soften that. Custom locks you into your own codebase, which at least you control. - Auditability. This is the one regulated firms underweight. Can you show a supervisor the input, the model and prompt version, the output, and who approved it? Some bought tools cannot. Self-hosted no-code and custom builds can, if you design for it from the start. ## How we actually decide Start no-code, prove the workflow, and build custom only where the value or the controls demand it. That sequence keeps you cheap and fast while you are still learning, and reserves the expensive option for the places it genuinely pays off. A great many workflows never need to graduate from a well-built n8n flow, and pretending otherwise is how firms overspend. This is also, quietly, one of the biggest reasons pilots stall, so it is worth reading alongside why AI pilots fail. The honest version of this decision is not a spreadsheet, it is a conversation about one workflow and what it has to survive. A Roadmap from £15k makes exactly that call across your first few use cases, and picks build, buy, or no-code for each with the total cost written down. If you want that call made properly, book a discovery call and we will tell you which of the three each of your workflows actually needs. ### What MCP (Model Context Protocol) is, and why it matters for business AI URL: https://www.sparkconsulting.tech/blog/what-is-mcp-model-context-protocol Published: 2026-04-22 · Author: Seb Lawson · Technology, explained MCP is a standard plug for AI. That is the whole idea, and it is more important than it sounds. Before it, connecting a model to your systems meant building a bespoke bridge for every combination: this model to that document store, that model to your CRM, each one hand-wired and each one a maintenance headache. The Model Context Protocol replaces all of that with a single agreed socket. Build the socket once and any model that speaks the protocol can plug in. It is the difference between a drawer of proprietary chargers and a world where everything takes the same cable. ## The problem it solves An AI model on its own is a brain in a jar. It can reason about what you type, but it cannot see your files, query your database, or do anything in your systems unless you connect it. Historically every one of those connections was custom work. Ten tools and three models meant a tangle of one-off integrations, each of which broke when anything changed. It was slow to build, expensive to maintain, and it quietly chained you to whichever vendor you had wired everything to. MCP, introduced by Anthropic and now adopted well beyond it, sets a common language for these connections. You expose your tools and data through an MCP 'server', which is just a standard adapter for one system. Any model that acts as an MCP 'client' can then use it. Build the adapter for your document store once, and Claude, or any other compliant model, can read from it without further work. The tangle collapses into a set of reusable parts. ## What it actually connects Two things, mostly. Tools, meaning actions the model can take, such as searching your files, querying a database, or raising a ticket. And context, meaning information the model can read to do its job. An MCP server for your practice management system might let the model look up a matter, read the file notes, and draft a next step, all through one standard interface rather than three bespoke ones. The model still only does what you permit, and every action can be logged, which matters when a supervisor later asks what it touched. ## Why it reduces lock-in This is the part that should interest anyone running a firm. When your integrations are bespoke to one vendor's model, switching models means rebuilding everything, so in practice you never switch, and you have handed a supplier real leverage over you. When your integrations speak MCP, they are not tied to any single model. The connective tissue you paid to build stays yours. If a better or cheaper model arrives next year, you point your existing servers at it and carry on. In a field moving as fast as this one, the freedom to change your mind without a rebuild is worth real money. We think this matters enough to treat as a design principle. We build integrations to open standards wherever we can, so the value sits in your systems and your processes rather than in a dependency you cannot escape. That is not idealism. It is the same instinct any sensible firm applies to outsourcing: do not let one supplier hold the only key. ## What it is not MCP is not artificial intelligence, and it is not a product you buy. It is a protocol, a set of rules for how software talks to software, in the same family as the standards that let any browser open any website. It does not make a model cleverer. It makes a model connectable. And it does not remove the need for governance. A standard socket makes it easier to plug AI into sensitive systems, which means the questions of who approved this, what data does it touch, and who is watching it become more pressing, not less. Convenience and control have to grow together. ## Why a non-technical leader should care You will not write a line of MCP, and you should not need to. But the decisions made around it shape two things you do own: how much a future model switch costs, and how much of your AI value stays inside your firm rather than trapped in a vendor. When a supplier proposes an AI build, one good question is whether the integrations are proprietary or standards-based. The honest ones will welcome the question. The answer tells you whether you are buying an asset or renting a cage. We build with tools such as Claude precisely because they take this open approach seriously, and because it keeps your options open as the field moves. If you want a build that connects to your systems without chaining you to one vendor, that is exactly how we work. Book a discovery call and we will map what a standards-based integration would look like for your firm, and what it saves you the day you decide to switch. ### AI for law firms: document review and drafting, done safely URL: https://www.sparkconsulting.tech/blog/ai-for-law-firms-document-review-drafting Published: 2026-04-15 · Author: Seb Lawson · Sector playbooks AI is genuinely good at the two things that eat a fee earner's day: reading long documents and producing a competent first draft. A contract review that took two hours becomes a 20-minute check of a pre-marked document. A first draft that started from a blank page starts from 80 percent done. The gain is real and large. So is the risk, which is why the interesting question for a law firm is not whether AI helps but how you use it without breaking privilege, confidentiality or your professional duty. The answer is verification and a lawyer's sign-off on everything that leaves the building. Three workflows carry most of the value. Here is each, and the guardrail that makes it safe. ## Contract review, marked up not decided Point AI at a contract and it will read every clause faster than any human, flag deviations from your standard positions, spot missing provisions, and surface the unusual terms buried on page 40 that a tired reviewer skims past. Against a playbook of your firm's preferred positions it becomes a first-pass reviewer that never gets bored. The output is a marked-up document with issues ranked and explained, not a verdict. The lawyer reviews the flags, agrees or overrules each one, and owns the advice. Used this way, AI catches more and misses less, while the judgement stays exactly where professional responsibility requires it. ## First drafts from your own precedents The biggest time saving is drafting from a blank page, and the safest way to do it is to ground the model in your own precedent bank rather than the open internet. That is what retrieval-augmented generation does: the AI drafts using your firm's approved templates and prior matters as its source, so an engagement letter, a standard agreement or a first-cut advice note comes back in your house style, citing your positions, not a hallucinated clause from nowhere. The fee earner edits and finalises. This matters twice over. The draft is better because it is grounded in your work, and it is safer because the model is reasoning over documents you control instead of inventing law. ## Matter intake and conflicts, assembled for the partner New matter intake is mostly structured admin: capture the client and matter details, read the documents that arrive, run the conflict and KYC checks, and open the file. AI can read an incoming instruction, extract the parties and the key dates, draft the matter-opening record and assemble the conflict-check inputs so nothing is keyed by hand. The partner still clears conflicts and accepts the matter, but the assembly that used to delay a file opening by a day happens in minutes. It is the same document extraction pattern the rest of professional services runs on, pointed at instructions and engagement documents. ## Privilege and confidentiality are a design decision This is where law firms are right to be cautious, and where the choice of tooling matters more than anywhere else. Client documents cannot be used to train someone else's model or leak across a shared service. So the questions to settle before anything is switched on are concrete: where does the data go, who can see it, is it used for training, and where is it stored. The answer should be an enterprise arrangement with no training on your data, tenant isolation, and hosting that satisfies your confidentiality and data protection obligations. Privilege is not preserved by a policy paragraph. It is preserved by the architecture, decided before the first document goes near a model. ## Verification, because the model is confident when it is wrong A language model will state a wrong case name or a plausible but non-existent clause with total confidence. That is not a bug you can prompt away, it is how the technology works, and in a legal setting it is the single most important thing to design around. Every citation, every quoted authority, every figure that leaves the firm gets checked by a person against the source. We wrote about why human-in-the-loop oversight has to be genuine rather than a rubber stamp, and legal work is the sharpest example. If the lawyer cannot realistically verify the output in the time they have, you do not have oversight, you have exposure. Build the checkpoint so verification is fast and unavoidable, not optional and skipped under deadline. ## The audit trail protects you and the client Every AI-assisted piece of work leaves a record: what the model was given, what it produced, what the lawyer changed, and who approved the final version, with the prompt and model version logged. For a firm that may one day need to show how a document was produced, or defend the reasonableness of its process, that trail is protection. It is also nearly free if built in from the start and a nightmare to reconstruct later, the same lesson every regulated sector learns the hard way. ## Start with the workflow that hurts most Do not roll AI across the whole firm at once. Pick one workflow, usually contract review against a playbook or drafting from precedents, and build it properly with the confidentiality, verification and audit trail in place. That is typically a Build Sprint, 8 to 12 weeks from a fixed £40k, and worth scoping in a Roadmap first so you start where the hours actually are. Prove the pattern once, then extend. If document review and drafting are the bottleneck in your practice, a discovery call will get you a candid read on where to start and what it is worth. No deck, no hype. Just the workflow, the guardrails and a number. ### Human-in-the-loop AI: what it means and when a regulator expects it URL: https://www.sparkconsulting.tech/blog/human-in-the-loop-ai Published: 2026-04-08 · Author: Seb Lawson · Governance & compliance Human-in-the-loop is not a person clicking approve. It is a person who can realistically catch an error in the time they are given, with the information they need, and the authority to stop what happens next. If any of those three is missing, you do not have oversight. You have theatre. And a regulator can tell the difference in about ten minutes. The phrase gets used as a reassurance. 'Don't worry, there's a human in the loop.' But the loop only counts if the human can act. A reviewer who sees forty AI outputs an hour, with no context and no realistic power to reject, is a rubber stamp with a pulse. The JFSC's guidance is explicit that oversight must be meaningful, and meaningful is a high bar dressed in a plain word. ## Real oversight versus theatre Three things separate the two, and all three have to hold. - Time. The reviewer has enough of it to actually assess the output, not just glance at it. If the volume forces a two-second look, the review is decorative. - Information. They can see what the AI saw and how it reached the output. A person cannot sensibly approve a decision whose basis is hidden from them. - Authority. They can say no, and no sticks. If overriding the system is career-costly or practically impossible, the human is not in control of anything. Theatre is easy to spot once you look for it. The approval rate is 99 percent. Nobody remembers the last time a human rejected an output. The reviewer cannot explain how the system reached its answer. Each of those is a sign the loop exists on the org chart and nowhere else. ## Calibrate oversight to risk Not every AI use needs a human standing over it. Uniform oversight is as wrong as no oversight, because it wastes scrutiny on trivia and starves the cases that matter. We use four modes, chosen by how much damage a wrong output could do. 1. Approve. The AI proposes, a human signs off before anything happens. Reserved for high-stakes cases: onboarding decisions, client-facing letters, anything touching a payment or a regulatory return. 2. Assist. The AI drafts, a human edits and owns the result. Good for medium-stakes work where a person is already in the flow, like drafting a file note or summarising a document. 3. Exception. The AI runs on its own and only escalates the uncertain or unusual cases to a person. Efficient for high-volume, low-stakes work where most outputs are routine. 4. Kill switch. The AI runs autonomously, but someone monitors it and can stop it instantly. For low-stakes automation where speed matters and the blast radius of a failure is small and reversible. The art is putting each workflow in the right mode. Most firms find the mistake runs one way: they apply full approve-mode oversight to everything, the reviewers drown, and the scrutiny quietly degrades into theatre on the cases that actually needed it. Match the mode to the harm and the oversight stays real where it counts. ## When a regulator expects it A person is expected in the loop whenever an AI output can reach a client, move money, or feed a regulatory return without a human between the model and the consequence. That is the general shape of it across principles-based regimes like Jersey's and the more prescriptive tiers in the EU. The higher the potential harm, the closer and more genuine the oversight a supervisor will expect to see. The test a regulator applies is not whether a human was technically present. It is whether that human could and did exercise real judgement. So the burden is on you to show it: an approver by name, a record of what they saw, evidence that rejections actually happen. Without that, 'there was a human in the loop' is a claim you cannot back. ## Oversight and audit are one control Human oversight only holds up if it leaves a record. The approver's name, what they reviewed, whether they changed anything, and when. That is where oversight meets the AI audit trail: the log is what turns 'we had a human review it' from a claim into evidence. Build the two together, because separately they are each half a control. In our work, getting oversight right on a single high-stakes workflow is a couple of weeks, and it is the part of an AI and automation roadmap that keeps a firm defensible as it scales. Prove the pattern once, then reuse the same four modes across every system you build. If you are not sure whether your current oversight is real or theatre, book a discovery call. We will look at one live workflow, tell you which mode it should be in, and show you what a supervisor would actually want to see. No deck, no hype. ### Why most AI pilots never reach production, and how to avoid it URL: https://www.sparkconsulting.tech/blog/why-ai-pilots-fail Published: 2026-03-31 · Author: Seb Lawson · Adoption & strategy Most AI pilots fail for reasons that have nothing to do with the AI. The model works. The demo impresses. And then the thing never reaches the day job, because a demo is not a system and nobody planned for the difference. In our experience the same four gaps kill pilots again and again, and all four are avoidable if you name them before you start. The trap is that a pilot is designed to prove the technology, when the real question was always whether the firm can run it. Those are different tests. Passing the first tells you almost nothing about the second, which is why so many impressive proofs of concept quietly die on a shelf. ## 1. No owner The most common cause of death. The pilot was run by an enthusiast or a vendor, and when the demo ended nobody senior owned taking it into production. No owner means no budget to finish it, no authority to change how work is done, and nobody accountable when it needs maintenance. A system without a named owner is a hobby, and hobbies do not survive a busy quarter. Put one senior person's name against it before you build anything. ## 2. No integration The pilot ran in a sandbox, on exported data, with someone copying results back by hand. That is fine to prove a point and fatal as a way of working. If the system does not connect to the tools your team already lives in, the inbox, the document store, the practice management system, then using it is extra work, and extra work loses to the old way every time. Production means the workflow happens where the work already happens, not in a separate window someone has to remember to open. ## 3. No audit trail This is the one that stops regulated firms specifically. The pilot produced good outputs but kept no record of how: no log of the input, the model and prompt version, the output, or who approved it. In a regulated firm that is not a system you can put into production, because the first time a supervisor asks how a decision was reached, you have no answer. Retrofitting an audit trail after the fact is painful and sometimes impossible, which is why we build it in from day one. Our piece on building an AI audit trail sets out exactly what to capture. ## 4. The wrong first use case Many pilots were doomed at selection. Someone picked the most ambitious, most visible, highest-stakes workflow, because that is the one that would impress. But high stakes means heavy oversight, hard integration, and no tolerance for the errors a first system will make. The pilot collapses under its own risk before it can prove anything. The fix is the opposite instinct: start with the smallest painful workflow, low or medium stakes, where a wrong output is caught before it matters. We made the full case in where to start with AI. ## The pattern underneath all four Notice what these have in common. None of them is a technology problem. They are all about ownership, plumbing, evidence, and judgement, the unglamorous operational work that a demo is specifically designed to skip. That is the pilot-to-production gap: the distance between something that works once, in a controlled setting, and something a team uses every day and a regulator can inspect. The gap is where the actual value lives, and it is the part most firms are least equipped to cross alone. ## How to avoid it Scope for production from the first day, not the demo. Before you build, name the owner, decide how it integrates, define the audit trail, and pick a first use case small enough to actually finish. Ship it into the real workflow in four to six weeks, measure it, and only then reach for the next. That is not a slower way to run a pilot. It is the difference between a pilot and a system. The other quiet killer is what happens after go-live. A system nobody tends drifts, breaks, and gets abandoned. That is exactly what our Operating Partner engagement from £6k a month exists to prevent: an owner in all but name, keeping the systems honest, logged, and improving. If your last pilot stalled, or you want the next one to reach production, book a discovery call and we will tell you which of the four gaps is about to bite. ### The EU AI Act and UK AI rules: what professional services firms actually have to do URL: https://www.sparkconsulting.tech/blog/eu-ai-act-uk-rules-professional-services Published: 2026-03-17 · Author: Seb Lawson · Governance & compliance Two regimes, two philosophies. The EU AI Act sorts AI systems into risk tiers and regulates the high-risk ones hard, with prescriptive obligations. The UK and Jersey lean on principles, leaving existing regulators to apply proportionate judgement. If your firm serves clients in both, you may sit under both at once. This is what that actually requires, without the alarmism. Start with a calming fact. Most professional services firms are users of AI, not builders of it. That matters, because the heaviest obligations in the EU regime fall on the people who develop and place high-risk systems on the market. As a firm using a vendor's tool inside your own workflow, your duties are real but lighter, and mostly about governance rather than engineering. ## The EU AI Act in one paragraph The Act ranks AI by risk. A small set of uses is banned outright. A defined group is treated as high-risk and carries obligations around risk management, data quality, documentation, human oversight, and transparency. Most business tools fall into a limited-risk band where the main duty is disclosure, telling people they are dealing with AI. And a large remainder is minimal-risk with no specific obligations. The obligations phase in over time rather than landing all at once, so treat any specific date or clause as something to verify against the primary text, not as gospel from a blog. ## Who is actually caught A UK or Channel Islands firm can be pulled into the EU regime by reach, not just by location. In broad terms, you may be in scope if you provide or deploy an AI system whose output is used in the EU, or if you serve EU-based clients through an AI-driven process. Being outside the EU is not automatic exemption. The practical trigger is where your AI's effects land, not where your office is. For most professional services work the honest answer is: you are probably a deployer of limited-risk or minimal-risk systems, with a smaller number of use cases that could edge toward high-risk if they materially affect a person's access to a service. The work is to identify which is which, rather than to assume the whole firm is caught or that none of it is. ## The UK and Jersey contrast The UK has favoured a principles-based, pro-innovation approach, asking existing regulators to apply cross-cutting principles within their own remits rather than passing one omnibus AI law. Jersey is aligned in spirit. The JFSC's guidance is proportionate and outcomes-focused, landing accountability with the board rather than prescribing controls line by line. The contrast is real but the destination is similar. Whether a rule tells you to keep records and maintain human oversight, or a principle expects you to, you end up building the same handful of controls. In our experience a firm that governs AI well for its own sake satisfies both regimes with one framework, rather than running two compliance projects in parallel. ## What to actually do Five steps cover most professional services firms, and none of them require a legal department. 1. Inventory your AI. List every system in use, what it does, whose data it touches, and where the output lands. You cannot tier what you cannot see. A first pass takes about a day. 2. Tier by risk. Sort each use into minimal, limited, or high-stakes by what a wrong output could reach. This is the spine of both regimes and it tells you where to spend effort. 3. Handle disclosure. For anything client-facing, be ready to tell people when they are interacting with AI. This is often the only hard EU obligation a limited-risk deployer carries. 4. Build oversight and an audit trail on the high-stakes cases. A named human who can override, and a record of every material decision. This satisfies the demanding parts of both regimes at once. 5. Check jurisdiction on EU-touching work. Where your AI's output reaches EU clients or users, take a proper view on scope. This is the one place worth a specialist's read rather than a rule of thumb. That is a four to six week piece of work for a firm of 20 to 250 people, and it doubles as the governance foundation you would want regardless of regulation. It is the core of our AI and automation roadmap, and it is why the systems we build tend to survive contact with either regime. One caveat, stated plainly. AI regulation is moving quickly, and the exact tiers, dates, and obligations shift as guidance and case law develop. Treat this as our practical read of the landscape, not as legal advice, and verify any specific point against the primary source before you rely on it. If you want a grounded view of which of your AI uses are caught and what to fix first, book a discovery call. We will map your systems to the tiers, flag the EU-touching cases, and put a number on the work. No deck, no hype. ### Prompt versioning: keeping AI outputs consistent and auditable URL: https://www.sparkconsulting.tech/blog/prompt-versioning Published: 2026-03-10 · Author: Seb Lawson · Technology, explained Treat your prompts like code, because that is what they are. The prompt is the instruction that tells the AI what to do, and it is the actual logic of the system. Change a line of it and you change every output that follows, often in ways you did not intend and cannot see until something goes wrong. Yet in most firms prompts live in a document somebody edits on a whim, with no record of what changed, when, or why. That is a control gap, and in regulated work it is the kind a supervisor finds quickly. Prompt versioning closes it. ## Why a prompt is not just a sentence It is tempting to see the prompt as a casual request, the way you would ask a colleague. It is not. In a live system the prompt encodes the rules: what to extract, what tone to take, what to refuse, what to flag for a human. It is the difference between an output you can defend and one you cannot. A small wording change, adding an example, tightening an instruction, telling the model to be more concise, can shift results across thousands of documents. If that shift is invisible and unrecorded, you have no way of knowing why last month's outputs and this month's no longer match. ## Consistency is the first casualty Language models do not return the same answer to the same question every time. There is natural variation built in. The prompt is your main lever for pinning behaviour down: a precise, well-tested instruction produces far more consistent results than a loose one. So when someone quietly tweaks the prompt to fix one annoying output, they may be loosening the very control that kept the other thousand consistent. Without versioning you cannot even tell that the tweak happened, let alone measure what it did. The outputs drift, someone eventually notices, and nobody can explain when it started. ## What versioning actually means It is exactly what software teams have done with code for decades, applied to prompts. Every version of a prompt is saved, numbered, and dated. You can see what the prompt said last Tuesday, who changed it, and why. You can compare two versions side by side. You can roll back to the previous one in seconds if a change makes things worse. None of this is exotic technology. It is the discipline of never editing the live instruction in place and never losing the history. - A stored history. Every version kept, numbered and dated, never overwritten. - A reason attached. A one-line note on why each change was made, so the record explains itself. - A tie to outputs. Each output records which prompt version produced it, so you can trace any result back to the exact instruction behind it. - A way back. The ability to roll back to a known-good version the moment a change misbehaves. ## Test before you ship The other half of treating prompts like code is testing them like code. Keep a small set of representative examples with the outputs you expect, and run any new prompt version against them before it goes live. Did the change you wanted happen? Did it break anything you were not looking at? This is how you catch the classic failure, where fixing one edge case quietly ruins the ninety-nine ordinary ones. It takes minutes to set up and it turns prompt changes from a gamble into a controlled step. A prompt change that has not been tested against known examples is a change made with your eyes shut. ## Where this meets the regulator A supervisor asking about an AI system will eventually ask the same question in different words: how do you know it does what you say it does, and can you prove what it did on a given day. Prompt versioning is a large part of the answer. It lets you show the exact instruction in force when a particular output was produced, and it lets you demonstrate that changes are controlled rather than made on a whim. That sits right alongside the wider record of inputs, outputs and approvals we set out in building an AI audit trail. Versioned prompts are one of the load-bearing entries in that trail. ## How we do it Every system we build treats the prompt as a versioned, tested, logged component from the first day, not something bolted on when someone asks. The cost of doing it early is close to nothing. The cost of retrofitting it after outputs have drifted and nobody can say why is real, and sometimes the history is simply gone. This is the same principle we apply across our work: build the governance in while it is cheap, so the system survives contact with an auditor rather than collapsing under the first hard question. If you are running AI in production and cannot currently say which prompt produced last month's outputs, that is worth fixing before someone asks. Book a discovery call or look at how an Operating Partner engagement from £6k a month keeps prompts, tests and change logs maintained as your systems evolve. The discipline is dull. The absence of it is expensive. ### AI for accountancy practices: from bookkeeping to advisory URL: https://www.sparkconsulting.tech/blog/ai-for-accountancy-practices Published: 2026-03-04 · Author: Seb Lawson · Sector playbooks The lowest-margin work in your practice is the most automatable, and that is the whole opportunity. Data entry, transaction categorisation, bank reconciliations, chasing records, first-draft accounts: this is high-volume, low-judgement work that AI and automation handle well, and every hour of it you reclaim is an hour your qualified people can spend on advisory work clients actually value. The point of AI in an accountancy practice is not to do accounting. It is to move your best people up the value chain, from compliance grind to the advice that carries a real fee. In our experience a practice can take 40 to 60 percent of the manual effort out of routine compliance work within a couple of cycles. Here is where the time goes, and where automation gets it back. ## Data entry and categorisation, read not typed The single biggest drain in most practices is turning a client's shoebox of documents into clean data. Invoices, receipts, bank statements and expense claims arrive as PDFs, photos and spreadsheets, and someone keys them in. AI reads them instead, extracting amounts, dates, suppliers and VAT, and proposes a category based on the description and the client's history. This is the document extraction engine at the heart of the modern back office. The categorisation learns your treatment of recurring items, so the coding gets more accurate over time and your team confirms rather than types. The tedious part shrinks; the review part stays. ## Reconciliations that surface only the breaks Bank and ledger reconciliation is rule-based work that automation does faster and more reliably than a person working late. The system matches transactions, applies your tolerances, and presents only the exceptions: the unmatched items, the duplicates, the entries that do not tie out, each with a plausible explanation drafted for review. Instead of scrolling a full ledger to find the handful of problems, your team opens a short queue of genuine breaks. The 90 percent that reconciles cleanly runs itself, and the human attention goes to the items that actually need a decision. ## Drafting accounts, letters and queries Once the numbers are in, AI drafts from them. First-draft accounts in your house format, client query letters, the list of missing records, a plain-English summary of the year's numbers for the client meeting: all built from data you already hold, ready for a qualified person to review and finalise. Drafting from a blank page is where hours quietly disappear, and starting from a competent 80 percent draft changes the economics of the compliance job. The accountant edits and signs. The machine does the typing, not the thinking. ## The human check stays, because the numbers matter Nothing here files a return or issues accounts on its own. Every categorisation, reconciliation and draft is reviewed and approved by a person before it counts. This is not timidity, it is proportion. A miscoded transaction or a wrong figure in filed accounts reaches a client and potentially a tax authority, which puts it in the tier where genuine human oversight is not optional. The automation removes the keystrokes and the assembly; the qualified judgement and the sign-off stay exactly where your professional responsibility requires them. That is what lets you go faster without going careless. ## The advisory dividend is the real return Here is the part that changes the shape of a practice. When compliance work takes half the time, you are not just cutting cost, you are freeing capacity at the top of the pyramid. The senior people who were buried in review can spend that time on cash-flow advice, tax planning, management reporting and the forward-looking conversations clients happily pay a premium for. Advisory is where the margin and the client loyalty live, and the constraint has always been time. Automating the compliance base is how you buy that time back. Measure it properly: track the chargeable advisory hours you unlock, not just the compliance hours you save, because that is where the return actually shows up. We set out how in how to measure AI ROI. ## An audit trail, because you are regulated too Every automated step leaves a record: what was extracted, how it was categorised, what was flagged, what a person changed, and who approved the output, with the model and prompt version logged. For a practice answerable to a professional body and to HMRC, that trail is both protection and good discipline. Built in from the start it is nearly free; retrofitted later it is a headache. It is also what lets you adopt AI with confidence rather than crossing your fingers. ## Where to start Start with the workflow that consumes the most junior time, usually data entry and categorisation, and build it properly with the review step and the audit trail in place. That is typically a Build Sprint, 8 to 12 weeks from a fixed £40k, and worth scoping in a Roadmap first so you automate in the order that returns the most soonest. Prove the pattern on one client segment, then roll it across the book. If compliance work is crowding out advisory in your practice, a discovery call will get you a straight read on which task to automate first and what it frees up. No deck. Just the hours and the number. ### AI and data protection under UK GDPR and the Data Protection (Jersey) Law 2018 URL: https://www.sparkconsulting.tech/blog/ai-data-protection-uk-gdpr-jersey Published: 2026-02-24 · Author: Seb Lawson · Governance & compliance Feeding client data into an AI tool is processing personal data, and every rule you already follow still applies. UK GDPR and the Data Protection (Jersey) Law 2018 do not have an AI exemption. If anything, AI raises the stakes, because you are often sending personal data to a third party, sometimes offshore, and getting back an output whose basis you may struggle to explain. The obligations are familiar. The failure modes are new. The good news is that the two regimes are closely aligned. The Jersey Law tracks the GDPR structure deliberately, so a control built for one generally satisfies the other. You are not running two data protection projects. You are running one, applied carefully to a new kind of processing. ## Lawful basis comes first Before you put personal data through an AI system, you need a lawful basis for that processing, and it has to cover the AI use specifically. Consent gathered for onboarding does not automatically extend to feeding the same data to a model for a purpose the client never saw. Where you rely on legitimate interests, do the balancing exercise properly and write it down. If the data is special category, the bar is higher again. The question to answer, in one line, is: on what basis are we allowed to process this person's data through this tool, for this purpose? If the honest answer is 'we hadn't thought about it that way', stop and think about it before the data leaves your building. ## Data minimisation, applied to prompts The habit that gets firms into trouble is oversharing with the model. It is tempting to paste an entire client file into a prompt because it is easy. Minimisation says send only what the task needs. If a summary requires three fields, do not send thirty. If a name is irrelevant to the analysis, redact it. Every extra field in a prompt is personal data you have exported, often to a system you do not control. In practice this is a design decision, not a discipline you can rely on staff to remember under time pressure. Build the workflow so it only ever passes the minimum, and minimisation stops being a rule people break and becomes a property of the system. ## Where do your prompts and outputs actually go This is the question most firms cannot answer, and the one a regulator will ask. When someone types into an AI tool, where does that text travel, where is it stored, for how long, and is it used to train the vendor's models? The answers vary enormously between a consumer chatbot and an enterprise deployment with a data processing agreement and training switched off. - Residency. Where is the data physically processed and stored? Transfers out of the UK or Jersey need a lawful transfer mechanism, and 'the server is somewhere in the US' is not one. - Retention. How long does the vendor keep prompts and outputs, and can you delete them? Indefinite retention of client data by a third party is a problem you own. - Training. Is your data used to improve the vendor's models? For client data, the answer needs to be no, and you need it in writing. - Sub-processors. Who else touches the data downstream? Your obligations follow the data even when a vendor hands it on. ## Vendor and contract questions Where an AI vendor processes personal data on your behalf, they are your processor, and you need the same contractual controls you would demand of any material outsourcing. A data processing agreement, clear purpose limits, security commitments, breach notification, and the right to audit. The convenience of signing up with a corporate card does not remove the obligation to have the paperwork a supervisor expects. Treat consumer-grade AI tools with particular care. The free tier that trains on your inputs is not somewhere client data should go, however useful it feels. Pick tools that offer an enterprise footing with the controls in writing, and reserve the consumer versions for non-personal, non-confidential work. ## DPIAs for high-risk use Where an AI use is likely to result in a high risk to people's rights, a Data Protection Impact Assessment is not optional, it is expected. That covers profiling, automated decisions with legal or similarly significant effects, and large-scale processing of sensitive data. The DPIA is where you set out what the system does, what could go wrong, and the controls that bring the risk down to acceptable. Done well, a DPIA is not a hoop. It is the same thinking as a good AI risk assessment, written in the language a data protection regulator reads. Much of the evidence it needs, what the system does, who oversees it, what is logged, comes straight from your AI audit trail. Build the trail and the DPIA half writes itself. Getting this right across a firm's AI use is typically a four to six week piece of work, and it sits inside our AI and automation roadmap. One caveat, stated plainly: this is our practical read, not legal advice, and you should check specific points against the primary legislation and your regulator's guidance before you rely on them. If you want a candid view of where your client data actually goes when your team uses AI, book a discovery call. We will trace one live workflow end to end, flag the data protection gaps, and put a number on the fix. No deck, no hype. ### An AI readiness checklist for firms of 5 to 250 people URL: https://www.sparkconsulting.tech/blog/ai-readiness-checklist Published: 2026-02-10 · Author: Seb Lawson · Adoption & strategy You do not need to be ready for AI in general. You need to be ready for one specific workflow, and that is a far smaller test. The firms that stall are usually waiting to be ready for everything. The firms that move check four things against one use case, find they are more ready than they feared, and start. This is that checklist, written to be honest rather than reassuring. Treat it as a diagnostic, not a gate. You do not need every box ticked before you begin. You need to know which boxes are empty, because the empty ones tell you what to fix first and what to keep a human in front of while you fix it. ## Data: can the system get to what it needs AI is only as good as what you can feed it. You do not need a data lake. You need the specific inputs for your first workflow to be reachable and reasonably consistent. - The documents or records the workflow needs live somewhere a system can reach, not only in someone's head or a paper file. - The inputs are consistent enough to work with. Messy is fine. Genuinely unpredictable, with no pattern, is a problem to solve before you automate. - You know where that data may and may not go, especially anything that would leave the island or a controlled environment. Our note on data protection under UK GDPR and Jersey law covers the lines that matter. - You can get to the data without breaching a contract or a client confidentiality term. Check before you connect, not after. ## Governance: can you show your working For a regulated firm this is the section that decides whether a pilot ever becomes a system. None of it is heavy. All of it has to exist. - One senior person is willing to put their name against AI adoption, with the authority to stop a system going live. - You have, or can build in a day, a simple register of what AI is already in use across the firm. Most firms find more than they expected once they look. - You can sort a use case into low, medium, or high stakes by what a wrong output could reach, and match the oversight to the tier. - You accept that every material AI decision needs a record: the input, the model and prompt version, the output, and who approved it. Our AI governance framework sets out the whole spine, and it is lighter than you think. ## Skills: enough to govern, not to build You do not need engineers on staff. You need enough understanding to make good decisions and keep an honest hand on the wheel. - At least one person accountable actually understands what the technology can and cannot do. 'The vendor said it was fine' is not a control. - The people who will use the workflow are willing to try it and honest enough to say when it is wrong. - Someone will own the system after go-live, because a system nobody tends drifts and breaks. If that owner is not on your staff, an Operating Partner can be that hand for you. - Your team knows the difference between a system that assists a human and one that decides on its own, and knows which one they are being handed. ## One good use case: the box that matters most You can have every other box ticked and go nowhere without this one. A good first use case is frequent, rule-bound, and forgiving of the occasional error because a human checks it before it counts. It is small enough to finish in weeks and painful enough that people will actually use it. If you cannot name one, that is your first piece of work, and it is a conversation, not a project. - It happens weekly or more often, so small savings add up to a real number. - You can describe the logic in a couple of sentences a new joiner could follow. - A wrong output is caught by a human before it reaches a client, a payment, or a regulatory return. - You can put a pound figure on what it costs you today. If you cannot, it is not your first case yet. ## Reading your score If most of the data and use-case boxes are ticked and the governance ones are thin, you are ready to start and should build the governance alongside the first workflow, not before it. If the data is not reachable or you cannot name a use case, fix that first, and it is usually a fortnight of work, not a transformation programme. Perfect readiness is a myth. Enough readiness for one workflow is a Tuesday. If you want the checklist run properly against your firm, that is precisely what a Roadmap from £15k does in four to six weeks: it scores where you stand, picks the first workflow, and writes down what it is worth. For a faster, candid read, book a discovery call and we will tell you honestly which boxes are empty and which one to fill first. ### Claude vs GPT vs Gemini for professional services work URL: https://www.sparkconsulting.tech/blog/claude-vs-gpt-vs-gemini-professional-services Published: 2026-01-28 · Author: Seb Lawson · Technology, explained All three are good. That is the honest starting point, and it is worth saying plainly because the internet would have you believe one of them is about to win forever. Claude, GPT and Gemini are each capable of doing serious professional work, and any of them will impress you in a demo. The differences that matter to a law firm, a trust company or a fund administrator are not the ones the benchmark leaderboards fight about. They are about how the model handles a hundred-page document, how your data is treated, and what it plugs into. Here is how we compare them, and where we tend to land for regulated work. One caveat first. These models change every few months, and specific capabilities move with each release. Treat the shape of this as durable and the fine detail as a snapshot. What follows is our working view, not a lab benchmark. ## Reasoning and careful work For the kind of work that carries risk, reading a clause carefully, following an instruction exactly, refusing to guess when it does not know, we favour Claude, and the latest Claude 5 family and Opus 4.8 have reinforced that preference. It tends to be the most willing to say 'that is not in the document' rather than inventing a plausible answer, which is precisely the behaviour you want when a wrong output could reach a client or a regulator. GPT is a very strong all-rounder and often the most fluent writer of the three. Gemini reasons well and is improving quickly. The gaps here are narrow and they move. But for cautious, instruction-following work in a regulated setting, Claude's temperament fits the job. ## Long documents This is where real work lives, because professional services runs on long documents: trust deeds, prospectuses, loan agreements, bundles of correspondence. All three can now take a large amount of text in a single go, which was not true a couple of years ago. Gemini has pushed hard on very large context and is a strong choice when you genuinely need to reason across an enormous volume at once. Claude is reliable and precise across long documents and, in our experience, holds its accuracy well deep into a lengthy input. GPT is capable here too. The practical point is that raw capacity is no longer the constraint it was. What separates them now is accuracy at length, and that is worth testing on your own documents rather than trusting a headline number. ## Data handling and trust For a regulated firm this outranks cleverness, and it is where the decision often actually turns. The questions are the same for all three providers. Is your data used to train the model. Where is it processed. What are the contractual and data protection terms on the business and enterprise tiers. The consumer versions of these tools and the business versions are not the same on any of these points, and the terms genuinely differ between providers and change over time. Anthropic has built much of Claude's public positioning around safety and careful data handling, which lands well with cautious firms, but you should verify current terms for whichever you choose rather than take any reputation on trust. We cover the underlying obligations in AI, data protection and UK GDPR in Jersey. The short version: read the terms of the specific tier you are buying, and do not assume the free tier's rules apply to the paid one, or the other way round. ## Ecosystem and where it already sits Sometimes the deciding factor is not the model at all but what it connects to. GPT sits inside the OpenAI and Microsoft world, so if your firm runs on Microsoft 365 there is a gravitational pull towards it. Gemini is woven through Google Workspace, which matters if that is where your firm lives. Claude is strong on integration through open standards and is a common choice for custom builds where you want to avoid being tied to one vendor's stack. None of this decides the question on its own, but it is a real cost or saving depending on where your firm already is. ## Where we land For the regulated, document-heavy, careful work that is our bread and butter, Claude is usually our default, because its instinct to stay grounded and admit uncertainty suits work where a confident wrong answer is the worst outcome. That is a preference, not a rule. We reach for the others without hesitation when the job calls for it. - Claude for careful reasoning, long regulated documents, and standards-based custom builds where staying grounded matters most. - GPT for fluent writing, broad general capability, and firms already living in Microsoft 365. - Gemini for very large volumes of text at once and firms built on Google Workspace. The mistake we see most often is choosing a model in the abstract, from a review or a demo, before knowing the actual task. The right way round is to define the workflow first, then pick the model that fits it, and then test it on your own real documents before committing. The differences that show up on your material are the only ones that matter. If you want help matching a model to a real workflow rather than a benchmark, that is the kind of thing a Roadmap from £15k settles quickly, with the choice tested on your own documents and a number attached to the outcome. Or book a discovery call and we will give you a candid steer for your specific work. The model matters less than getting the workflow and the governance right, which is the part we care about most. ### Document extraction: turning PDFs, contracts and statements into structured data URL: https://www.sparkconsulting.tech/blog/ai-document-extraction Published: 2026-01-20 · Author: Seb Lawson · Sector playbooks If you automate one thing in a professional firm, automate document extraction. It is the unglamorous workhorse sitting underneath almost every AI system worth building: the step that turns the PDFs, scanned contracts, bank statements and forms clogging your inbox into clean, structured data a computer can actually use. It is not exciting. It is where the money is. Get extraction right and onboarding, reconciliation, review and reporting all speed up, because every one of them starts with reading a document. Get it wrong and nothing downstream works. Typically a well-built extraction step handles 80 to 90 percent of documents with no human touch, and routes the rest to a person. ## What it actually does Extraction takes an unstructured document, a thing built for a human to read, and pulls out the specific data points you care about into fields a system can store. A passport becomes a name, a number and an expiry date. A bank statement becomes a list of transactions with dates and amounts. A contract becomes parties, dates, values and key clauses. Old approaches used rigid templates and broke the moment a layout changed. Modern AI reads the document more like a person does, understanding that the total is the total whether it sits top-right or bottom-left, which is why it copes with the messy variety of real-world paperwork that template systems never could. ## How it works, without the jargon There are three steps. First, if the document is a scan or a photo, the text is recognised and lifted off the page. Second, an AI model reads that text, and increasingly the layout and images too, and identifies the fields you asked for. Third, and this is the part firms skip at their peril, each extracted value comes back with a confidence signal. The model tells you not just what it read but how sure it is. That confidence score is the hinge the whole system turns on, because it lets you send the easy 85 percent straight through and hold back the 15 percent that needs a human eye. ## Accuracy, honestly Extraction is very good and it is not perfect, and anyone who tells you otherwise is selling something. A clean, typed document extracts near-flawlessly. A crumpled receipt photographed at an angle in poor light does not. The mistake is chasing 100 percent accuracy from the model itself, which is neither achievable nor necessary. The workable target is high accuracy on clear documents plus honest confidence scoring on the rest, so the system knows what it does not know. A model that is 90 percent accurate and always flags its uncertainty is far more useful than one that is 95 percent accurate and confidently wrong on the other 5 with no warning. You design for the errors you can catch, not the accuracy you wish you had. ## Why human review is a feature, not a failure The confidence score turns human review from a bottleneck into a design choice. High-confidence fields flow straight through. Low-confidence fields land in a short review queue where a person confirms or corrects them in seconds, and every correction is a data point that improves the setup over time. This is how you get speed and reliability at once, and in a regulated setting it is also how you stay compliant, because genuine human oversight is exactly what the JFSC and every professional body expect. The human is not there because the machine failed. The human is there by design, spending their attention only on the documents that actually need it. ## Extraction versus RAG It helps to know what extraction is not. Extraction pulls specific fields out of a document into structured data. Retrieval, the technique behind RAG, does something different: it finds and quotes the relevant passage from a large body of documents to answer a question. You use extraction when you know exactly which fields you want, every time, in the same shape, which is the case for onboarding forms, statements and invoices. You use retrieval when the question varies and you need the system to go find the right paragraph. Most real systems use both, extraction to structure the incoming documents and retrieval to answer questions across them, and knowing which job you have is half of designing it well. ## Where the value actually sits The same extraction engine, tuned to different documents, powers the highest-value workflows across every sector we serve. In trust and corporate services it reads KYC documents for client take-on. In fund administration it turns custodian statements and price files into a validated NAV. In law it lifts the parties and dates out of an instruction. In accountancy it reads the shoebox of invoices and receipts. Build it once, properly, with the confidence scoring and the review queue working, and you have the foundation every other automation stands on. That is why it is the first thing we build and the piece we take most care over. ## What it takes to build A production extraction system tuned to your document types, with the confidence thresholds, the review queue and the audit trail in place, is typically a Build Sprint, 8 to 12 weeks from a fixed £40k, and it earns its keep faster than almost anything else because everything downstream depends on it. The work that matters is not the model, it is the tuning: testing against your own real documents, setting the confidence thresholds where they belong, and designing the review step so it is fast and reliable rather than an afterthought. If your team is still keying data off PDFs by hand, that is the workflow to fix first. A discovery call will get you a candid read on which documents to start with and what automating them is worth in hours per week. No deck, no hype. Just the workhorse, done properly. ## FAQ ### Working with Spark How we engage, what the process looks like, and who we are and are not for. **How is Spark different from a traditional agency or consultant?** Traditional agencies bill hourly and scope loosely, so the incentive is to take longer. We do the opposite. We work to a fixed price and a fixed timeline: an AI and automation Roadmap lands in four to six weeks from £15k, and a Build Sprint ships a production system in eight to twelve weeks from £40k. You pay for senior delivery, not the overhead of a large team, and the differentiator is the delivery rather than the deck. **What are your three engagement models, and which do I need?** Three, and most firms start with the first. A Roadmap (from £15k, four to six weeks) is where to begin if you are not yet sure what to automate: we map the operating model and hand back a costed plan. A Build Sprint (from £40k, eight to twelve weeks) is for when you know the workflow and want it built and live. An Operating Partner retainer (from £6k a month) is for firms that want us embedded as their ongoing AI and automation lead. If you are unsure, a discovery call will point you at the right one in 30 minutes. **What does the actual process look like, start to finish?** Four phases, and you approve each before we spend money on the next. Discovery maps your operating model end to end. Design produces a specification any engineer could pick up and a costed ROI model. Build happens against your real data in staging, with human checkpoints and audit trails from day one. Operate takes it live with training, documentation and monitoring. Our how we work page walks through each phase in detail. **How quickly can we start, and how soon will we see something working?** We can usually start a Roadmap within two to three weeks of a signed engagement, sooner if there is a gap. You see working output early: a Build Sprint is structured so the first usable version of a workflow is in front of your team well before the twelve-week mark, not saved for a big reveal at the end. We would rather show you something rough in week three than something polished in week ten. **Do we have to start with a Roadmap, or can we go straight to building?** You can go straight to a Build Sprint if the workflow is already clear and the value is obvious. Plenty of firms do. The Roadmap exists for when the priorities are not yet obvious, or when a board wants a costed plan across the whole firm before committing to a build. If you already know the smallest painful workflow worth fixing, we will happily skip to building it. **What size and type of firm do you work with?** Small to mid-sized firms, roughly 5 to 250 people, in regulated and professional services. That means finance, fund administration, trust and corporate services, wealth, law and accountancy as our core, with hospitality, construction and other professional services where back-office automation produces visible ROI in weeks. If your work is document-heavy, auditable and time-poor, you are the firm we are built for. **Who is Spark NOT the right fit for?** We are probably not right for you if you want custom enterprise software built from scratch, because we automate the tools and processes you already run rather than building new platforms. We are not right if you want a chatbot with no real workflow behind it, if you expect AI to replace strategic judgement, or if you need something delivered in days. Our shortest engagement is a four to six week Roadmap, and we would rather tell you that up front than overpromise. **Can you work alongside our existing IT team or provider?** Yes, and we usually do. We are not trying to replace your IT function or your managed service provider. We plug into what exists, document everything we build, and hand over cleanly so your team or your provider can run it. Where useful, we will train them directly so nothing depends on us continuing. **What do you need from us to be successful?** Three things, and none of them is a large time commitment. A named point of contact who knows how the work actually gets done. Access to the systems and a representative sample of real data, under NDA. And one person senior enough to make decisions and sign off. In our experience the projects that stall are the ones without a clear owner on the client side, so we agree that before we start. **Do you work with firms outside Jersey and the UK?** Our base is Jersey and our core market is the Channel Islands and the UK, but the work is delivered remotely and we work with firms elsewhere where the fit is right. What matters is the shape of the problem, not the postcode. That said, our regulatory fluency is strongest for Jersey, Guernsey, the Isle of Man and the UK, which is where we add the most beyond the build itself. ### Pricing and commercials What our engagements cost, how billing works, and where the numbers come from. **How much does it cost to work with you?** Three fixed prices, depending on what you need. An AI and automation Roadmap is from £15k and takes four to six weeks. A Build Sprint is from £40k and ships a live production system in eight to twelve weeks. An Operating Partner retainer is from £6k a month for firms that want us embedded as their ongoing AI and automation lead. Every price is fixed and quoted in advance, so you know the number before you commit, and a 30 minute discovery call will tell you which one fits. **Why do you charge a fixed price rather than an hourly or day rate?** Because hourly billing rewards taking longer, and we would rather be paid for the outcome than for our time. When the price is fixed, the incentive lines up with yours: scope it tightly, ship it, move on. It also means you can approve the spend against a known number rather than an open-ended meter, which is exactly what a board or a finance director wants to see. If a target is too fuzzy to price, we will tell you during Discovery rather than dressing it up as a day rate. **How are payments structured?** Fixed-price work is billed in three milestones: 30% to start, 40% at the midpoint, and 30% on delivery. That keeps you paying against progress you can see rather than everything up front. The Operating Partner retainer is billed monthly in advance at £6k a month. We invoice cleanly, in sterling, with the milestones written into the engagement so there are no surprises about when each payment falls due. **Do you offer payment plans?** The milestone structure is the payment plan. Splitting a fixed-price engagement into 30% at start, 40% at midpoint and 30% on delivery spreads the cost across the project rather than loading it at the front. For the larger Build Sprint engagements we can talk about the timing of those milestones if cashflow is tight, within reason. We are a delivery firm, not a lender, so we will not stretch payment across many months after the work is done, but we are pragmatic about staging it sensibly. **What is included in the price, and what is extra?** The price covers the senior delivery: the discovery, the design, the build against your real data, the testing, the documentation and the handover. A Build Sprint also includes 60 days of stabilisation support after go-live, so early issues are our problem, not yours. What sits outside the fee is the third-party running cost: model usage, platform and tooling subscriptions, and any new software you choose to buy. We size those running costs during Design and put them in the ROI model, so nothing about the ongoing bill is a surprise. **Are there ongoing or hidden costs?** No hidden costs, and the ongoing ones are sized before you commit. Once a system is live you pay for what it consumes: model usage plus platform and tooling fees, often in the region of a few hundred pounds a month rather than thousands for a typical workflow. We put that run rate in the ROI model during Design and build in sensible cost controls, such as usage limits on anything that scales with volume. You can read how we keep the running bill down on our stack page. **Is there a minimum spend?** Effectively yes. Our smallest engagement is a Roadmap from £15k, and the next step up is a Build Sprint from £40k. We do not take on £2k odd jobs or a few days of tinkering, because that is not where we add value and it rarely produces a result worth having. If your budget is below the Roadmap price, the honest answer is that we are probably not the right firm yet, and a discovery call will confirm that in half an hour rather than wasting a fortnight. **Do you offer free pilots, trials or discounts?** The discovery call is free. The work is not. We do not run free pilots, because a pilot that nobody has paid for is a pilot nobody takes to production, which is exactly the trap we help firms avoid. What you get without charge is a proper 30 minute conversation about your workflows, an honest steer on whether automation is worth it, and a view on which engagement fits. If the numbers do not stack up, we will say so rather than sell you something. **What happens to the cost if scope changes mid-project?** We handle it as a transparent change request, priced before any work starts on it. The fixed price is fixed against the scope we agreed, so if you want to add a workflow or expand the brief partway through, we quote the addition as a clear number and you decide whether it is worth it. Nothing gets built and billed without your sign-off. Because each phase is approved before we spend money on the next, you always keep control of where the budget goes. **Is there a minimum term or lock-in on the Operating Partner retainer?** No long lock-in. The Operating Partner retainer is a monthly arrangement at £6k a month, and it continues because it is earning its keep, not because a contract traps you. We agree a short initial period up front so there is time to build momentum, then it runs month to month with straightforward notice. The exact terms are set out in the engagement letter. If we are not delivering value you should be able to walk, and the retainer is built that way on purpose. ### Tools and platforms The AI models and automation platforms we build with, and how we choose between them. **What tools and platforms do you work with?** We are platform-agnostic by principle and opinionated by default. We work with whatever you already run, and when the choice is ours we reach for a default stack: Claude for reasoning, n8n for automation and orchestration, and a handful of others depending on the job. Our stack page lists it in full. Common integrations include CRMs such as HubSpot, Salesforce and Pipedrive, email platforms, Slack, spreadsheets, databases, document stores and payment processors. If it has an API, we can almost certainly connect it. **Which AI model do you use, and why?** Our default for careful, regulated work is Claude, because it tends to stay grounded and admit when it does not know rather than inventing a confident wrong answer, which is exactly the behaviour you want when an output could reach a client or a regulator. That is a preference, not dogma. We also build on OpenAI's GPT and Google Gemini where they fit better. We wrote a fuller comparison in Claude vs GPT vs Gemini for professional services work. **Are you tied to one AI vendor?** No, and we design deliberately to avoid it. Being locked to a single model provider is a commercial risk, because pricing, terms and capabilities all move. Where it makes sense we build so the underlying model can be swapped with limited rework, and we favour open standards such as MCP for connecting AI to your tools. The goal is that you own the system, not that you are renting it from us or from any one vendor. **What is n8n, and why is it your default automation platform?** n8n is a workflow automation platform that connects your apps and orchestrates multi-step processes, with AI steps where useful. We favour it for three reasons: it can be self-hosted so your data stays under your control, its workflows are transparent and auditable rather than a black box, and it avoids the per-task pricing that makes high-volume automation expensive elsewhere. For regulated firms that combination of auditability and ownership is usually decisive. **How do you choose between n8n, Make and Zapier?** By volume, auditability and where your data needs to live. Zapier is fastest for simple, low-volume connections across common SaaS tools. Make is a strong hosted, visual option for more involved workflows. n8n wins when you need self-hosting, high volume, or a full audit trail, which is most regulated work. We covered the wider decision in build, buy or no-code. We will recommend the cheapest tool that meets the requirement, not the most powerful one. **Do you build AI voice agents?** Yes. We design, pilot and tune voice agents using Vapi for the call flow and ElevenLabs for natural, on-brand speech. That covers inbound reception, triage, appointment booking and outbound follow-ups, integrated with your calendar and CRM. We build in clear AI disclosure and a human handoff by default, because a voice agent that cannot hand off gracefully does more harm than good. **Can you connect AI to our existing systems, like our CRM or case management tool?** Yes, and this is most of what we do. The value is rarely in a standalone AI tool. It is in connecting the model to the systems your work already lives in, so it can read a matter, draft the letter and update the record without anyone copying and pasting. If your system has an API we integrate directly. If it does not, there are usually other routes, and we will tell you honestly during Discovery whether a given integration is straightforward, awkward or not worth it. **Do we need to buy new software or replace what we already have?** Almost never. We start from the tools you already own and pay for, and we automate across them. Ripping out working systems is expensive, disruptive and rarely necessary. Occasionally a specific gap justifies a new tool, and if so we will say why and what it costs, but the default is to make your existing stack do more, not to sell you a new one. **Where is everything hosted, and can it run in our own environment?** It depends on the tool, and we design around your requirements rather than ours. Self-hostable components such as n8n can run in your own cloud tenancy or infrastructure so your data never leaves your control. AI models are generally accessed through the provider's business or enterprise API under commercial terms. During Design we agree exactly where each part runs and where your data flows, and we document it, which is also what a supervisor will want to see. **What does it cost to run these tools once they are live?** Running costs are usually modest relative to the time saved, and we size them before you commit. For a typical workflow, ongoing costs are model usage plus platform and tooling fees, often in the region of a few hundred pounds a month rather than thousands. We include the run rate in the ROI model during Design, so you are never surprised by a bill, and we build in sensible cost controls such as usage limits on anything that scales with volume. **How do you keep AI costs under control?** By matching the model to the task and metering usage. Not every step needs the most expensive model: we route simple work to cheaper or smaller models and reserve the heavyweight reasoning for where it earns its keep. We cap usage on anything that scales with volume, cache where it is safe to, and monitor spend so a runaway process is caught early. Cost discipline is part of the build, not an afterthought. **Can you migrate us off Zapier or Make onto something we own?** Yes, and it is a common request once per-task pricing starts to bite or an audit trail becomes a requirement. We map your existing automations, rebuild them on n8n with proper error handling and logging, run the two in parallel until the new version is proven, then switch over. The result is usually lower running costs, a full audit trail and no vendor holding your automations hostage. **Do you use no-code tools or write custom code?** Both, chosen by what the job needs rather than ideology. No-code and low-code platforms are faster, cheaper and easier for your team to maintain, so we reach for them first. When a requirement genuinely needs custom code, for a tricky integration or a bespoke piece of logic, we write it, and we document it so it is not a black box. The test is always total cost of ownership over a few years, not which approach looks more impressive. **What if a better tool or model comes out after you have built our system?** That is expected, and we build for it. Because we favour swappable components and open standards, moving to a better model or platform later is usually a contained change rather than a rebuild. If you are on an Operating Partner retainer we watch the landscape for you and propose swaps when they are worth the switching cost. If you are not, we leave you with documentation clear enough that any competent team can make the change. ### What we can build The kinds of systems we deliver, how far they can go, and where the honest limits are. **What kinds of things can you actually automate?** The document-heavy, repetitive back-office work that quietly eats your fee-earners' days. Think client onboarding and KYC gathering, pulling data out of statements and contracts, drafting standard letters and reports, chasing outstanding documents, reconciling records across systems, and answering internal queries against your own policies. If a task is rules-based, done often, and involves reading or moving information between tools, it is a candidate. Our what is AI automation page gives the wider picture, and the pattern is always the same: pick the smallest painful workflow first and ship it. **How complex can these systems get?** From a single automation to a multi-step agent that touches several systems, and we scale the ambition to the risk. At the simple end, one trigger fires one action: a document arrives, data is extracted, a record updates. In the middle sit multi-step workflows that read, decide, draft and route with a human approving the output. At the far end are agents that plan across several tools and hand off to a person at defined checkpoints. We deliberately start simple, prove the value, then add complexity only where it earns its keep. **What is an AI agent, and do we need one?** An agent is software that can decide the next step for itself rather than following a fixed script, and most firms do not need one to start. A simple automation or a chatbot solves a large share of real problems at a fraction of the risk and cost. An agent earns its place when a task genuinely branches, when the path changes with the input, and a rigid workflow would break. We pull the three apart in AI agents, chatbots and automations. We will recommend the least clever option that does the job, not the most impressive one. **Can you build document extraction from PDFs, contracts and statements?** Yes, and it is one of the highest-value things we do. We build systems that read PDFs, scanned documents, contracts and bank statements, pull out the fields you care about, and drop them into your systems in a structured, checkable form. The gain is real: work that took a person 20 minutes of careful copying drops to a review of a few seconds. We always keep a human confirming anything that matters, and we log what was extracted and by which version. There is more detail in AI document extraction. **What is RAG and do we need it?** RAG, retrieval-augmented generation, is how you make an AI answer from your documents rather than from its training data. It retrieves the relevant passages from your own material, then has the model answer using only those, with citations back to the source. You need it whenever an answer must be grounded in your policies, contracts or files rather than the model's general knowledge, which in regulated work is most of the time. It is also what makes an output explainable, because you can show exactly what it was based on. We explain it plainly in RAG explained. **Can you automate client onboarding and KYC?** Yes, and it is one of the clearest wins in professional services. We automate the gathering and chasing of documents, extract and check the data inside them, screen against the sources you use, and assemble a clean, auditable file for a human to review and approve. The accountable person still signs off; the hours of collation and follow-up largely disappear. We go deep on this in AI for KYC and client take-on, and it is core to our work in trust and corporate services. **Can you help with fund administration tasks like NAV and investor reporting?** Yes. Fund administration is full of repeatable, document-heavy processes that automate well, from NAV support and reconciliations to assembling investor reports and statements from your source data. We build the pipeline that pulls the numbers together, drafts the pack, and flags anything that looks off for a person to check before it goes out. The accuracy comes from grounding in your real data and a human confirming the result. See our fund administration page and automating NAV and investor reporting. **Can you build for a law firm?** Yes, and legal work suits this well because so much of it is reading, comparing and drafting against precedent. We build document review that flags clauses and inconsistencies, drafting assistants grounded in your own templates and matter files, and tools that summarise long bundles down to what matters. The lawyer stays firmly in charge: the system does the first pass, the fee-earner exercises the judgement. We set out what is realistic, and what is not, in AI for law firms. **Can you build for an accountancy practice?** Yes. Practices carry a lot of routine, deadline-driven processing that automation lifts straight off the team: sorting and coding documents, pulling figures from statements and invoices, drafting standard client correspondence, and answering internal queries against your own guidance. The result is fewer late nights in busy season and a cleaner audit trail, not fewer accountants. The judgement stays human. We cover the practical starting points in AI for accountancy practices. **Can you build internal assistants or chatbots over our own documents?** Yes, and it is one of the fastest wins available. We build assistants that answer questions from your own policies, procedures and files, using retrieval so every answer is grounded in your material and cites its source rather than making something up. That turns the shared drive nobody can navigate into something your team can just ask. It stays inside your control, it logs what was asked and answered, and it says 'I do not know' rather than guessing when the answer is not in your documents. **What are the limits, what can AI NOT reliably do yet?** Plenty, and we would rather be straight about it. AI models are probabilistic, so on their own they can be confidently wrong, which is why we never let one make an unchecked high-stakes decision. They should not be trusted for final legal or regulatory judgement, for anything requiring true accountability, or for tasks where a rare error is catastrophic and undetectable. They are weak where your process is undocumented or your data is a mess, because there is nothing solid to ground them in. The fix is design, grounding, a human check and an audit trail, not blind faith. **Where should we start if we have never automated anything?** With the smallest painful workflow, not the grandest vision. Pick one task that is repetitive, done often, and quietly draining a person's week, and automate just that. It is low risk, it proves the value in weeks, and it teaches your team what good looks like before you commit to anything bigger. That is the whole philosophy behind a Roadmap, which lands a costed plan in four to six weeks from £15k. We wrote the starting guide in where to start with AI, or you can just book a call. ### Security, data and confidentiality How we handle your data and confidential information, and where it goes when AI is involved. **How do you handle our data and confidential information?** Carefully, and under a signed NDA before we see anything sensitive. Your data is encrypted in transit and at rest, kept segregated by project rather than pooled, and used only for your engagement and never for anything else. We work to data minimisation from the start, so a workflow carries only the data it genuinely needs, and we document exactly where that data flows so your compliance team can review it. During Design we agree the handling rules in writing, which is also what a supervisor will expect to see. **Is our data used to train AI models?** On the business and enterprise API terms we build against, generally not, and we design deliberately to keep it that way. The major providers separate their commercial API tiers, where inputs are not used for training, from their consumer products, where they may be. We build on the commercial tiers, verify the specific terms for the tier a given workflow uses, and document what we find rather than asking you to take it on trust. Where the requirement is absolute, we can self-host components so sensitive data never reaches a third-party model at all. **Where does our data actually go when using these AI tools?** It depends on the component, and we map every path during Design so there are no surprises. AI reasoning steps are processed through the provider's business or enterprise API under commercial terms, sent for the request and not retained for training. Self-hostable components such as the n8n automation layer run in your own environment, so the data they handle never leaves your control. We produce a written data-flow map showing exactly where each piece of information travels and where it rests, because in a regulated firm you have to be able to answer that question. Our piece on AI and data protection sets out why it matters. **Do you sign NDAs and confidentiality agreements?** Yes, before any discovery work begins. We do not need to see a single confidential document to have a first conversation, but the moment real data or real systems come into it, an NDA is in place first. We are happy to work under your paper or ours, whichever your firm prefers. For regulated firms this is table stakes, and we treat it that way rather than as a formality to rush through. **How do you keep different client matters segregated and confidential?** Each engagement is kept in its own space, with its own credentials, storage and access, so one client's data is never mixed with another's. We do not pool data across projects, and staff only have access to the engagements they are working on. Within a build, we design the same discipline into your own system, so where your firm handles multiple clients or matters, the workflow respects those boundaries rather than blurring them. Segregation is a design requirement from the first day, not a setting we remember to switch on at the end. **Can our data stay in the UK or EU for residency reasons?** Yes, where residency is a requirement we design for it, and it often is in regulated work. Self-hosted components can run in a UK or EU region of your cloud tenancy, and where a hosted AI service is involved we select providers and regions that meet your residency obligations. We agree the residency rules during Design and document where each piece of data is processed and stored, so your compliance team has a clear answer. We go through the detail, including the Jersey angle, in AI and data protection under UK GDPR and the Jersey law. **Can you self-host so nothing sensitive leaves our environment?** Yes, and for the most sensitive work it is often the right call. n8n, our default automation platform, is self-hostable, so it can run inside your own cloud tenancy or infrastructure with your data never leaving your control. That lets us keep the orchestration, the storage and the logging entirely in your environment, and reach out to an external AI model only for the specific reasoning step that needs it, or not at all where a self-hosted model fits. We agree the boundary during Design: what stays inside, what leaves, and why. For a lot of regulated firms that combination of self-hosting and auditability is decisive. **What security documentation can you provide?** The documentation you need to satisfy your own governance, available on request. That typically includes the data-flow map, the list of systems and providers involved with their terms, the access model, and the encryption and retention arrangements for the workflow we have built. We produce this as a matter of course during Design rather than scrambling for it when a supervisor or a client asks. If your firm has a specific security questionnaire or due-diligence process, we will complete it, and we would rather over-document than leave a gap. **How is access controlled, and who can see what?** On a least-privilege basis: people and systems get the minimum access they need to do the job, and no more. Access is role-based, so a reviewer, an operator and an administrator see different things, and it is logged, so you can show who touched what and when. That logging feeds the same audit trail that makes the whole system explainable to a regulator. When someone leaves or changes role, access changes with them, and we document the model so your compliance team can see exactly who can reach what. ### Compliance and regulation AI in a regulated firm, built so the regulator nods rather than flinches. **Is it actually safe and compliant to use AI in a regulated firm?** Yes, when it is governed properly, and that is the whole of our approach. Regulators are not banning AI. They are asking who owns it, whether you can explain what it does, and what happens when it gets something wrong. We build so those questions have answers from day one: a named owner, an audit trail, and a human in the loop where it counts. Used that way, AI strengthens your control environment rather than threatening it. **What does the JFSC expect when we use AI?** The JFSC has taken a principles-based, proportionate stance built around governance, explainability, human oversight and accountable leadership, rather than a prescriptive rulebook. In practice that means effort should scale with the harm a use case could cause, and someone senior owns the decision. We unpacked what that means in practice in the JFSC's AI guidance and what it means for your firm and set out a working framework in AI governance for Channel Islands firms. Treat both as our interpretation, not legal advice. **Does the EU AI Act apply to us, and what about UK rules?** It might, even from the Channel Islands or the UK, depending on where your outputs are used and who your clients are. The EU AI Act tiers obligations by risk, while the UK and Jersey lean on existing principles-based regulation rather than a single AI statute. The practical answer is to tier your own use cases by risk and document the high-stakes ones, which satisfies the spirit of all of them. We go through this in the EU AI Act and UK rules for professional services firms. **How do you keep AI auditable?** Every material AI decision leaves a record: the input, the model and prompt version, the output, and who reviewed or approved it. Built in from the start this is nearly free. Retrofitted after a supervisor asks, it is painful and sometimes impossible, which is why we never leave it to the end. Our piece on building an AI audit trail sets out exactly what to capture and why. **What do you mean by keeping a human in the loop?** For anything high-stakes, a person reviews and can override the output before it takes effect, and that review is genuine rather than a rubber stamp. The level of oversight scales with the risk: light for a drafted internal note, firm for anything that reaches a client, a payment or a regulatory return. If the reviewer cannot realistically catch an error in the time they are given, that is not oversight, it is theatre. We explain the distinction in human-in-the-loop AI. **Can AI decisions be explained to a regulator or a client?** They have to be, so we build for it. We favour approaches that cite their sources and show their working, such as retrieval-augmented generation, over opaque systems that produce an answer with no trail. Combined with prompt versioning and the audit log, that means for any given output you can show what information it was based on, which version of the system produced it, and who signed it off. That is what explainability means in a regulated setting. **How do you handle GDPR and the Jersey data protection law?** As a first-class design requirement, not a box ticked at the end. That means a lawful basis for the data an AI system touches, data minimisation so prompts carry only what they need, clarity on where data is processed and retained, and a data protection impact assessment for genuinely high-risk uses. We cover the detail in AI and data protection under UK GDPR and the Jersey law, and we document the data flows so your compliance team can review them. **Will using AI create a problem in a regulatory inspection?** Not if it is governed, and often the opposite. A well-built AI workflow can leave a cleaner, more consistent audit trail than a manual process ever did, because every step is logged. The firms that get into trouble are the ones running ungoverned shadow AI that nobody assessed. The fix is not to ban it, it is to bring it into the light with an owner, a register and a risk tier, which a Roadmap sets up in four to six weeks. **Do you provide governance frameworks and policies, or just build things?** Both, because one without the other fails. Alongside the systems we build, we help you stand up the governance that surrounds them: a named owner, an AI register, risk tiering, a one-page usage policy people actually read, and audit trails by default. A firm of 20 to 250 people can stand up the whole framework in four to six weeks without pausing live work. That is the spine of our Roadmap. **Is AI output reliable enough to trust in regulated work?** On its own, not for high-stakes decisions, and we would never claim otherwise. AI models are probabilistic, so they can be confidently wrong. The answer is not to avoid them but to design around it: retrieval that grounds answers in your real documents, a human check on anything that matters, and an audit trail that catches drift. Used that way, AI is reliable enough to take real work off your team while keeping the accountable human firmly in charge. ### Adoption, team and support How your team uses what we build, what happens after go-live, and who keeps it running. **Will my team need technical expertise to use what you build?** No. We build for the people who do the work, not for engineers, so the day-to-day experience is a form to fill, a button to click, or a draft that lands in the tool your team already uses. The clever part sits underneath and stays out of the way. If a workflow can only be run by someone technical, we have built it wrong. During Operate we watch real users touch it and smooth off anything that trips them up before we call it done. **What training and documentation do you provide?** Every build ships with training and a written record, because a system nobody understands is a system nobody uses. We run hands-on sessions with the people who will actually operate the workflow, not a one-off demo for management. Alongside that you get plain-language documentation: what the system does, how to run it, what to check, and what to do when something looks off. We also document the technical side, the prompt versions and the data flows, so your team or your IT provider can maintain it without us in the room. **What support do we get after go-live?** Every Build Sprint includes 60 days of stabilisation support after go-live, and this is when most of the real learning happens. Live use surfaces the edge cases that no amount of staging can, so we monitor, fix and tune while your team settles into the new way of working. If you want support to continue past those 60 days, an Operating Partner retainer from £6k a month keeps us on hand for monitoring, changes and the next build. The stabilisation period is included in the Sprint price, not billed on top. **What happens if we want changes after delivery?** Small fixes and tweaks during the 60-day stabilisation window are part of the Build Sprint, so if something needs adjusting once real work flows through it, we adjust it. Larger changes, new features or a second workflow are handled as transparent change requests: we scope the work, put a price and a timeline on it, and you decide. Many firms find that once the first build proves itself, the pipeline of useful changes never really stops, which is why they move onto an Operating Partner retainer rather than raising a request each time. Either route works, and we will tell you which is cheaper for what you want. **Do we own what you build, or are we dependent on you?** You own it outright. The workflows, the prompts, the configuration and the documentation are yours, and we hand them over so nothing depends on us continuing. We build deliberately to avoid lock-in, favouring self-hostable components and open standards over anything that would hold your automations hostage. If you want to run it on your own infrastructure and never speak to us again, you can. We would rather earn the next engagement than trap you into it, and our tools approach is built around that principle. **What if we want to bring it fully in-house later?** That is a clean handover, and we design for it from the start. Because everything is documented, the prompts are versioned and the workflows are transparent rather than a black box, any competent engineer or technical operator can pick the system up and run it. We will walk your team or your IT provider through it directly, hand over the credentials and the configuration, and stay available for questions during the transition. The test we set ourselves is simple: could a capable team we have never met keep this running from the documentation alone? If not, the documentation is not finished. **How do you get staff to actually adopt it?** By involving them from the start and starting small, because the fastest way to kill adoption is to drop a finished system on people who were never asked. We talk to the people who do the work during Discovery, build for the way they actually operate, and put a rough version in front of them early so they shape it rather than inherit it. We pick the smallest painful workflow first, so the win is visible and the disruption is low. A tool that saves someone a genuinely annoying hour every day sells itself, and that is what we aim for. **Who maintains the system once it is live?** Whoever you want, and we make sure that is a real choice rather than a default back to us. Because you own the system and it is fully documented, your own team can maintain it, your existing IT provider can, or we can on an Operating Partner retainer from £6k a month. Most firms start with us close during the 60-day stabilisation period, then decide based on how much change they expect. If the workflow is stable and rarely touched, in-house maintenance is often the sensible call, and we will say so. **How reliable is it, and what happens if something breaks?** We build for the day something goes wrong, because in a live workflow it eventually will. Every system ships with error handling, so a failed step retries or fails safely rather than corrupting your data or vanishing silently. We add monitoring and alerting, so a broken integration or a runaway process is caught early and someone is told, rather than discovered by a client. During the 60-day stabilisation on a Build Sprint we are watching those alerts with you, and on an Operating Partner retainer we keep watching after. A human stays in the loop on anything high-stakes, so a wrong output is caught before it reaches a client or a regulator. ### Results and ROI How we measure success, what to expect, and what happens if a build falls short. **How do you measure ROI and success?** Against a single number we agree before we start, usually hours saved or capacity freed on a specific workflow. If a target is too fuzzy to measure, we do not take the work, because an outcome you cannot count is an outcome you cannot defend to a board. During Design we build an ROI model that puts the run rate against the time saved, so the return is a figure rather than a feeling. We set out how we do the sums in how to measure AI ROI, and you can run your own rough estimate with the ROI calculator. **What results can we realistically expect?** For the right workflow, hours back every week and capacity your team gets to redeploy rather than headcount you cut. A document-heavy, repetitive process is where automation earns its keep fastest, taking work that took hours down to minutes with a human checking the output. We will not promise a specific percentage before we have seen your data, because the honest number depends on your volumes and your process. What we will do is put a target on it during Design and structure the Build Sprint so you see working output early rather than waiting for a big reveal. **What if the automation does not work as expected?** We build so that is the exception, and we stand behind it when it happens. Nothing gets built until you have approved a blueprint, and everything is tested against your real data in staging before it goes near production. A Build Sprint then includes 60 days of stabilisation support after go-live, so early issues are ours to fix, not yours to live with. If a system genuinely does not do what we scoped it to do, we make it right or we refund the work. We would rather do that than leave you with something that does not deliver. **Do you guarantee results?** We put a number on the target and stand behind delivering it, which is a stronger promise than a vague guarantee. What we will not do is guarantee a result we have not scoped, because that is how firms end up disappointed. Our safeguard is at the front: we scope narrowly so the target is realistic, test on your real data, and only build against an approved blueprint. If a workflow will not produce a return worth having, we tell you before you spend, not after. **How long until we see a return?** Often within 12 to 18 months, and sometimes a good deal sooner. The build cost is one-off and the time saved is recurring, so a workflow that frees several hours a week starts paying back as soon as it is live and the payback compounds from there. High-volume, repetitive processes cross into profit fastest. We model the expected payback period during Design so you can see the crossover point before you commit, rather than taking it on faith. **How do you avoid the pilot that never reaches production?** By refusing to build one. Most AI pilots stall because they were scoped as experiments with no owner, no path to live and no real data behind them. We work the other way: pick the smallest painful workflow, build it against your actual data, put a named owner on it, and take it to production with training, documentation and monitoring. The Operating Partner retainer exists to keep systems live and improving rather than quietly abandoned. We wrote up the common failure modes in why AI pilots fail. **Can you share case studies or client references?** References, yes. Named case studies, mostly not in public. Our clients are regulated professional services firms, and many would rather their competitors did not know exactly what they have automated, which we respect. What we can do is put you in touch with a reference on a call, under NDA, so you hear about the work directly from someone who has done it with us. If you would like that, ask on your discovery call and we will arrange it. ### About Spark Who we are, where we are, and what we believe about building AI that works. **Where are you based?** Jersey, in the Channel Islands. That is our home and our core market, alongside Guernsey, the Isle of Man and the UK. Being on-island matters because we understand the firms we serve and the rules they answer to, rather than watching from a distance. The work itself is delivered remotely, so distance is rarely a barrier, but the roots are local and deliberate. **Why does a Jersey and Channel Islands base matter?** Because regulatory fluency is most of the value, and it is hard to fake from off-island. We understand what the JFSC expects, and how Guernsey, the Isle of Man and UK regimes differ, so we build for auditability from day one rather than bolting it on after a supervisor asks. Off-island vendors tend to white-label generic tools with no grasp of your control environment. We are local, senior, and we speak the language your regulator and your board already use. **Who is behind Spark?** Spark is founded by Seb Lawson and run as a lean, senior team of operators who happen to know AI, rather than a large agency billing junior hours. You work with the people who do the building. That keeps the overhead low, the fixed prices honest, and the decisions fast. We are delivery people first and technologists second, which is exactly the right way round for this work. There is more on our about page. **Do you work remotely or in person?** Remote-first for the delivery, on-island in person where it genuinely helps. Most of the build, the reviews and the day-to-day happen remotely because that is faster and it is how modern software gets made. But we are based in Jersey, so for a kickoff, a board conversation or a working session with your team, we can be in the room. We use whichever mode moves the work along, not whichever looks busier. **What sectors do you specialise in?** Regulated and professional services first: finance, fund administration, trust and corporate services, wealth, law and accountancy. These are document-heavy, auditable, time-poor businesses, which is exactly where automation pays off fastest. We also work in hospitality, construction and other professional services where back-office automation produces visible ROI in weeks. Our sectors page sets out where we go deepest and why. **What does Spark actually believe about AI?** That the job is to turn idea into system, and everything else is noise. We believe in delivery over decks: a shipped, working workflow beats a strategy presentation every time. We believe in measuring everything, so no recommendation leaves us without a number attached to the outcome. We believe in picking the smallest painful workflow, shipping it, logging every change, and moving to the next. And we believe the hype is the enemy of the work, so we do not sell it. **How do we get started?** A free 30-minute discovery call. You tell us where the pain is, we tell you honestly whether there is a fast win, a bigger build, or nothing worth doing yet. There is no obligation and no deck. If there is a fit, the usual next step is a Roadmap from £15k that hands back a costed plan in four to six weeks. Book the call and we will take it from there. ## Contact - Book a discovery call: https://calendar.notion.so/meet/sebastianlawson/gimr3uka - Email: seb@sparkcuriosityhq.com