Thanks Nasimson - every approach has advantages and disadvantages. This approach does require an active people development approach but has huge cost and benefit advantages.

Great points, @jabailo. If you write a great piece of code but no one wants to use it, is the software really any good? Maybe, if you're doing some kind of abstract thesis. But not if you're trying to solve a business problem or create a new product or service that will bring new revenue to your company. Breaking down silos -- whether technological or people -- is vital.

Scripts are great so long as they're tools and not masters. The employee needs to know when it's appropriate to use the script, when to deviate from it, and be empowered to make those decisions. 

It isn't focus on profit that's the problem. It's the focus on short-term profits over investing in people. 

If you cut out training you'll save a lot of money -- in the short term. In the long term, you'll face HR costs that other, more prudent companies, don't have to deal with. It's harder to recruit for a position than it is to promote from within. 

Help-desk and other front-line jobs shouldn't be limited only to entry-level people. People at all levels of seniority should have the opportunity for regular explosure to the day-to-day problems of people who work the line. 

IT managers should work the help desk occasionally, fast-food executives should work the grill and cash registers, manufacturing execs should work on the factory floor occasionally, and so on. 

I too began my career at the "PC Help Desk".  While that sounds like support, it could often be anything you make it from telling people where the Help button is to getting involved with workgroup applications (dBase III back then).

While I always coveted the real "programmers" (S/38) who sat in closed offices and made great things, over time the whole developing in a vacuum process has been completely reworked.  Now developers must be part and parcel of a community.  The agile method says throw it out there, let people play with it, listen to feedback and make it better -- exactly the skills of someone who has to sit on telephone and imagine what is frustrating someone else is doing all the time!

@Alison - scripts and knowledge databases and all okay as long as the key focus is making the customer happy and solving the customer issues and not some artificial metric such as reducing call length or increasing the number of closed tickets (which have no relationship with whether the closed ticket actually solved the problem).

@Mashka - so kind of you.  Thanks.

There are definitely benefits to not using scripts in support. But how can companies use best practices and knowledge-sharing so they can leverage the skills of their best customer support staff? What tools are best-in-class organizations using to transfer these skills to other tech support employees?