The first support ticket was waiting. I replied to see whether the system worked.
The message was short: testing to see if this works.
That test covered more than the send button. A support request had to reach the right inbox. The system had to create a ticket. A reply had to return to the person who opened it. The thread needed to stay together so the next response had context.
For a small product, support often begins as a shared email address. That is enough until more structure is needed. It also makes the early failures obvious.
A reply can come from the wrong address. The customer's response can disappear. A notification can go to an inbox nobody watches. Formatting can break. The support tool can show a message as closed while the person who wrote in is still waiting.
We were not testing volume or publishing service metrics. We were checking the path with one ticket.
The private record contains account details that do not belong here. It does not need to. The public-safe fact is that support was being treated as part of the product before a wider launch.
I wanted a person to be able to ask for help and receive a normal reply. That meant testing the same route they would use instead of assuming the setup screen was correct.
The test also established a reference for later changes. If the address, support tool, or notification settings changed, we could repeat the same small exchange and compare the result. No special test harness was needed for this path.
I used an ordinary message because that was the behavior under examination. The system had to handle a short question and a short response before more complicated cases mattered.
The ticket arrived. I answered it. Then I checked whether the response came back through the system the way it should.
It was a small test and a necessary one.