This is great, and exactly what one organization I once worked for did. We had "business liaison" positions within every department, and "application owners", which were dual roles - these people were generally business users, with extra training so that they could work effectively to bridge between IT and the userbase. As part of these dual roles, they were included in the IT decisionmaking and change control process, so that they knew what was up before it happened, rather than finding out afterwards, and so that they could advocate for their department's needs ("You can't change payroll the day before we run it!" "Tuesday doesn't work because that's year end closing!")
We also filtered everything IT through the helpdesk, from change controls, to access requests, to outage notification & paging, to trouble tickets and support requests. Problems which weren't reproducible were stopped there. Things that seemed to be user education would either be handled by the helpdesk, or assigned to the appropriate business liaison to see if there really was a problem and gather more details. Remote control sessions were utilized by the helpdesk to gather screenshots. Intermittent problems were weeded out unless they recurred, in which case the previous calls were referenced to verify that this really was recurring. We leveraged our engineering and operations teams for troubleshooting when appropriate to gather logs. Only after we had concrete, conclusive details of a problem did something get passed to developers - and when we did, it was handled quickly, because we'd gathered all the information efficiently and correctly.
As a result, the developer teams were able to focus on fixing bugs, not triaging problems. The helpdesk always had ready access to all the relevant teams via phone, email, and instant messaging, and was well respected within them, because we were their filter, firewall, and front line, as well as their secretaries. (And we had the decisionmaking power as far as who got paged at 3am and who didn't!)