No ringback

Eighteen months inside a system that couldn't tell me whether my own work was happening

The phone was the most important asset I had. Client outreach, service, prospecting — all of it ran through outbound dialing, dozens of calls a day. So when the firm migrated from one enterprise phone platform to another, I noticed the new one was wrong almost immediately.

The symptoms were strange in a way that made them hard to describe. Calls wouldn't connect. Sometimes there was no ringback at all — I'd click to dial and get silence, with no way to tell whether the call was ringing on the other end or had never left the building. Sometimes a call came back busy when I knew the person was at their desk with a free line. Caller ID went out wrong. And once in a while, in the dead air where a ringback should have been, I could hear someone speaking a language I didn't recognize, faintly, underneath my own call.

That last one is the detail people react to. It wasn't the one that mattered.

What actually made it unbearable

Here is how the system worked, as it was explained to me later. I'd click to dial on my computer. That initiated a call to my work cell. My cell then bridged into what amounted to a conference call with the person I was trying to reach. Three hops: desk to cell, cell to bridge, bridge to recipient.

Every one of those hops could fail, and none of them failed consistently enough to be diagnostic. Often my cell never rang at all. Sometimes that produced an error. Sometimes it produced nothing — I'd click, and the system would simply not respond, with no way to tell whether it had swallowed the request or was still working on it. When the cell did ring, the conference leg was the part I was told was breaking, and that segment I couldn't observe at all.

So the fault could be anywhere along the chain, and the one signal that would have told me whether the call was progressing — ringback — was the thing that was gone. That tone isn't a courtesy. It's the cheapest possible confirmation that a call is progressing, a signal that costs nothing to generate and nothing to read. Losing it wasn't losing a phone feature. It was losing the only instrument I had for knowing whether my own work was happening.

The part I didn't expect

On the bad stretches, my best estimate is that something like half the calls weren't completing — by completing, I mean progressing to ringing or connection.

I want to be careful with that number, because I can't prove it. That isn't modesty — it's the entire problem. The instrument that would have told me whether those attempts were progressing was the instrument that was broken.

So: I made eighty calls today. How many were real? I didn't know then and I don't know now.

Nobody above me could know either. An unanswered call and a call that never left the building leave the same trace to me.

And nobody was counting the calls anyway. In this business the only measure that finally counts is revenue — activity is what people talk about, production is what gets reviewed. So there was nowhere in the firm this would have surfaced as an anomaly. Not in activity data, because nobody was watching it closely enough for a change to register. Not in revenue, because revenue arrives months later, in aggregate, with a hundred inputs feeding it: a phone system quietly preventing something like half your call attempts from progressing looks identical to a soft market, a slow quarter, or a rep who lost a step.

The trap closes from both ends. Invisible in the short-run measure because nobody watched it. Invisible in the long-run measure because by the time it got there it couldn't be attributed to anything. I can't tell you what my revenue would have been with a working phone. Neither can anyone else. There's no version of that year to compare it against.

I raised it anyway, gently, having confirmed with peers that they were hitting it too. It was not especially well received.

I don't think anyone behaved badly. That's the part worth sitting with. The response was structurally reasonable: a person reporting an unverifiable problem is asking to be believed rather than shown, and organizations are right to be skeptical of that in general. The trouble is that the situation was manufactured entirely by the missing verification signal. Take away the cheap check, and an honest report becomes indistinguishable from an excuse.

Why it took eighteen months

There were seven layers between me and anyone who could fix it: first-line technical support, second-line technical support, first-line voice, second-line voice, the regional technology owner, enterprise technology, and finally the platform vendors themselves. I did not know that at the start. You never do.

I went back to the bottom of that ladder about half a dozen times, reopening closed tickets and restarting fixes that hadn't held. They didn't close because anyone dismissed me. They closed because a ticket needs a reproducible failure to stay open, and I couldn't produce one on demand. Someone would test the line and it would work — which proves nothing about an intermittent fault, and is still a reasonable basis for closing a ticket.

So I'd stop, and then it would cost me another week of calls and I'd start again. That cycle isn't persistence and I won't dress it up as persistence: each time I quit, I was waiting for it to hurt enough other people that the cost of proving it would spread beyond my own patience. It never spread.

What ended it was that I became the instrument.

I became the instrument

For months, every time a call failed, I stopped and documented it: number called from, number called to, timestamp, what the system did instead of connecting. Submitted through a Teams chat, on a template somebody had given me. Hundreds of calls, one at a time. That one didn't work — fill out the form, send it in, go back to selling.

Sit with the template for a second. Somebody built a form for this. The organization's answer to a producer who couldn't verify his own work was not to instrument the phone system. It was to standardize the paperwork for the human doing the verifying by hand. I read that form as two things at once: evidence the problem was real, and a decision about who would carry it.

It worked, is the thing. Once there were hundreds of documented failures, they stopped being my word against a passing test call and became a pattern somebody could trace. The final escalation succeeded because I walked into it carrying data I had generated myself, one failed call at a time, for months, during the hours I was being measured on.

Then it got fixed. I was told the conference leg had been repaired, ringback came back, and the calls went through.

What I actually took from it

For a long time I read this as a story about persistence. I don't think that's right anymore.

Once the right people saw the same evidence, it moved quickly. It was expensive to prove, and that cost landed on the person with no instrument to do it, no authority to demand one, and a great deal to lose from the ambiguity. I was in retail sales, diagnosing an enterprise telephony fault, on a template, in the middle of my selling day. At every escalation layer, a passing test call could make the system look healthy. Nobody was lying.

Verification cost doesn't disappear when a system fails to provide it. It rolls downhill to whoever is in enough pain to pay it, who often isn't the person with the authority to remove it.

As far as I'm aware, nothing was added afterward to make the next failure visible. The fault was fixed; the blindness wasn't. Nobody ever mentioned to me what it had cost to find it.

So when I watch a firm hand work to software now, my first question isn't whether the system can do the job. It's who finds out when it doesn't, and what it costs them to prove it.

A system that fails loudly is a nuisance. A system that fails silently, while producing output indistinguishable from success, can cost you eighteen months — and you won't know the clock started.