Nobody was ever going to learn our software.

Contact center software. Campaign tools. A chat platform. Real customers, real volume, work we were proud of and still are.

And every time one of those customers wanted something, the request came to us.

Not to a settings page. To us — a person on our side, reading an email, opening the account, doing the thing, writing back. That was not a failure. That was the product working exactly as designed, and it is how almost all business software works. For most of the time we were building it, there was no alternative.

There is now. So before we tell you what Omni Octo does, here is what we think was wrong with what we did before — written by the people who did it.

One

It could already do it. They just couldn’t get to it.

The thing a customer asks for is almost never a feature that doesn’t exist.

It is usually something the software can already do, sitting behind a menu they haven’t found, or a report they don’t know how to build, or a setting whose name you would have to already know in order to search for it. The capability is there. It shipped months ago. We announced it.

So they do the only thing available to them. They ask us.

And that request — which needs no engineering, no release, no deployment, and nobody to write a line of code — still gets an email, a person, a position in a queue, and an answer on Thursday.

If these had been real feature requests, the wait would be honest. Building something new takes time, and it takes time for us, and it would take time for anybody. We have no quarrel with that wait, and neither do our customers.

The interesting case is the other ninety percent: where the software could already do it, and the only thing missing was knowing how.

Nobody in that chain was slow on purpose. The people answering those emails were good at their jobs and cared about the outcome. The queue was not a failure of the team — it was the only route we had built between a customer’s question and an answer that already existed inside our own system.

And the cost nobody counts is the questions that never get asked.

When asking is expensive, people stop asking about small things. They keep an agent that is slightly wrong for months, because getting it slightly less wrong is not worth two days and an email thread. We saw every ticket that was filed. We never saw the improvements our customers decided weren’t worth the trouble of requesting — and that set was much larger.

Two

Their data. Our building.

A customer ran a campaign of several hundred phone calls. Afterward they told us it had gone badly.

We asked how they knew. They sent fifteen recordings.

Fifteen, out of several hundred — not because they were cherry-picking, but because fifteen is what one person can listen to by hand in an afternoon. The rest existed. Recorded, transcribed, stored, complete.

Every answer they wanted was in there. How many people picked up. How many reached the end. Where in the conversation people stopped talking. Which question confused everybody. Whether the thing they were upset about had happened six times or four hundred.

None of that required us to build anything. It required someone who knew how to ask the data a question. That person worked here, not there.

So the conversation we had with them wasn’t an analysis. It was two parties arguing from anecdotes — theirs, fifteen of them, chosen for being bad.

We had built a system that accumulated exactly the evidence needed to improve it, and then put that evidence somewhere its owners could not question.

That is not a storage decision. It decides whether a customer can answer their own question on a Tuesday afternoon, or has to describe it to somebody else first and wait.

Three

The configuration becomes an answer key.

A customer arrives with a spreadsheet. Three tiers of urgency. Forty to fifty situations in each tier. Every row has a prescribed response.

This is an entirely reasonable thing to bring us. It is their expertise, written down — they understand their field far better than we ever will, and the spreadsheet is them doing the hard part of the work.

So we encoded it. Situation, response, situation, response. And the moment we did, two things happened that we had not thought about.

First, the spreadsheet became an answer key. It was now a written record of what the system was supposed to say, which meant every conversation that departed from it was, by definition, a defect. I wrote that it should say this. Why did it say that? That is a fair question to ask against a document we had agreed to. And it meant the system could no longer be improved without renegotiating the document — which meant, in practice, that it could not be improved, because nobody renegotiates a hundred and fifty rows.

Second, it only ever grew. Every edge case, every new situation, every can you also handle became another row. Every row was another thing we maintained, indefinitely, for one customer. The configuration was a contract with no end date and only one direction of travel.

What the customer wanted was never the hundred and fifty rows. It was the judgment the rows were an attempt to write down.

Take this seriously. Ask a sensible follow-up. Know when it’s urgent. That is the whole instruction, and it fits in three sentences. The spreadsheet existed because there was no way to say those three sentences to the software and have them understood — so the judgment had to be flattened into rules in advance, by hand, and then frozen there.

Four

Some of it we should not have built at all.

One row in a spreadsheet like that concerned a person who had said they were feeling lonely. The prescribed response asked them to recall how many times they had felt that way recently, and when, and to describe it.

Read it as a data collection step and it is perfectly sensible. It produces a structured field, and the field can be reported on.

Read it as something a human being hears, on a phone call, seconds after admitting to a stranger that they are lonely, and it is grotesque. It takes the single moment in the conversation that was unmistakably human and turns it into a database write.

We said no to that one. We would say no again.

Some conversations matter precisely because a person chose to have them. Automating those doesn’t scale the care. It removes the part that was doing the work.

An agent that handles the scheduling, the reminders, the follow-ups, the notes and the paperwork around those conversations creates more room for them, and that is worth a great deal. An agent that handles the conversations themselves is a different product with a worse purpose, and we aren’t interested in building it.

Five

They don’t learn. They ask.

This is the thing six years taught us, and we learned it slowly and in the wrong order.

First we found that customers will not learn the interface. Not ours, not anybody’s.

Think about how it feels to be handed Salesforce, or HubSpot, or any enterprise Microsoft product, and told that everything you need is in there somewhere. That statement is completely true and completely useless. The software isn’t hard. There is simply an enormous amount of it, arranged according to the logic of the people who built it, and learning that arrangement is a project in its own right. Our customers already had jobs.

So we wrote documentation. A great deal of it. A wiki page for every feature, walkthroughs, long-form videos, the whole library, kept current. It was accurate and well organized and we were pleased with it.

They didn’t read it.

And the support queue filled up with questions that were already answered. Not some of them — most of them. Asked and answered on a page we had written, or sitting in a menu three clicks away. For a long time we read this as a documentation problem, and responded by writing more documentation.

It was never a documentation problem. It is the same problem as the interface, moved one level up. A wiki is an index into somebody else’s mental model. Reading it is a smaller project than learning the menus, but it is still a project, and it is still a project about us rather than about their work.

Nobody has the capacity to learn another company’s product, another company’s menu, and another company’s wiki. They have their own work to do.

So here is what people do instead, and it is the oldest thing we do.

They ask.

Ask what this means. Ask why it did that. Ask for it to be done.

It is how every person deals with every other person — a friend, a child, a teacher, a student, a colleague, an employee, a board member. Nobody reads the manual for a colleague. You ask them, they answer, and if it needs doing, they do it. Asking is not a shortcut taken by people who couldn’t be bothered to read. It is the interface human beings have used on each other for as long as there have been human beings, and it is extraordinarily good: it needs no training, it works on the first day, it tolerates vague questions, and it lets you describe a problem in the words you actually have rather than the words someone else chose.

Every customer who opened a ticket answerable from our own wiki was not failing to use our software properly. They were using the interface they actually have.

We just weren’t on the other end of it.

Because what they asked was a person at our company, and that person has a queue, and a time zone, and a weekend. So the request went in, and then the waiting started — and the waiting is the whole cost.

They wanted it now. Or last night. What they got was next Thursday.

They don’t want to wait to have it done. They don’t want to learn to have it done. Those are the only two options the last generation could offer, and our customers were right to be unhappy with both.

So the bar we hold ourselves to now is not the one we used to hold.

A capability is not finished when it works. It is not finished when it has a settings page, and it is certainly not finished when it has a documentation page. It is finished when you can describe what you want in your own words — the words you’d use with a colleague, not the words we happened to name the feature — and the agent understands what you mean, tells you what it’s about to do, and does it.

Anything short of that is still asking someone to learn our product first.