We're Making Our Own Platform

Hey, Patrick here - I'm making significant changes to Call Theory's priorities. Read on to learn what we're doing, and why we're doing it. It's taken several weeks to put together this article, but it's worth a read in my opinion.

There's a lot to digest, but my exceptionally clear and concise communication will make it easy to understand. To begin, let's do a quick executive bullet-point summary of what I'm doing and the expected impact we'll see for paying customers.

• We are building a new multi-tenant call center platform
• We are moving future Call Theory development priorities to this platform
• We are no longer building new tools for the Amtelco platform
• We are giving up on Starbase, our previously announced billing gateway
• We are not changing other Call Theory services and resources

Let's look at these individually more in depth.

We are building a new multi-tenant call center platform

There's currently two types of call center platforms:

1. Legacy multi-tenant systems bolting AI features and agents onto everything
2. AI-first systems that primarily replace live operators and aren't multi-tenant

Neither of these scenarios are something that I really prescribe to – rather, I'd like to see a multi-tenant call center platform that focuses on improving the experience for the live operator. Something that helps translate productivity gains from technology like AI for the benefit of the agent.

I like to call this "trickle-up productivity." Maybe that 4-day work-week will happen, after all?

The primary goal is to improve customer experience by empowering live operators with AI assistance on goals they otherwise would need expertise, training, or supervisor assistance to complete.

Until we come up with a better name, I'm calling this new platform ToneDef.

The name is a play-on-words for Tone Deaf (i.e., Amusia) while also providing "Tone Defense" (modern security) for call centers.

Personally, I think it fits. People tell me I'm tone-deaf all the time!

We are moving Call Theory development priorities to this platform

We've probably been spreading ourselves too-thin for too long. With ToneDef becoming a new priority, we're going to stop spending time trying to understand and build utility against Five9, Amtelco, 3CX, and other 3rd-party ecosystems.

These ecosystems are all based on 3rd-party companies that can (and have) revoked systems access or refused to assist partners and vendors.

We are no longer building new tools for the Amtelco platform

The future road-map for our Amtelco-related products (i.e., Mission Control) will become much more concise. We're going to limit the addition of new features to only those where a customer pays us to develop it (and also allows us to share it with the community.)

Another way to explain this is that we are no longer expanding capability, but will continue to maintain and improve usability. This is planned for at least as long as we have customers using the Amtelco platform.

And since Mission Control is now open-source, it will be easier for the community or another developer to fork it if needed.

We are giving up on Starbase, our previously announced billing gateway

I guess the first place to start would be: I'm sorry to those this announcement disappoints. While the interest was fairly low (3 total companies,) I had hoped to fill a needed gap in the Amtelco ecosystem.

However, with our decision to build our own platform, we can build the technical base allowing the same types of features and integrations Starbase promised, except built natively into ToneDef.

This will go on my notable failure list, but I learned so much about billing/invoicing that we felt comfortable taking it into our next project.

Call Theory services and resources are not otherwise changing

We're still doing our Tuesday office hours and Thursday Amtelco IS scripting sessions. All of our online documentation will continue to be maintained. We're still doing break/fix and managed services for customers running Amtelco, Five9, and 3CX. We're going to continue to document our learning experiences with conversational AI agents and add new scripts to our digital library.

Everything is still happening!

No services that we actively provide to customers are being cut - this is primarily about focusing our future development priorities.

Why are we doing this now?

There are a variety of reasons we decided to make our own platform. I'm happy to dive into them below.

Build Better AI Tooling

Earlier this year, I came across this blog post and it resonated with me. AI tooling needs built by people who care more about the product than the money it generates. Anything else is a conflict of interest for the end-users of the product. [See modern social media.]

I need to be careful about my speech here, as President Trump has decreed that talking badly about capitalism amounts to domestic terrorism.

The point is that if we want to see AI used in better ways, then we probably have to build it ourselves.

Conversational AI is here

It's been easy to dismiss AI as not a threat since the latency around communicating over standard telephone networks was historically favorable to humans. Earlier this year, multiple commercial and open-source projects showcased viable telephone conversations using AI.

Local businesses are even starting to go with these solutions as they are often cheap or easily accessible from their existing (marketing/sales/service/erp) platforms.

Essentially, we [as an industry] can't ignore conversational AI anymore.

Luckily, we've been honing our skills on creating conversational AI agents through Call Center Village over the last several months, setting us up for building these agents as part of ToneDef.

We Built IS Scripting Automation

Over the last several months, we've spent hundreds of hours building, testing, and experimenting with generating and modifying Amtelco Intelligent Series scripts through AI prompts and fine-tuning existing models.

We've got a pretty compelling internal product that allows us to create Intelligent Series scripting in a variety of different ways:

• We can pragmatically generate a script using a our own DSL
• We can use a ChatGPT-like interface to build a script conversationally
• We can decompress, modify, and re-compress an .iff file
• We can generate new .iif files for importing scripts
• We can generate new script versions directly in the Intelligent database
• We can properly chunk large scripts when saving changes back to the database.
• We can export scripts into standard formats for importing into other systems

This all essentially means that we have a general purpose AI-backed workflow that can create Intelligent Series scripts from text descriptions and a pragmatic tool for more easily moving scripting between platforms. Pretty cool.

A side effect of this tool is the ability to summarize scripting outcomes – a popular feature request. It needs a little bit more guidance before this becomes generally usable.

