AIConsultingThatEndsWithaPlanYouOwn

Consulting decides what to build. Automation is the building. If you already know the job you want handled, you can skip straight to AI automation and we'll scope and price that job directly. Consulting is for the earlier problem, which is knowing AI should be doing something for you without knowing which something is worth the money. Plenty of businesses genuinely don't need the consulting step, and we'll tell you on the first call if you're one of them.

No, and the plan is deliberately written so you do not have to. It includes enough detail for another developer to quote from it, and you own it outright the moment it's delivered. We would obviously like to build it, but a recommendation you can only act on by hiring the person who wrote it isn't advice. It's a sales document.

It depends on how much there's to map, and we would rather quote it properly than put a misleading number on a web page. A single-location practice with a handful of processes is a very different piece of work than a business running four systems that all have to agree with each other. On a 30-minute call we can usually tell you roughly where you land and what the deliverable would be. Book an introductory call and we will scope it properly rather than guess at it here.

Then that's what the report says, and you've saved yourself a build plus the infrastructure and the maintenance that come with it. Often the job runs the same way every time, and a plain deterministic workflow repeating those steps is cheaper, more predictable and easier to fix than anything with a model in it. A lot of what gets sold as an AI problem is really a follow-up problem, where quotes go out and nobody chases them, and that's marketing automation at a fraction of the cost. Sometimes it's a lead problem, where enquiries are scattered across four inboxes nobody checks together, which is lead management. Telling you that's the job.

Most engagements run two to four weeks from kickoff to the written plan, and the limiting factor is usually how quickly we can get time with your team rather than the analysis itself. You'll have the timeline in writing before it starts. If something is urgent enough that you can't wait, say so on the call and we can look at whether a shorter piece of work would answer your question.

You'll have the sessions we need from you in writing before it starts, rather than discovering them as we go. The shape is a kickoff with you, a short session each with two or three of the people who actually do the job, and a walkthrough at the end once the plan is ready. Everything between those happens on our side. If the scope turns out to need more of your team than that, you'll hear it before anything gets booked.

We sign an NDA whenever you want one, and we'll use yours if you have one. Most of the mapping runs on walkthroughs and screen shares with your team driving, so plenty of it never needs a login at all. Some of it does. Working out whether your booking system can actually be written into, or what fields exist on a record, sometimes means looking inside it properly. When that comes up we'll tell you what we need and why before we ask, take read-only access on a named account rather than a shared one, and have it revoked when the engagement ends. We don't need to read patient files or client matters to write the map, so where a screen has real information on it we'll work from a test record or ask you to blank it first.

Sometimes it is, and that's worth saying plainly rather than finding out three weeks in. This works best where the owner is still personally absorbing work that should have been handed off, which is a common position at roughly five to fifty staff. Below that the numbers often don't work, because the hours you'd save don't cover what a build costs to make and then keep running. If you're smaller than that, the question is which problem you actually have. If the phone isn't ringing because nobody knows you exist, no amount of AI manufactures demand that isn't there, and the SEO or ads conversation is the right one. If enquiries do arrive and then die because nobody chased them, that's worth automating even at two people, and lead management or follow-up automation costs a fraction of a scoping engagement. You'd hear which of those you're on during the first call, not after you'd paid for anything.

Whichever ones fit your constraints, and we're not resellers for any of them, so there's no commission steering the answer. Models get deprecated, change their pricing and have bad days, so anything we recommend is built to swap rather than hard-wired to one provider. Where residency matters we'll typically point at AWS Bedrock in the Montreal and Calgary regions for Canadian data, or a US region for a US business, and where it matters less there are cheaper and faster options including open-weight models. The reasoning goes in the plan so you can challenge it.

They go down, and every provider has bad days, so nothing we recommend gets hard-wired to one of them. Where it makes sense the system routes through a layer like OpenRouter with a second and third model configured behind the first, so when one stops responding the work carries on instead of queuing up behind a company you have no control over. The part worth being straight about is that a fallback isn't a like-for-like swap, because models phrase things differently and are stronger at some jobs than others. So the backup gets tested against your actual work and tuned before it is ever needed, and where the difference would matter to a customer we would rather hold the job for a person than let a second choice answer on your behalf. Underneath all of it sits that plain fallback to a human queue, because a system that only works while every part is healthy isn't finished.

That's a real option and sometimes it's the right one. Open-weight models like Kimi, GLM and DeepSeek can run inside infrastructure you control, which is the strongest answer available if the worry is that your data should never reach a third-party provider at all. The trade is that you rent the machine they run on whether or not anybody uses the system that day, so the sums work out differently from paying per request, and the gap widens the quieter your volumes are. Sometimes an open model on your own infrastructure is cheaper and cleaner. Sometimes a hosted provider in a region you picked is both cheaper and far less to maintain. You get both sets of numbers rather than our preference.

Yes. We're based in Brantford, Ontario and most of our clients are Canadian, and we've delivered web and marketing work for businesses in the United States and the United Kingdom. None of this depends on being in the room, and where your data sits is a setting rather than a limit. Time zones are the only genuine friction, and we can work out on the first call whether the overlap suits how you like to run things.

Camrin does. You're not handed to a junior after the sales call, because there's no sales team to hand you off from. That's the honest limit on how many of these we can run at once, and it's also why the read you get comes from somebody who has built and operated these systems rather than somebody working from a framework.