Guide

You don't need a starship first

Why so many first AI plans stall under an idea that is too big, and why one well-aimed first step gets you further.

László Sabján
October 27, 2026 6 min read
Paper craft: a sailboat on colored paper waves, a lighthouse on the shore

I often say it right at the start: let's stop for a minute. Not to talk you out of anything. It's just that you don't need a starship first. A sailboat will get you where you're going too, as long as the sails are set right.

The short answer to how a first AI project should start: with a single call type. One you get a lot of, that repeats, and that already has a clear way it should go. Once that works and there are more calls worth handing over, the next one builds on it. That's how an AI phone assistant grows with the company instead of stalling under a first plan that's too big.

I say this once the company has told me what it wants. What we see most often in a first AI project is a first plan that's too big. The development rarely gets stuck. The size of the plan does: too many questions need answers at once, and each one needs a different person inside the company.

What the starship looks like

The idea usually goes something like this. The assistant should answer every inbound call. Book appointments, change them, cancel them. Answer questions about products, shipping and complaints. See the CRM, the calendar and the invoicing system. Speak English if needed. And all of it should go live at once.

That's understandable. Anyone who has heard a good voice agent starts thinking about everything it could do. And some of it really could happen, later.

The catch is that what looks simple from the outside rarely is. Take appointment booking. From the outside it's one sentence: "book me in for Thursday." From the inside it's a list of questions. Which calendar counts if there are two? What if the caller doesn't know which service they need? Who can get an appointment out of turn, and who decides that? If the assistant doesn't understand the request, who does the call go to? And who picks up if it's lunchtime?

These aren't technical questions. Someone in the company knows the answers, or nobody does, because the receptionist has been handling it in their head, a little differently on every call.

A second language works the same way. From the outside it's a checkbox. From the inside it means every answer and every knowledge-base entry has to be maintained in two languages, and someone has to check that the English answer says the same thing as the Hungarian one. When the opening hours change, they change in two places.

Every new call type is another list of questions like that. Every new system the assistant has to connect to brings another owner you need something from: access, data, a decision. With the starship, all of these arrive at once. The project doesn't stall because something is broken. It stalls because nobody can answer everything at the same time.

What the sailboat means

A sailboat is a real boat. It gets you there. It just doesn't carry everything at once, and you can adjust it along the way.

With an AI phone assistant, the first step is one call type. Ideally one you get a lot of, that repeats, and that already has a clear way it should go. Appointment booking is a good example. So are after-hours calls nobody answers today. Or the question your team answers many times a day.

For that one call type, a few things have to be said out loud. What the assistant does, and what it doesn't. When it hands the call to a person, and to whom. What you'll look at a month later to tell whether it works. For one call type, these questions are manageable, and you know who to ask.

The timeline changes too. Simple appointment booking can go live in 3–5 working days. For a complex integration, plan on a 4–6 week pilot. There's no such number for the starship, because it's hard to say even when it will start.

Once the first step works, you can learn from it. Live calls show what people actually ask, where conversations get stuck, and when they ask for a person. If a second call type comes, it builds on this: the same handoff, the same measurement, the same knowledge base, just bigger.

The first call type is also where you find out how the handoff to a person works. That matters as much as the assistant itself. If a caller gets stuck and asks for a person, someone has to be there to take over who knows what was said so far. Get that right for one call type, and you don't have to reinvent it for the next.

And setting the sails

The second half of the comparison matters just as much. A sailboat only gets you there if the sails are set right.

Here that means the first step should point toward the big goal too. If a year from now you want the assistant to take most inbound calls, the first call type should be one of the most common ones, not a convenient side branch. If the goal is for a salesperson to spend less time screening leads, start with screening, not customer service. That way the first step is already the first piece of what you wanted all along.

Who keeps it going

A sailboat also needs someone at the helm. After go-live, we don't hand you the system and wish you luck. We run the measurement, maintain the knowledge base and fix what breaks, and every month you see in numbers where it stands. That monthly picture shows whether the first step is working, and if there are more calls worth handing over, when it makes sense to expand.

Why I say it at the start

It could go another way. Accept the big plan, get started, and when it gets stuck, mention that maybe it should have been smaller.

But a big project that's already running is hard to shrink. By then there's an expectation from management, an internal announcement, and the team already knows something is coming. If it turns out at that point that the plan was too big, everyone is disappointed. People look at the assistant differently from then on, even though it wasn't the problem.

You can't know in advance where the pitfalls are. That's not your job. We can, because this is what we do. So it's our responsibility to say it at the start, not six months later.

Recently a company wanted to launch four things at once. We started with two, and agreed in the very first conversation that we'd build from there. The other two didn't fall off the list. They're just next in line.

When even the sailboat won't help

Sometimes even the first step is missing what it needs.

One case is when there's no process. If nobody can tell you today how an appointment booking goes, what counts as a good result, and what to do when the caller asks for something else, the assistant won't know either. AI can carry out an existing process. It can't invent one for you. In that case, the first step is writing the process down, and the assistant comes after. We can help with that, but the decisions have to be made inside the company.

The other is when nobody owns it on your side. Someone who answers the questions, listens in on the first calls, and can decide what to do when something doesn't go as planned. If that person doesn't exist, or exists but is supposed to do this on top of their day job, even the small step gets stuck. In the same place as the big one: on the answers.

There's a third case that's less visible. When management expects from the first step what it would have expected from the starship. One call type won't transform the whole customer service operation in a month. If that's the expectation, the sailboat will disappoint, even though it's doing exactly what it was built for. So agree on expectations at the start, not just on what you're starting.

In all three cases, the fair thing is to say this at the start too.

Where to start

Start by mapping your call types. For each one, look at four things:

  • which one you get the most of,
  • which one repeats,
  • which one already has a clear way it should go,
  • and which one has an owner in the company who has time for it.

Where all four line up, you have a good first step.

Before you start, write down what you'll look at a month later. It doesn't need complicated metrics. Enough to know how many calls the assistant took, how many it handled end to end, how many it handed to a person, and why. That shows whether the sails are set right and what the next step should be. If you don't write it down in advance, a month later everyone will have a different idea of success.

We've written more about the call types other companies started with on our use cases page.

If you like, we can go through these four questions with your calls in a 30-minute conversation and see which would be the right first step for you. You can book a time here.

László Sabján

Founder, CEO — AI Squad

LinkedIn profile →

Interested in this?

Let us talk about how it would apply in your business.

Book a free 30-minute call