I think it depends on how teams are organized already and the size of the company.
Few things I noticed that made this work in practice:
* Engineers pair up for few rotations with other engineers who are experienced in interacting with customers, triaging issues, troubleshooting issues across the system and identifying which internal service is causing issue and ping the team that supports it and/or move it to their support queue.
* The goal is not to fix every single bug or issue in the queue. Prioritize incoming tickets and gather as much information as possible before moving it to some team's backlog. Solve only problems that you think are manageable within the length of your support rotation.
* One engineer per team or owners of a set of services should on the rotation (this again depends on how teams are organized already).
* Pair with customer support or customer success agents when dealing with difficult customers, situations or need help communication-wise in general.
* Bring in these bugs to your team and make sure stakeholders are aware of them. This is important especially when the team ships something and moves on to the next thing thinking they have 100% capacity for the new project. This is another feedback channel that PMs should be aware of.
* Engineers on support rotation are exempt from their team duties while on support. Again, this communicates what capacity the team will be operating on in the next week or two.
I learned so much about other parts of our product and APIs, how users interact with it, and most importantly (for me at least, since that was the new part) working with people in the company who are not in engineering or product!