There are some additional limitations, notably:

1. It does not handle advanced/complicated on-call rotations well.
2. It cannot create new Shared Fields on it's own, but can reference existing.
3. Database and API integrations need to be done manually
4. It still needs some tweaks and edge-case fixes
5. Loss of Amtelco functionality when exporting to stand-alone HTML

My expectation is that this tool will allow us to continue to support customer scripting needs without the excessive time-commitment required for drag-and-drop scripting techniques [even with templates.]

I.e., it allows us to prioritize ToneDef development without a drop-off in scripting productivity, and it gives us import/export capabilities for Amtelco scripting.

Since we're talking about Intelligent Series scripting, it might make sense to look at the larger Amtelco ecosystem as well.

My Amtelco Problems

I've spent most of my adult career supporting Amtelco systems in one-way-or-another, but there are a variety of problems that the ecosystem hasn't resolved. I think I've exhausted what I can offer the Amtelco ecosystem without direct partner support from Amtelco.

My intention with sharing these frustrations is that they might be addressed eventually. I have a lot of respect for Amtelco and what they've built.

• There is no education path for IS scripting

Without any documented training and certification process, the Intelligent Series scripting ecosystem will never develop beyond a skill people using Amtelco systems have to learn. This means you'll struggle to hire and retain external IT/programming talent that is forced to primarily work with Amtelco scripting.

I do think it's one of the best overall scripting platforms for multi-tenant systems we're used to working with. But we're mostly beyond "basic scripting" in our industry where a dedicated IS programmer is almost required.

• Lack of progress on existing versions

At the 2024 NAEO conference, Amtelco announced 5.6 was generally available. The 5.6 rollout was halted shortly thereafter and many of my customers are still on 5.5 waiting for a new version.

At the 2025 NAEO conference, Amtelco announced 5.7 was generally available. The 5.7 rollout was halted shortly thereafter and customers are not able to upgrade to 5.7 until they fix performance issues.

Intelligent Series 6.0 is not generally available, but sounds great whenever it's released.

Customers are virtually locked into their existing version for multiple years unless they got into an early or beta upgrade window.

But in the meantime, what should my customers be doing if they need the features or functionality that were released in 5.6 and 5.7? And how long should we wait for a functional AI version (i.e., 6.0)

Side note: We've all been there. Have you seen my project delays? No judgements. I'm hoping to reduce my delays by not being dependent on code I can't control or see.

• Need for modern software development practices

Amtelco installers aren't signed by a certificate and it's becoming harder and harder to finagle installations with zero-trust policies from EDRs flagging unsigned and low-use applications (i.e., similar to Smart Screen) on installations.

This is especially problematic for end-user applications like Soft Agent and Web Agent Shell, and in highly-managed enterprise environments.

Additionally, the version releases maintained on the Amtelco support and FTP sites are generally out of date. There are undocumented versions in home folders where you need to request the specific link - you can't just browse to the "current" folder and assume it's the most current working version.

• No Amtelco partnership program

I've not had any real technical support from Amtelco (beyond trying to fix broken versions of their software) for many years. They are adamant that they do not work with 3rd-party vendors in any capacity except through customer requests. This has made my job of keeping up with new Amtelco features (coupled with stalled roll-outs of 5.6 and 5.7) a complete nightmare.

As an example, creating Starbase versions for 5.5, 5.6, and 5.7 became difficult with the rounding changes introduced in later versions – changes I didn't learn about until a customer installed it.

It doesn't make sense to commit to supporting multiple Amtelco software versions without some kind of partnership support.

• Lack of direction for 3rd-party partners

Amtelco has been moving towards a service model over the last several years, offering managed hosting environments, building out consulting services, and creating SaaS options like Active Insights.

Despite my best attempts, I was never able to understand where 3rd-party solution providers (like me) fit into the larger ecosystem as Amtelco moved towards this hosted/services model.

A concrete example of this is NAEO not longer allowing vendor-members to attend Amtelco presentations at conference.

• Amtelco API pricing and usage doesn't make sense to me

I was really excited for MergeComm. I wrote multiple integrations using the MergeComm ISWeb REST API Trigger - essentially a structured web-hook that opened the door to 3rd-party integrations without forcing everything through an email.

But in practice, you get one (1) single license for use system-wide. Anything more must be purchased and is a recurring payment (on top of buying the API software) even if you run your own infrastructure onsite. This exact issue has led to multiple customers of mine to stop their rollout of MergeComm API triggers (and one is even leaving the ecosystem for a more developer friendly platform.)

I've all but abandoned developing against the ISWeb REST API because none of my customers can afford to use it in any meaningful way.

The terms around the Amtelco API usage essentially require you to get approval from Amtelco for anything you want to build. I'm assuming they want to front-run any ideas they see as valuable first. I'm also making a big assumption, so maybe also assume I'm wrong.

Front-running community software contributions isn't an uncommon behavior, but it's not one I love.

What's next, then?

We're going to be shifting our blog conversations towards building out the pieces of this new platform. If you have any questions, please reach out to me. You can just hit reply to this email.

We'll still talk about Amtelco and other call center platform topics as we come across it just like we've been doing.

We have a few more updates to send out this week about Call Center Village and the weekly training schedule for the remainder of October – so you're likely going to see a few more emails from me this week. How uncharacteristic of me.

We're excited for ToneDef. We hope you are, too. More information to come.

And hopefully a better name.