It seems to me that Technical Support breaks down into three separate-but-related domains, all of which will probably come into play when resolving a customer issue.
The first of these is customer communication. This may involve CRM (Customer Relationship Management) software, dedicated account representatives, members of a Sales team, or all of these. (What else does this involve?) Customer communications is primarly non-technical, even when technical information is being communicated. Joel's Seven steps to remarkable customer service covers many of these issues.
I think it's fair to say that what customers want is to be kept informed, at an appropriate level; for their problems to be solved, at a technical level; and for their fears to be addressed. The last of these is the domain of technical support soft skills, which is worthy of its own topic. Customers want to be communicated with, regularly and promptly, but different customers have different needs. CRM (Customer Relationship Management) software may be necessary to track customer needs. ACD (Automated Call Distribution) software may be necessary to ensure prompt support in environments with a large volume of incoming calls. Trouble Ticketing software should be used to communicate within a Technical Support team, both for handoffs between members and as a permanent record of work performed.
In an ideal world, the CRM, ACD, and trouble ticketing software might all be one tool, or they might integrate, so that (for example) the ACD can perform caller ID using data from the CRM, and so that the Engineer working a call can review the customer's previous cases without needing to manually search. If the case turns out to be a new case, the Engineer could open a new trouble ticket from the ACD, with the system automatically populating the necessary fields; if a case already exists, the ACD could log the call on the case, documenting the Engineer's work. (Does anyone know of tools that integrate in this way?)
The second of these domains is interpreting what exactly the customer is asking for on a technical level. One detailed breakdown of this topic is Tom Limoncelli's seminal paper, Deconstructing User Requests and the Nine Step Model. Steve Litt at Troubleshooters.Com has an eleven step model. Customers may be unhelpful, in that they're unable to articulate the issue, or may fixate on a symptom that they believe to be a cause of the issue. (In troubleshooting, as in other domains, premature optimization is the root of all evil.) Other customers may be extremely helpful.
Finally, the third domain is identifying and solving the technical issue. This is a challenging domain; Wikipedia has an interesting summary of Problem solving that might be relevant. These skills may be hard to teach, which raises the question of how do we train technical support staff? I've also started thinking about how we might consider Professionalizing Technical Support.
For identifying and solving the technical issue, tools in addition to the Trouble Ticketing system may be helpful. Access to the software's bug tracker can be critical for identifying known-and-unresolved problems. Remote Access can be helpful, as can Log Analysis tools.
Finally, after the problem is resolved, the solution should be generalized, and that information fed back into the knowledgebase, help system, and other tools. If a new technical problem was uncovered, that information should be added to the bug tracker as well. (This may be considered either a form of or a product of root cause analysis.)
Technical Support centers represent an additional set of issues, once you move beyond the volume that one or two technical support team members can address. Three models, almost always hybridized, are customer self help (knowledgebase tools, help systems, and discoverable systems); a helpdesk or call center (receiving customer communication, via e-mail, the Web, or telephone; creating a case, and possibly managing ongoing communications with the customer); and the problem-solving component represented by technical support engineers.
How to balance these three models represents a major challenge, and (as with almost everything customer-facing) how to best address these issues will differ based on product, industry, and customer base. For example, inexpensive products with a wide base of untrained end-users will want to steer as many customers to self-help as possible, and address most remaining issues early on in communication with call centers, as most problems probably do not represent a technical failure of the system. (In his seven steps article, referenced above, Joel notes that these problems should still be fixed at the sfotware level whenever possible.) Niche products with a highly-technical userbase may be better served by direct contact with the engineers who will be troubleshooting the issue. Issues of customer satisfaction and resource management (including cost control and availability of top staff) make generalization difficult.