When support is the last to know a version is “ready”

The first day of a new version is often quieter for engineering than for support. That is not a complaint. It is a reason the freeze packet should be written for the people who will read tickets, not only for the people who wrote the build.

We keep seeing the same sequence. The release owner marks the version ready. Store submit happens. Support receives a forward of the engineering notes at 6 p.m., in English, with internal names for screens. By morning the tickets are already using the words customers use.

A usable support brief is short. What changed that users will notice. What still fails and how to recognise it. What not to promise. Who is on the rota, including the public holiday. A link to the limitation list in the same language as the app.

If your support group is a vendor on a different floor, or in a different city, send the brief before the go/no-go, not after. They are part of the evidence that the version is ready. A rota with names that cannot actually take calls on launch morning is a blocker, even if the build is clean.

In Kuala Lumpur we have sat in rooms where support was invited and still not handed the microphone until engineering had restated the test summary. Invert that order. Ask support what they are unprepared to explain. That answer is usually the real state of the release.