I started out working at a helpdesk at a university, so I have some advice and warnings --
First, depending on your hiring practices, not everyone who gets hired for the helpdesk would make a good sysadmin. Honestly, some of the ones we had didn't make good helpdesk employees, either. (why they thought it was a good idea to water a plant that was sitting on top of a monitor, I have no idea; and why our manager thought it was a good idea to hire people who'd get a chance to practice their new English skills might've been useful to help with our foreign students if they actually had some experience with computers to go with it)
Anyway, the point is -- there are some people that it might not be worth going out the way to help. If you keep an eye on them, you should find out who are willing to ask questions and do enough troubleshooting to find the root cause rather than try to get rid of people as quickly as possible.
Due to the size of our shop, we only officially had four classes of employees -- 'helpdesk' (fielded calls and walkins), 'technician' (handled hardware repairs), and 'senior staff' (effectively, the sysadmins), and 'management' (useful to send the belligerent folks to, as somehow my manager could turn any conversation into a discussion of her grandchildren within 30 minutes, which would confuse the users into submission).
Anyway, the way walk-ins were handled basically worked as such:
Person with a problem talks to
someone on the helpdesk staff
If the helpdesk staff can answer the
question, they do.
If the person's a new user to
software that we supported, we gave
them a print-out of the appropriate
FAQ or user guide. (yes, now it's
considered a waste of paper, but
this was the mid-90s).
If the helpdesk staff member
couldn't answer the question, they
could attempt to confer with the
other helpdesk members working at
the time (normally 2-3 per shift).
If we still didn't have a
resolution, the helpdesk would relay
the message to the senior staff.
If the senior staff might either
answer the question, or ask to have
the user come back to their cubicle
for more questions. This was the
important part -- this was not a
hand-off. (unless the senior staff
member thought this was so unique it
was unlikely to come up again).
This way, the helpdesk person heard
how to troubleshoot the problem, so
they could deal with it in the
So, I think the problem these days is that a lot of shops don't want to tie up too many people on a single call -- so level 1 helpdesk transfers the calls up the chain, but don't hear how to deal with these new issues. Look at how to your deal with users, and see if there's a handoff that prevents the junior folks from being involved so they can learn on the job.
With our system, senior staff members have more interaction with the junior staff, and can quickly assess who's actually learning as they go, and who's sending back the stupid questions. A couple of us got recognition as junior staff members for taking it upon ourselves to update all of the handouts (FAQs, user guides, keyboard maps, etc) convert them from some format our old Wang used to Word Perfect (and later HTML) and build a document management system to track version, when each one was last updated and reviewed (but deemed still correct), etc.
I ended up getting promoted into our newly formed web development group, and our UNIX guy suggested I get a copy of the "Unix System Administration Handbook", and I ended up effectively apprenticing as I later moved to take over responsibility for our gopher/web server (which at the time wasn't considered to be a critical server).