Is this a problem with Claude specifically, or with all of them?

All of them. It isn't a model quality issue. Any model writing about a client relationship it can't see is going to produce something generic, and swapping vendors moves nothing.

We wrote a really detailed prompt. Isn't that the same as context?

It gets you a long way, and a good prompt is worth writing. The limit is that it only holds what you thought to type at the time, it doesn't update when the business changes, and you have to bring it every time. Connected systems don't need you present.

How much does the connection work cost compared to the seats?

More than the seats, and that surprises people. The subscription is the cheap part. The reason the subscription looks wasted is that nobody funded the part that makes it work.

Can't somebody on our team just write the skills themselves?

Probably, yes. Writing a skill that works is not the hard part and most technical people can prompt their way to one. It's the plumbing underneath it that decides whether the thing still runs in three months.

Where do we start if our data is a mess?

At the bottom. Find out what isn't being recorded and what nobody has agreed on the definition of, and fix that first. The nine-constraint map lays out the order.

Why Your Team Isn't Using AI | Janaitis Business Systems

The way it usually comes up is somebody telling me they already tried. They bought the Claude subscription, they had it write a few client emails, and what came back was close. Not close enough to send, but close. So it sits there, the seats renew, and the honest summary is that it was a neat demo and nothing changed.

AI underperforms inside most mid-market businesses for one reason, and it isn’t the model. It’s that nothing connects the AI to the systems holding your business’s data, so every session starts from zero and every good result you get has to be hand-fed and then thrown away.

That’s a fixable problem, and it’s a different problem than the one most people think they have.

What does it mean to say the problem is “context”?

Context is everything your business already knows that the model can’t see. Who this client is, what you quoted them last spring, how the last three conversations went, what you charge, how you write when you’re annoyed, which of your people owns the account.

You have all of that. It’s sitting in your CRM, your email, your calendar, your meeting transcripts in Fathom or Fireflies, your ticketing system in ClickUp or Monday or Asana, your spreadsheets in Google Workspace or Office 365, and your accounting in QuickBooks. Claude has none of it. So when it writes you a bad email, what it’s doing is writing to a stranger on your behalf, about a relationship it has never heard of.

The fix is to connect those systems to it. A prompt that describes them is a different thing, and it doesn’t hold.

Why does uploading your five best emails stop working?

Because you’ll do it once. There’s a workshop pattern that goes around: download your five best LinkedIn posts as PDFs, upload them, run the prompt, and look at how much better the output sounds. It works. The voice really does get closer.

Then next Tuesday you need to write another post, and the five PDFs are gone, and gathering them again takes longer than writing the post yourself. So you don’t.

Same with emails. You can download four or five you’ve written, upload them, and get something in your voice. You can write a very detailed prompt describing exactly how you want to sound and get to about ninety percent. Both of those move the output closer, and neither is something you’ll do every time, which means neither is a system. You’re restarting from the beginning with every new session, and nothing you learned last week is present this week.

The tell is simple. If using the tool takes longer than doing the task, your team has already stopped using the tool.

What’s the smallest thing worth connecting first?

Connect one system your work already flows through, natively, and then set up a loop that records what you change.

Email is usually the right first one, because everything about a client relationship passes through it. For LinkedIn, the smallest version is publishing through a scheduler like Buffer and connecting Claude to that, so it can read everything you’ve already published instead of waiting for you to go find it.

Once the connection exists, here’s the loop I’d run, and it’s the part that compounds:

Pull. Claude drafts the email or the post.
Edit and send. You fix it until it sounds like you, then send it or schedule it. This is the step you were already doing.
Pull again. Tell Claude you sent it, and have it go get the version that went out.
Diff. Have it compare what it wrote against what you sent, and find every place the two differ.
Record. Have it write those differences down as rules.

Pull, diff, record. Do it on two or three emails and the rules base starts building itself. If you open with “Hey Dave” and the draft keeps saying “Hi Dave,” you change it once, it gets written down as a rule, and you never deal with it again. That’s different from the model reading five old emails and guessing at a pattern. That’s your actual preferences, captured at the moment you expressed one.

The change a business can feel the same day is that one: a draft that arrives already carrying the last correction you made, instead of one that needs the same correction again.

The same idea works on the skills themselves. For any skill you write, you can have a second one that reviews it on a schedule, goes out and reads how other people are solving the same problem, and folds what it finds back in. Otherwise the skill you wrote in March is still the skill you wrote in March.

The second mistake: buying the seats and calling it adoption

The first mistake is the missing connection. The second one is handing everybody a login and walking away.

What happens is predictable. A few people take it seriously and get very good at it. Some use it as a search engine twice, decide it’s fine, and go back to typing the question into the browser bar, because getting Google’s AI summary is about as much effort and it’s already open. Most land somewhere in between, and none of that is anybody’s fault. Nobody told them what good use looks like here.

The part that gets missed even in companies that do train people is the sharing. When somebody works out a good way to triage their inbox, or to pull client context before a call, that shouldn’t stay on their machine. It should become a shared skill everyone runs, so the whole company gets the benefit, and so that the next improvement anybody makes reaches everyone at once. Without that, you’re paying for however many private, half-built versions of the same thing.

So how do you know whether you’re ready?

Look at whether the data you’d be pointing it at is any good, before you point it at anything.

AI sits at the top of the nine-constraint map, in the tier where tools finally get to do something. Down at the bottom is whether the work is being recorded at all, whether your people agree on what the numbers mean, and whether entry is clean. If your CRM is only as current as whichever salesperson remembered to type up their call notes, connecting an AI to it gives you a faster way to produce a confident wrong answer.

That’s the honest readiness check, and it has nothing to do with the model you picked.

The short version

Most mid-market businesses aren’t getting anything out of AI because they never connected it to the systems that hold their business. The tool is answering from a blank slate every time, which is why the output reads like a stranger wrote it, and why the workarounds that fix it are all things nobody keeps doing. Connect one system natively, record what you change when you edit the output, and the tool starts getting closer to how you work instead of resetting every Monday.

We pay for AI and nobody uses it