Straight answers

"What happens when it gets something wrong?"

It will sometimes be wrong. Anyone who tells you otherwise is selling something. The design answer: nothing consequential happens on the system's say-so alone. It prepares, checks against your records and rules, and shows its working. One of your people reviews and approves before anything reaches a customer. When the evidence behind an answer is thin, the system is built to flag that instead of sounding confident. So a wrong draft costs you a correction, not a customer.

"Does everything always need a person to check it?"

At the start, yes, always. Every system I build starts with a person reviewing and approving before anything reaches a customer, no exceptions. Once a specific action has been checked correctly enough times that the pattern is genuinely proven, some businesses choose to let that one action run on its own from then on. That's your call to make later, with evidence in front of you, never a default I switch on quietly.

"Where does our data go?"

A fair question, and one that gets a specific answer for your setup before anything is built, in writing. The principles: your records stay yours; nothing you give me gets used to train someone else's public model; and who can see what is agreed explicitly, not assumed. If a workflow touches genuinely sensitive data, that shapes the design from day one or rules it out.

"Will my team hate this?"

Not if it's done honestly. The judgement calls stay with your people; the system takes the drudge work of preparing, checking and drafting. Nobody's expertise is being replaced by a chatbot, and I won't help you pretend otherwise. Where a workflow changes how someone works, they're involved in testing it, because they know where it really hurts. If your actual goal is cutting heads, I'm the wrong consultant.

"Will we be locked into you?"

No, and this is a design decision, not a promise. You own the system, the records, the rules and the documentation. It's exportable, the handover is part of the job, and the AI models underneath are swappable. Support is available because it's useful, not because you're trapped.

"Is this a big disruptive project?"

It starts as the opposite: one bounded workflow, fitted around how you already work, standing on its own. If it proves useful and the evidence points to more, expanding is your decision, made from results. Nothing here starts with a programme, a roadmap or the word "journey".

"You're new. Why would we go first?"

Because you'll see it working before you spend anything. Fine Kilter is new as a practice, and this site doesn't dress that up: no invented case studies, no borrowed logos. What you're judging is a worked example taken end to end, a published method, and operating experience from inside a real business. And an early client gets more of my attention than a fiftieth client ever would.

"We already use ChatGPT a bit."

Good, that's useful evidence that your team sees the point. But scattered tool use isn't an operating capability. The difference is everything around the AI: your records feeding it, your rules constraining it, checks, approval points, and ownership. The models themselves are capable, and they are interchangeable. What is usually missing is your context, written down in a form the system can actually work from. That is what I build.

"What do we actually end up with?"

A working system, and the thing underneath it: how that piece of your business really runs, written down properly. The records you work from, the rules you apply, the judgement calls your people make and what they are based on, all separated out so any part can be checked or changed on its own.

That written-down version is not a report I hand over at the end. It is what the system reads every time it does a piece of work, which is why it stays accurate instead of going stale in a drawer. It is also why the system runs against how your business actually operates rather than general knowledge about businesses like yours.

And it is yours. If we stop working together, nothing has to be rebuilt.

"Who maintains it after you leave?"

It needs maintaining, and pretending otherwise would be the "set and forget" lie. Rules change, records grow, models improve. The handover covers who does what, and ongoing care is available if you'd rather I did it. Either way, the maintenance question gets answered before the build finishes, not discovered afterwards.