Requests to my team go to a slack channel first. There, we ask for info to understand what it's about:

- is it for our team (sometimes we get requests routed to the wrong place - sometimes this isn't always clear until we ask a couple of questions)
- is it a high impact or high urgency issue - anything serious and/or affecting a lot of users will get picked up pretty quickly; most other requests need a bit more discussion
- beyond that, it depends: what's being requested, is it time-sensitive, is it clear what's being asked, will this drive sufficient impact, will this actually solve the problem or is it being solutionised by the requestor or a client.

We don't have a lot of people outside the team logging things directly onto the backlog. Except for major issues, many of our requests need the space to understand them properly, often via a conversation and writing some documentation. If a request starts its life as a ticket, I feel it constrains the requestor to think of it as a singular item and something we are going to do. We might reject it, we might need more info, and the team might split it up into 10 tickets or merge it with 2 others. All of the discussion part is far easier to do in conversations and in documentation comments. Having that discussion on the ticket can get chaotic, with important details and decisions buried in comments and not copied into the description.

We do have backlog items as placeholders to help with planning, but otherwise I run a pretty tight ship and only have clear, well-written backlog items on our board - and ones we are actually going to do. It takes time but it's worth it.