I gave Claude access to my entire business, and filmed what happened

I have built a lot of automations. Webhooks, branch logic, mapping tables, the HTML email template that took an afternoon and broke the first time a client’s name had an apostrophe in it. Every one of them answers exactly one question, and the business immediately asks a different one.

So I connected Claude to the actual systems my business runs on, gave it three jobs I would normally have built a workflow for, and recorded all of it without cutting out the parts that went wrong.

Everything below is what actually happened in the recording, with the timestamps so you can check my working.

The setup, in about ninety seconds

Four connectors: ServiceM8, Gmail, Google Calendar and LeadConnector. Connecting one is an OAuth round trip and nothing else. Note that some connectors cap at one connection per workspace, which is usually not a limit so much as a fact about the vendor: a business has one ServiceM8, so a workspace gets one ServiceM8.

Then a profile, which is the part worth understanding, because it is the thing Claude actually talks to. A profile gathers the connections and the specific tools you want available and turns them into a single MCP endpoint. I made one called operations and described it as day to day operations of FloConnector, and that description is not decoration: the model reads it, and it shapes what the model reaches for.

The way I think about a profile is a role, or a task. Marketing operations. Month end. Quoting. Not “everything I own”.

The part that trips people up is that there are four separate places to say no, and they do different jobs (2:58):

The first two blur together, because you set them a minute apart in two places that look similar. The difference is reach: a tool killed at the connector is gone everywhere, and a tool turned off in a profile is still there for the profile that legitimately needs it.

The fourth one is the one I would demonstrate to a nervous client. In the video I deliberately try to authorise with an address that is not assigned to the profile and it refuses (7:45). Handing someone the endpoint URL is not handing them your business, which matters the first time an agency has three staff and one of them should not be seeing the accounting connector.

There is also an AI tool picker: I typed “quoting tools”, it read every tool description in the connector and came back with 17. It included list_jobs, which looks wrong until you think about what quoting actually needs.

Connecting it to Claude is pasting the endpoint URL into Settings, Connectors, Add custom connector (6:14). Sign in, approve, done.

One detail from 9:11 that matters more than it looks. Every profile carries three tools of ours that you did not pick: flc_about, which tells the model the profile’s name, purpose and what it is holding, and flc_load and flc_query, which I will come back to. Those three are what load up front. The rest are found by search when the model needs them, which is why a profile can carry a hundred and sixty tools without costing you a hundred and sixty tool definitions before you have typed anything. I wrote about why that matters and about what happens when you skip it.

One: a lead in the inbox becomes a job

The first one is the workflow every trades and property business has some version of. An enquiry lands in an inbox and somebody retypes it into the job system.

That is deliberately vague about the middle. I did not tell it which category, or which forms, or that it should check whether the client already exists. Four minutes later (13:29):

• It searched for an existing client, found none, and said so before creating a fresh one.
• It created the job as a work order rather than a quote, having decided from the email that this was work to be done, not work to be priced.
• It listed the categories already in the account, picked “burst pipes and leaks”, and did not invent a new one. That restraint is the difference between a useful integration and a category list that has four spellings of “plumbing” by March.
• It attached a safety form and a job completion form.

It also got something wrong, and I left it in. It offered to attach the photo from the email, fetched the image, and then could not upload it, because that tool does not exist yet. It failed at the last step rather than at the first, which is the honest failure mode for a connector platform: the model will reach for anything you have described to it, and if the reach is not there it finds out late.

The other miss is my fault. It did not put the client’s email address on the job, because the test email came from me, and my address is not the lead’s address. It was right and my test data was wrong.

Two: a quiet pipeline gets chased

Second scenario, a CRM. In LeadConnector there is a pipeline with new leads, contacted, a ServiceM8 stage and a few completed (15:11).

Nine open opportunities, five new and four contacted. Most of that is seeded demo data, and the first useful thing it did was notice that and say so rather than dutifully drafting emails to test@example.com.

Then it ranked what was left and named its two best conversion candidates, Olivia and James, with reasons. I want to be careful about how much credit to give here, because the sample was tiny. But the shape of the answer is the thing: it read the pipeline as a pipeline, not as rows.

