For a small business, AI integration services mostly mean connecting a model you rent from OpenAI or Anthropic to the tools you already run, so it does one narrow job inside them. Start with something dull and high-volume, like sorting inquiries or pulling data out of documents, with a person checking the result. The model's bill for that is usually a few dollars a month, so the money goes into the build and the upkeep.
If you've been told you should "do something with AI", the practical place to start is usually your inbox, not your website. Below is why, and what it costs to run, worked out from the vendors' own published prices.
What is AI integration, in plain terms?
It's connecting a large language model, the kind behind ChatGPT and Claude, to software you already use. Your system sends the model some text through the vendor's API (the interface programs use to talk to each other), the model does one job with it, and the result goes back into your system. You pay per use, and nobody builds or trains a model.
That last point matters, because a lot of what's sold as "AI services" blurs it. For a business with a five-figure budget, training your own model is almost never the answer. Renting a good one and wiring it into your inbox or CRM usually is. That wiring is most of the work, and it's pretty ordinary integration work, the same kind we do when we connect a website to HubSpot or Salesforce.
Are other small businesses doing this yet?
Fewer than you'd think. In the Census Bureau's Business Trends and Outlook Survey, between 17% and 20% of US businesses said they used AI from December 2025 to May 2026, and 20% to 23% expected to within six months. So roughly one business in five.
The split by size is the more interesting part. Over those months AI use went up at firms with 20 or more employees but didn't change significantly at smaller ones, and fewer than 20% of firms with four or fewer employees used it. At firms with 250 or more employees it was 37%. One caveat, though: the survey changed its question in November 2025 to ask about AI "in any business function", so it's worth keeping in mind if you compare these figures with older ones.
So if you haven't started, you're with most small businesses, not behind them. The bigger firms are pulling ahead, though, and that's a decent reason to pick one job and try it properly rather than wait.
What should you build first?
A narrow, repetitive job where a person still checks the result. Sorting incoming inquiries and pulling data out of documents are both good first projects. A customer-facing chatbot usually isn't, because when it gets something wrong, your customer sees it before you do.
The jobs that work best as a first project tend to have four things going for them:
- There's a lot of it. Hundreds of items a month, not a few a week, or the time saved won't pay for the build.
- There's a clear right answer. Sorting sales inquiries from support requests has one you can check, so you'll know quickly if the model is getting it wrong. "Write our brand strategy" doesn't.
- A mistake is easy to fix. If an email gets tagged wrong, someone re-tags it and nothing's lost, but a wrong quote that reaches a customer is a different story.
- The data is already digital. If the input lives on paper or in someone's head, getting it out of there is a different project, and it comes first.
It's the same way we'd scope any first version, starting from where you want to end up, then cutting down to the part that covers most of the need and can launch soonest. An assistant that answers your customers might well be where you end up. It's rarely the right place to start, because you want to learn what the model gets wrong on work your own staff can see and correct.
Picking the process is often the hardest call, and it's one we help with as advisers before anything gets built.
Three workflows and what they cost to run
For the first two workflows below, the model's bill comes to somewhere between 30 cents and $10 a month at the volumes we've assumed. The third, an assistant that answers questions, is where the choice of model really moves the number: from about $6 to well over $100. All prices are as of October 2026.
Models are billed per million tokens, a token being a chunk of text. A token is roughly 3.5 English characters on older Claude models, but the current ones count about 30% more tokens for the same text, so the Claude figures below could run that much higher. Treat all of them as rough sizing, not measurements. The prices are simpler than they look. OpenAI's smallest current model, gpt-6-luna, and Anthropic's Claude Haiku 5.5 both cost $0.10 per million input tokens and $0.50 per million output tokens. The mid-tier gpt-6.1-sol and Claude Sonnet 5.5 both cost $2 in and $10 out (OpenAI's API pricing, Anthropic's API pricing).
| Workflow | Example volume | Small model (Haiku 5.5, gpt-6-luna) | Mid-tier model (Sonnet 5.5, gpt-6.1-sol) |
|---|---|---|---|
| Sorting and logging inquiries | 1,000 messages a month | about $0.30 a month | about $6 a month |
| Pulling data out of documents | 500 documents a month | about $0.50 a month | about $10 a month, or $5 in batches |
| An assistant on your own documents | 2,000 conversations a month | about $6.40 a month | about $128 a month |
The volumes are examples we picked to show the arithmetic, not averages. Swap in your own and the sums work the same way.
1. Sorting and logging inquiries
Every form submission or email gets read by the model, tagged (sales, support, spam), summarized in a couple of lines, and written to your CRM with a suggested reply for whoever picks it up. Nothing goes to the customer until a person sends it.
Say that's 1,000 messages a month, each about 1,500 tokens in (the message plus our instructions to the model) and 300 tokens out. That's 1.5 million input tokens and 0.3 million output. On Haiku 5.5 or gpt-6-luna it comes to $0.15 plus $0.15, so about 30 cents. On Sonnet 5.5 or gpt-6.1-sol it's $3 plus $3, about $6.
In a workflow like this the model is rarely the hard part. What takes time is everything around it, like a form that gets a new field, or a CRM that rejects a record because something's formatted wrong. Those are ordinary integration problems, so that's likely where most of the build hours go.
2. Pulling data out of documents
Intake forms, invoices or PDFs come in, and the model pulls out the fields your system needs. Anything it's unsure about goes to a review queue instead of straight into your records, so a person looks at the hard cases and nobody has to retype the easy ones.
At 500 documents a month, with about 6,000 tokens in and 800 out per document, that's 3 million input tokens and 0.4 million output. On Sonnet 5.5 it's $6 plus $4, about $10 a month. This kind of work can usually wait an hour, which makes it a good fit for batch processing. Anthropic's Batch API gives a 50% discount on input and output tokens for requests that don't need an immediate answer, and OpenAI's batch prices are also half its standard ones. So about $5.
On a small model the same volume is around 50 cents ($0.30 plus $0.20). For clean, typed documents that may be all you need. For messy scans we'd test both models on a few dozen of your real documents before picking one.
3. An assistant that answers from your own documents
Your staff ask questions in plain English and get answers drawn from your policies, price sheets or manuals, with a link to where the answer came from. We'd build it for staff first and open it to customers only once you've seen how it answers. An assistant like this often lives inside a small internal web application with its own login and permissions, so people only see the documents they're allowed to.
Each question sends the relevant documents along with it, so the input side gets heavy. Say 2,000 conversations a month of four questions each, with about 6,000 tokens in and 400 out per question. That's 8,000 questions, 48 million input tokens and 3.2 million output. On Sonnet 5.5 it's $96 plus $32, about $128 a month. On Haiku 5.5 it's $4.80 plus $1.60, about $6.40 (Haiku's price holds for prompts up to 100,000 tokens, well above these).
Prompt caching can bring the bigger figure down. When the same documents go out with question after question, Anthropic charges 0.05 times the base input price to read them back from the cache on Sonnet 5.5, so the repeated part costs a small fraction of the full price, though writing it to the cache in the first place costs a bit more than normal input. How much that saves depends on how much of each request really repeats.
This is the workflow where picking a model is a real decision, and price is only half of it. The mid-tier models cost twenty times as much per token as the small ones, so it's worth running a batch of your real questions through both and comparing the answers before you commit.
Our own default is usually Claude, because in our tests it's done better at the kind of reasoning and analysis that business workflows depend on. For simpler jobs that tends to mean Haiku or Sonnet, and for more complex ones Opus, or even Fable. It's a starting point, though, not a rule. We still look at each project on its own, so some of them end up on a different model.
What do AI integration services cost?
Mostly the build and the upkeep, not the tokens. For the first two workflows, the model bill is likely smaller than a single software subscription. What you pay for is connecting the model to your systems, handling the cases where it gets something wrong, building the review step for your staff, and keeping it working as models and APIs change.
Most of the build is the connection to the CRM, inbox or database the AI works inside, which is ordinary API integration work. The prompt (the instructions the model follows) is a small part by comparison, though it takes testing against real examples to get right. Error handling is the part that's easy to underestimate. You need a plan for when the model sends back something malformed, when the vendor's API is slow or down, or when a document just can't be read.
The build itself is priced like any other custom software, as hours times a rate. The hours depend mostly on how many systems it touches and how many screens your team needs to review and correct its work. We've written about what drives the cost of a web app, and the same drivers apply here. We don't publish prices, because they depend entirely on those details.
Then there's upkeep. Models get retired and replaced, prices change, and the systems on either side of the integration change their APIs too. So plan for some hours every month after launch, and for someone to keep an eye on what the model is actually doing. We'd also put a limit on spending inside the integration itself, so a bug or a flood of spam can't quietly run up the bill.
The things that go wrong after launch are pretty predictable, so we plan for them from the start. The model gives wrong answers, the model you built on gets retired, or the costs creep up.
Wrong answers are easiest to keep down in the design, by asking the model for only as much as the workflow needs, in the narrowest scope that does the job. A model that only has to tag an email has a lot less room to get it wrong than one writing the whole reply.
Retirements shouldn't catch anyone by surprise either. We build in an automated check that flags when a model the integration uses is being retired, either in the CI/CD pipeline (the automated process that tests and deploys the code), as a scheduled job, or both. That way the switch to a newer model happens on your schedule, not the vendor's.
When costs creep up, we look at two things first. One is whether the integration is using the right model, because a less expensive one often does the job just as well, like Haiku in place of Opus. The other is how many tokens each request uses, since there's often input that can be trimmed without changing the result.
For some steps there's a bigger saving, which is to use a model that doesn't write anything at all. Jev, from TypeSafe, is built for quick, structured decisions. You give it the text and the answers it's allowed to give (sales, support or spam, say), and it picks one and returns a probability for each, so it can't drift off and invent a category of its own. As of September 2026 it costs $0.042 per million input tokens, with output free, so the input for tagging the 1,000 messages in the first workflow would come to about 6 cents a month. It can't summarize a message or draft a reply, though, so we'd use it for the sorting step, or for checking another model's draft before a person sees it, and leave the writing to a model like Haiku or Sonnet. We'd still test it on a set of your real examples first, because it can pick the wrong answer from the list just like any other model.
Is your data safe with OpenAI or Anthropic?
Through their APIs, both say they don't train on what you send. OpenAI's data controls page says data sent to its API isn't used to train its models unless you opt in, and by default it keeps abuse-monitoring logs for up to 30 days. Anthropic's commercial terms say it "may not train models on Customer Content from Services."
Those are the terms for the API, which is what an integration runs on. If your staff paste customer data into a chat app on their own accounts, that's a separate question, and it's worth checking which terms cover it.
The vendor's terms only cover what happens once your data arrives, though, so what you send in the first place is still up to you. A triage workflow doesn't need a customer's whole history to tag an email, and an extraction workflow can strip out fields it doesn't need before anything leaves your system. We'd design it to send as little as it can and to keep a log on your side of what went out. And if you work under rules like HIPAA, that's a conversation to have before the build, not after.
When shouldn't you build one?
When a tool you already pay for does the job, or when there isn't enough of the work to matter. If your help desk or CRM has an AI feature that covers it, switching that on costs far less than building anything.
Volume is the other test. If the job is a few items a week, a person with a chat assistant open in another tab will handle it fine, and a custom integration won't pay for itself. Building makes sense when the job is high-volume, specific to how your business works, and has to sit inside your own systems.
Where to start
Pick one job that passes the four tests above, and write down roughly how many items it handles a month, where they come from and where the results need to go. That's most of what anyone needs to scope it. Then build the smallest version that does that one job with a person checking it, and run it for a month before adding anything.
If you have a workflow in mind, we can scope the AI integration with you and tell you what the first version should leave out. Tell us about it, and we'll come back with an estimate that shows where the hours go.
