By Janne Timonen, CEO, LastBot Europe Oy

The old assumption

For years, the unwritten rule in customer service software has been simple: integrations are hard.

If you wanted your chatbot to check a real order status, look up a real parcel, verify a real customer, or trigger a real action in a backend system, you needed:

A developer who understood both APIs.

A scoping document.

A sprint or two of engineering time.

QA, deployment, and handover.

A maintenance owner for when either side changed.

That assumption has been the single biggest reason AI customer service pilots stall. The bot is ready. The knowledge is loaded. The channels are connected. And then someone says "but it needs to see the order in our shop and the parcel in our ERP," and the project moves from weeks to quarters.

I want to describe what happened when I stopped accepting that assumption and just tried.

The setup

I am the CEO of LastBot. I am not an engineer. I can read code well enough to know what it does, but I do not write production code, and I have no interest in pretending otherwise.

The task in front of me was concrete. A customer wanted their AI assistant to do two things that every e-commerce and logistics operation needs:

Check order status in their online shop. When a customer asks "where is my order," the bot should look up the actual order in the shop backend and answer with the real state.

Check parcel status in their ERP. When the order has shipped, the bot should query the ERP for the current parcel state, delivery estimate, and any exceptions.

Two integrations. Two different backend systems. Two different API styles.

In the old world, that is a project. In the new world, it turned out to be an afternoon.

The workflow, step by step

Here is exactly what I did. No shortcuts, no omitted steps.

Step 1: Collect the two API descriptions

I asked the customer's IT contact for the API documentation of their online shop and their ERP. Both had standard REST API descriptions. One was an OpenAPI specification, the other was a PDF with example requests and responses. Neither was polished. Both were good enough.

Step 2: Open the LastBot REST API documentation

I opened our own REST API connector guide, which describes how LastBot ONE talks to any external API. It is written for exactly this situation: someone who needs to connect the AI assistant to a tool the business already runs.

Step 3: Hand everything to an LLM

I pasted three things into a single conversation with a large language model: the online shop API description, the ERP API description, and the LastBot REST API connector guide.

Then I wrote what I wanted, in plain English: "I want two custom tools for LastBot. The first should take an order number and an email address and return the current order status from the online shop. The second should take a parcel tracking number and return the current parcel state, last scan location, and delivery estimate from the ERP. Both should return clean, human-readable responses the AI can use in a conversation. Handle the case where the order or parcel is not found. Handle authentication using the API keys I will paste in the LastBot interface."

That was the whole brief. Business language. No code.

Step 4: Copy-paste into the LastBot interface

The LLM produced two ready-to-use tool definitions in the exact structure LastBot expects. I opened the LastBot interface, went to the custom tools section, and pasted them in. I added the API keys in the fields the interface provides for credentials. I saved.

Step 5: Test in a real conversation

I opened the chat and asked, "Where is my order 10482?" The bot called the online shop, got the order, saw it had shipped, then called the ERP with the tracking number, and answered with the parcel's current location and delivery window in one clean sentence.

Total time from opening the docs to a working conversation: about three hours, most of which was spent reading the customer's ERP documentation carefully.

Why this works now

Three things had to come together for this to be possible.

LLMs got good at translating between documentation styles. Ten years ago, mapping an ERP API to a chatbot tool schema was a human specialty. Today it is a translation problem, and translation is what these models do best.

The LastBot REST API connector is designed for this. We built the connector so that the boundary between the AI conversation and the external system is a clean, declarative interface. You describe what the tool does, what it takes in, what it returns, and how to authenticate. You do not write glue code. The AI figures out when to call it and how to use the result.

The person closest to the customer can now do the work. In the old model, the account manager or partner had to hand the integration off to engineering and wait. In the new model, they can build it themselves while the customer is still on the call. That changes the economics of every pilot.

What this means for partners

Most of our growth comes through partners: telcos, MSPs, PBX vendors, hosting providers, and agencies who resell LastBot ONE to their own customers. The single most common question they ask us is, "How hard is it to integrate our customer's systems?"

The honest answer used to be, "It depends, let us scope it." The honest answer now is, "If you can read an API doc and describe what you want, you can do it yourself in an afternoon."

That is not marketing language. That is what I just did. And I am the least technical person in our company.

For a partner, this changes three things:

Time to first deployment shrinks from weeks to days. No engineering queue, no scoping cycles, no external subcontractor.

Margin improves. The integration work that used to be billed as a separate line item is now bundled into the same conversation as the initial setup.

The demo becomes the deployment. You can connect a customer's backend live in the meeting and leave with a working assistant.

What this does not mean

I want to be careful. This does not mean every integration is trivial. Some backends are genuinely complicated. Some require careful data mapping, permission handling, or negotiated rate limits. Some involve compliance boundaries that need a real review.

But the base case, looking up an order, a parcel, a customer, or triggering a standard action, is now a copy-paste job. That case covers the majority of the AI customer service integrations we see in the field.

The remaining cases still need engineering. They are just no longer the reason your pilot stalls.

The larger shift

The interesting part is not that I built an integration. The interesting part is what it says about who can build one now.

For twenty years, software integration has been a specialist activity. It required people who could hold two systems in their head at once and write code that connected them. That skill was scarce, and scarcity created bottlenecks.

The bottleneck is gone. What matters now is the ability to describe a business outcome clearly, verify that the output does what you asked, and take responsibility for it in production. Those are product and operational skills, not engineering skills.

If you run a partner business, an agency, a reseller channel, or an internal operations team, that shift is worth thinking about carefully. The work that used to sit in a queue behind your engineers can now sit with the people closest to the customer. The question is whether your organization is set up to take advantage of it.

We built LastBot ONE for exactly this world. If you want to see how it works in yours, grab any API documentation you have, grab ours, hand both to your favorite LLM, and see how far you get before lunch.

That is how I did it. And I am not the exception. I am the new default.

Janne Timonen is the CEO of LastBot Europe Oy. LastBot ONE is a partner-led AI contact center for SMBs, live in minutes, connected to the tools you already run.

How a Non-Technical CEO Built a Real Backend Integration in an Afternoon