The part I did not expect: it looked at the stage names, found the one called ServiceM8, and worked out what it was for. That stage exists because I built an automation behind it. An opportunity lands there and a job gets created. It inferred the intent of my automation from a stage name, and offered to use it.

Which does raise the obvious question about the automation. If you can just say “move this to the ServiceM8 stage and create the job”, the trigger is doing less work than it used to.

So I asked for exactly that, plus setting the opportunity to A1, and it did all three (18:31). It also reasoned that an A1 opportunity should be a work order rather than a quote, on its own, which is the same call it made in the first scenario from completely different evidence.

Two things about the email. First, it drafted and asked before sending, even though it had the ability to send. It is conservative by default and I would rather that than the opposite. Second, when I pointed it at the tool that sends email from inside a ServiceM8 job, it wrote a properly formatted HTML email and sent it from there, so the message landed in the job diary where the next person to open the job will see it. I have spent whole afternoons on HTML email templates that ended up worse than that one.

Three: a remittance marks off a month of invoices

The last one is not glamorous and it is the one I would actually pay for (20:27).

A client sends a remittance covering every job you invoiced that month. ServiceM8 has no bulk way to mark those as paid. You open each invoice and do it by hand.

I dropped the remittance in and asked it to mark them all off as paid, regardless of dates, because the money was already in the bank.

It went through the document, matched the lines to the jobs, and recorded a bank transfer payment against each invoice. Then it asked whether I wanted purchase order numbers attached where they matched, I said just use the invoice number, and it did that too.

The two tools doing the quiet work here are flc_load and flc_query, and the part at 23:12 is worth pausing on, because it is the difference between a demo and something that survives contact with a real account.

Ask “how many burst pipe jobs did we do over the last five years” of an account holding a hundred thousand jobs, and the obvious approach fetches a hundred thousand jobs and dies.

So the rows go into a temporary, in-memory analytics workspace that lives about ten minutes, the model writes a query against it, and what comes back is the answer rather than the data. I wrote up why we built it that way rather than running model-written code in a sandbox, including where the approach loses.

What this actually replaces

None of the three workflows above are new capabilities. I could build all of them. I have built versions of all of them.

The difference is that each one took a sentence, and none of them needed to be right in advance. The remittance one is the clearest case: I would never have built that automation, because the format changes per client, the volume is a few times a month, and the payoff would not have covered the build. It sat in the “annoying, do it manually” pile forever. Those piles are where most of the time actually goes.

What I would not claim: that it is fast. Each of these took roughly four minutes, and it thinks out loud the whole way. It is not fast, it is unattended, and those are different products.

What I would not claim either: that you should hand it everything. Two of the three limits I set at the start of the video exist for a reason, and the whole reason a profile is a role rather than an account is so that the answer to “what could it possibly do” stays short enough to read. If you want the underlying guarantee, the AI never holds a credential at any point in any of this: the tokens live server side, encrypted, and the model never sees one.

Running it without you

The last bit of the video (24:32) is the obvious follow up. Everything above was me typing. Claude has scheduled tasks, and ChatGPT now does too, so the same request can run on a timer: a daily briefing at seven, yesterday’s jobs and what is outstanding, emailed to me before I open a laptop.

That is where narrow profiles earn their keep. A scheduled task that runs unattended should be pointed at a profile holding the eight tools that job needs, not the hundred and sixty your day to day profile carries. Build the profile for the task, and the blast radius of the schedule is the profile.

Try it

FloConnector is in beta and moving quickly. Signing up gives you 1,000 credits, and the code YT5000 adds 5,000 more on top of that for the first ten people who use it.

If the connector you need is not there yet, tell us on the feedback board rather than assuming. We are deliberately not seeding fifty connectors nobody asked for, so what gets built next is genuinely decided by what people request.

Written by

David List

Founder, FloConnector

Building the hosted MCP layer that lets a business's AI actually run its software. Previously deep in field-service and accounting integrations.

floconnector.com