A short list of beliefs about what we should and shouldn’t be doing as a company. Treat it as the current draft.
This document exists for two reasons. The first is that we want to be the kind of company that can answer the question, “why did you do that?” If something we ship in five years requires us to revisit that question, this is where we want to start. The second is that we want the people who use NocTel to know what they are getting from the company on the other end of the relationship. Most software vendors do not publish what they believe. We think we should.
What follows are seven beliefs. They are not aspirations. They are positions we have already taken and that we plan to keep taking, in the order we tend to encounter them. If we drop one, we will say so here. If we add one, we will say so here.
The telecom industry has spent decades treating customer confusion as a revenue stream. Multi-year contracts. Support tiers. Certifications for things admins should be able to do themselves. Consultants for every change. This is not an accident. It is the shape that a business takes when the cost of switching is higher than the cost of staying with something you don’t like.
We bet the opposite. Customers who can do more themselves will stay longer, refer more often, and trust us more deeply. Our pricing has to reflect that bet. Our portal has to reflect that bet. Our support has to reflect that bet. If we ever start charging for things our customers should be able to do themselves, that is the moment we have stopped meaning this.
Month-to-month. No long-term contracts. Hardware you own. The price quoted is the price billed. If we stop being useful, you should be able to leave.
This discipline keeps us honest. A customer who can leave next month and chooses not to is a customer who is genuinely getting value. We think that is a cleaner signal than a five-year contract obligation, and we would rather have the signal than the obligation.
We don’t operate outside the United States. We don’t offer a free tier. We don’t pursue customers we don’t think we can serve well. We will tell you on the first call if we think you’d be better off elsewhere.
An honest “no” is more useful to both parties than a hedged “yes.” Our sales conversations are short for this reason. If we are a fit, we say so. If we are not, we say so. The list of customers we have referred to other vendors over the years is long. We do not regret being on it.
The number on the bottom of every page on this site rings on a desk in our office in Washougal. The person who answers is, in most cases, someone who wrote the code. This arrangement gets harder to maintain as we grow. We plan to keep it anyway, for as long as we can find a way.
The reason is not nostalgia. It is that the loop between customer says something is broken and person who can fix it hears about it is, in our experience, the most important loop in a software company. We do not want to put a sales rep, a tier-one support agent, or a ticketing system in the middle of it.
“99.999% uptime” is not a number we will publish on our marketing material, because that is a claim every vendor makes and almost none of them can defend at the worst moment of a real incident. We would rather be the vendor who you can reach during an outage than the vendor with the better uptime page.
What we will say: we run on geographically redundant infrastructure. We do not perform planned maintenance during your business hours. We answer emergency calls twenty-four hours a day. When we have an incident, we publish what happened, why, and what we changed. We have done this for eleven years. If you want to read about the incidents, ask.
We use machine learning in a small number of places where it makes the customer’s life better, most visibly the photograph-to-flow import in our Action Editor. We have a long list of places where we have considered adding it and decided not to. The deciding question is not “could we use AI here,” but “would a customer notice an improvement.”
When the answer is yes and we can ship it without making the system harder to debug, we ship it. When the answer is yes but the integration would obscure what the system is actually doing, we wait. The transparency of what the system does is more valuable than the convenience of having the system do it for you.
If a customer needs to read a help article to understand what a screen does, we have failed to design the screen. Help articles exist for reference and for the unusual case, but the routine case should be self-explanatory. The label on the button should tell the customer what the button does. The empty state should explain itself.
We measure ourselves on this. Every time a support call begins with “I don’t understand what this means,” we treat it as a design bug. Sometimes it is a documentation problem. More often it is a screen we built when we were tired.
If we ever stop meaning any of this, we’ll say so here.
This document is the current draft. We expect it to grow as we encounter situations we hadn’t planned for. We expect it to occasionally shrink as we drop beliefs that turn out to be wrong. The version number above is the truthful one: what you are reading is the third version we have published. There will be a fourth.
Cory Schruth, on behalf of the NocTel team