I started writing custom programs long before I became an answering service owner. At the time, I didn’t think of it as the beginning of a larger philosophy about software. There was usually a problem to solve, and my job was to figure out how a program could help.
Looking back, I think that experience taught me something that has stayed with me throughout my career. You can understand programming and still not understand the job your software is supposed to support.
That distinction matters.
I entered the telephone answering service industry in 1995 when I became the owner of Accurate Messages. I remained an answering service owner until January 2026, so I had plenty of time to experience the business from the operator’s side. I dealt with customers, employees, billing, changing technology, account activity, pricing, and all of the little operational issues that do not necessarily make sense until you have dealt with them yourself.
Those years changed the way I thought about software. Instead of asking what a program could do, I became much more interested in asking what the person using it actually needed to accomplish.
Specialized Industries Have Their Own Logic
Every industry develops its own language and way of doing things. Telephone answering services are certainly no exception.
If you have never operated an answering service, some parts of the business may look fairly simple from the outside. Calls come in, operators answer them, messages go out, and customers receive a bill. Once you are actually responsible for the operation, you realize how much is happening underneath that basic description.
Accounts can have different billing arrangements. Customers can generate very different amounts of activity. One account may be easy to handle even with significant call volume, while another can require a surprising amount of operator time. Instructions change. Usage changes. Staffing requirements change. What looked like a profitable account when it was first priced may look very different a year later.
If you are developing software for that business, you have to understand those details.
A programmer can build exactly what you ask for and still produce something that does not work particularly well in practice. The individual features may function correctly. The calculations may be right. The screens may look good. The problem can simply be that the software does not match the way people actually do their jobs.
I think that is one of the hardest things to recognize when building specialized software.
The Person Doing the Job Usually Knows Where the Friction Is
One thing I learned from writing custom programs is that the first description of a problem is not always the real problem.
Someone might tell you they need a particular report. Fine. You can build the report. Before doing that, though, I want to know why they need it. What are they trying to find? What decision are they going to make after reading it? What are they doing manually today because the information is difficult to get?
Those questions can change what you build.
I have seen the same thing in the answering service industry. An owner may say they want more information about their accounts. What they may actually be trying to determine is whether certain accounts are profitable. That leads to a different conversation. Now you need to understand revenue, usage, operator activity, and the actual work involved in servicing those customers.
This is why I believe industry knowledge has so much value. It helps you get past the requested feature and understand the reason someone wants it.
More Features Do Not Necessarily Make Better Software
There is always a temptation with software to add more.
If customers ask for a feature, you consider adding it. If a competitor has something you do not, you wonder whether you need it too. Technology keeps improving, so there is always another capability available.
I understand that temptation. I have felt it myself.
The question I try to come back to is whether adding something makes the software more useful for the person doing the job. Sometimes the answer is absolutely yes. Other times, another feature creates another screen, another setting, and another thing someone has to learn without making their work noticeably easier.
That tradeoff isn’t always obvious.
Specialized software needs enough flexibility to accommodate different businesses because no two answering services operate exactly the same way. At the same time, if you try to accommodate every possible situation, the software can become unnecessarily complicated.
Finding the right balance is difficult. I am not sure there is ever a point when you can say you have solved it permanently. Businesses change, customers change, and the technology changes with them.
Operating the Business Changed What I Paid Attention To
My years with Accurate Messages gave me a perspective I could not have gotten simply by studying the answering service industry.
When you own the business, you live with the consequences of the systems you use.
You notice when something takes too many steps. You notice when information is technically available but difficult to find. You notice when a report gives you numbers without helping you understand what is causing them. You also learn that the person sitting at a desk using a system every day may see a problem very differently from the person who designed it.
That experience has influenced my work with TAS Concepts, Inc. and TASbillerCloud.
Profitability analysis is a good example. I have spoken about profitability at answering service conferences because it is something I dealt with as an operator. Knowing how much you billed a customer was never enough for me. I also wanted to understand what it took to provide that service.
How much activity was the account generating? How much operator time did it require? Had that changed over time? Did the pricing still make sense?
Those are operational questions first. Software is simply a way of making the answers easier to see.
Sometimes the Best Improvement Is a Small One
Technology discussions tend to focus on major changes. I have been in this industry since 1995, so I have certainly watched plenty of those changes happen.
Still, some of the most useful improvements are not dramatic.
Sometimes saving someone several steps in a task they perform every day is valuable. Sometimes putting two pieces of information together makes a problem much easier to recognize. Sometimes the improvement is simply eliminating a manual process that people have accepted for years because nobody stopped to ask why they were still doing it.
Those are the kinds of problems I find interesting because I see them in the work itself.
After all these years, I still think good software begins there. Before deciding what to build, you need to understand what people are trying to accomplish, where they are losing time, and which decisions are harder than they should be.
The technology matters, of course. It has to work, and it has to keep up with changing expectations. But technology alone doesn’t tell you what is worth building.
For that, you have to understand the job.