My point is that impermanent realtime communication is a variant of the telephone. We (modern business) don’t rely on telephone calls alone. That conversation held in real-time is only valuable if it is accurately captured.
The process is calls result in written minutes which are distributed to the attendees and signed off on as accurate. If you don’t have those last two steps, its back to he-said/she-said.
Our ticket system is the start of the process. 'User X needs a thing that does Y." There is a conversation with the user that is captured in the ticket, which the user can see. If the user disagrees with the request as captured, they can document the disputed items in the ticket, which one would hope get addressed prior to scheduling.
There are developer only steps that the user can’t see, but they can tell the tickets status, which usually has a predicted implementation date and/or describes blockers.
Depending on the request, the user may be required to do UAT or provide test cases for validation prior to production deployment.
Release notes will reference the oroginal request ticket when it is deployed.
I have seen some variant of this process as the norm over the past 30yrs.
In my construction engineering days “tickets” were known as “change orders” but its all request tracking, documentation, implementation, and validation.
