The Deal Desk

What you asked for

One place Lorna works from. An email comes in, and sitting next to it is a suggestion — reply like this, chase these documents, approach these lenders. She reads it, changes what she wants, presses approve. It goes. The pipeline updates itself behind her, and she never has to remember to run anything.

You were clear about the limits, and they're the right ones. Nothing goes out without a human seeing it. Lorna directs the AI, not the other way round — partly because of PI and advice liability, and partly for a more practical reason: she takes the follow-up phone call, so she has to know what was actually said.

Everything below is built around that.

What you've already got, and why it wasn't wasted

The Claude and Notion setup did its job. Not as the finished system — as the thing that told you what the finished system needs to be. You couldn't have specified this six months ago. You can now, in detail, because you've run it.

So we keep the thinking and rebuild the plumbing. Your skills, your checklists, your Companies House research, the way you've decided a deal should move — all of that carries over. What doesn't carry over is the architecture, because the four problems you described are all architectural:

• Only you can navigate it. Lorna can't see where anything is.
• The system forgets a conversation the moment someone replies without copying it in.
• A single skill generated 20+ tasks a day, so you turned it off.
• Lender knowledge only ever grew. Nothing could be corrected or retired.

Straight answer on the Anthropic question

You said you want to own the stack rather than depend on Anthropic. You're right about the risk, but it's worth being precise about where the risk actually sits, because it changes what we build.

In the new system the runtime is ours: our server, our database, our code, our prompts. The model is a single line of configuration. We can point it at Claude, GPT, Gemini or something running on a machine in the office, and swap it in an afternoon without touching anything else.

That's what owning the stack actually means, and it's a stronger position than refusing a particular model on principle — which would cost us output quality without removing any real dependency.

What's underneath

Three parts, deliberately separate.

The CRM

An off-the-shelf system we host ourselves. Companies, people, deals, tasks, notes. We're not building a CRM and, more importantly, we're not maintaining one for the next ten years. You and Oliver can open it directly and browse the pipeline without anyone building you a screen first.

The desk

The new piece, and the one that does the thinking. It reads the mailbox, works out what to suggest, holds the approval queue, and joins everything together. This is Lorna's screen.

The lender engine

Already built, already running, and it doesn't change.

The part that's further ahead than you think

The lender engine behind the fundability tool already holds 130 lenders and 327 products, normalised out of 168 source documents.

It also records, field by field, whether a criterion came from the lender's own paperwork or was inferred — with the sentence and the page number. So when it says a lender's minimum is £150k, we can show you where that came from, or admit that we're guessing.

That's the thing you told me was missing from your own lender data, and it's the hardest and slowest part of a build like this. It's done. The deal desk plugs straight into it.

How it gets smarter

This is the bit I want you to look at hardest, because it's where systems like this usually go wrong.

A lender declines because the business has only traded eleven months. Lorna confirms the reason with one click — that's her entire involvement.

The system records it as a belief: something we think is true, with the lender's own words attached and a confidence score. See it again, confidence rises. See it contradicted, confidence falls and the reason gets recorded alongside it.

Two things follow. Straight away, the next time a young business comes up and that lender is on the shortlist, it warns us before the approach is drafted — quoting the email it learned from. And over time, once a belief has proven itself, it gets promoted into a hard rule — but only when someone signs it off.

Beliefs get superseded. Appetite notes expire on a date. Confidence decays if nothing confirms it. That's the difference between this and a knowledge base that just gets bigger, slower and less accurate — which is what happens to almost all of them, and what was starting to happen to yours.

And when appetite shifts, correcting it is a conversation with the system, not a data-entry job.

What stops it doing something daft

The 20-tasks-a-day problem can't recur, because it's prevented in the database rather than in a prompt. Duplicate suggestions are structurally impossible, there are hard caps per deal and per day, and any suggestion nobody acts on disappears after three days. The list can't silently pile up.

On sending: nothing leaves without an approval. For the first half of the build the system won't even hold permission to send email from Google — so "it cannot email a client on its own" is something Oliver can verify in the admin console rather than take on trust.

The phases

I'd rather commit properly to the first three phases, let Lorna live in it for a fortnight, and scope the rest once we know how she actually uses it — not how we imagine she will.

What I need from you

1 · The qualification checklist — this is the one that blocks everything

Phase 3 rests on "the system governs the go/no-go" — but the actual rules only exist in your head. I need the standard asks and the internal questions, per product type, written down by you and Oliver. If I write them, I'm inventing underwriting policy, which is exactly the exposure we're both trying to avoid.

2 · The rest of the Notion export and the Claude skills

The Companies database has landed. The pipeline, lenders, actions and contacts haven't.

3 · Half an hour of Lorna's time, watching her work

Every requirement in this document is you describing her job. Before I design her screen, I'd like to see her do it.

4 · From Oliver, three things

Sign-off that a human approving every outbound message satisfies the compliance position; a decision on how long we keep client documents; and a written position on the point below.

5 · A decision on client data and the AI provider

To draft a reply or read a lender's response, the system has to send that content to an AI provider — which means client names, figures and company details leave our systems. That's true of any tool of this kind, including the one you're running now, but it hasn't been written down anywhere and Eynsham is the data controller.

My recommendation: route only through providers contractually bound not to retain or train on what we send, verify that's what actually happens rather than trusting a setting, send the minimum needed for each task, and name the providers in Eynsham's processor register alongside the others. If Oliver isn't comfortable with that, there's a workable fallback — the reading and sorting can run on a machine in our own control, and only the drafting step, which needs far less context, goes out.

This needs deciding before we build the drafting phase, because it can change the design.

Two things you should know