Ticket Open

The task should have taken a few minutes. I wanted a domain name to point somewhere else. The site was ready, the destination was ready, and only the address needed to be told where to go.

I opened a support ticket. The first day passed, and the domain continued pointing in the wrong direction. On the second day, I wrote again. The system informed me that support was busy, which was useful in roughly the same way that being told a locked door was locked was useful.

On the third day, I called. No answer. By the fourth, the original technical problem had almost disappeared from my mind. I was no longer thinking about DNS or redirects; I was thinking about the ticket.

The ticket had become the project. I checked it in the morning, after lunch, and again in the evening. Open. Still open. Somewhere there was probably a person with the power to perform the tiny action that would release me. Perhaps the request was hidden beneath a larger request. Perhaps nobody had seen it. The longer I waited, the easier it became to imagine an administrative afterlife where tickets remained open forever.

I sent another message, and the system thanked me for my patience. I had not offered any patience. That was what made the sentence interesting.

If they had told me at the beginning that the operation would take five days, I could have accepted it or found another solution. Instead, each day arrived without an answer, making a small delay feel much larger. Everything important was already finished and waiting behind one small instruction: change this, point that there, done.

Technical work often contains genuinely difficult problems—bugs that take hours to understand, systems that fail for reasons nobody expects, code that behaves differently in production. This was not one of those problems, which was precisely why it was so irritating.

The technical problem was easy. The waiting had become complex.