Supporting custom code

Question: How can a technical support team support handle custom code, like that developed by a professional services team?

Answer: This was a tough problem.  I tried several solutions over the years.  Our final solution to this was fantastic, but I can't take much credit for it.  Two of my lead staff members, one from PS and one from Tech Support, did the real work of building an elegant solution.

I was managing both technical support and professional services.  When we built out our custom code business I was very hands-on in all aspects of it.  I did everything but the coding.  So, at first, I handled all of the support for custom code myself.  But that couldn't scale.

I had ideas and intentions for rolling out a program whereby the support team would take over supporting the custom code.  It was something that I talked about with both teams off-and-on for quite some time.  So both teams had plenty of time to consider the problem before the problem really presented itself.

It turned out that we became victims of our own success.  We had improved the capabilities of our custom code to the extent that it was completely blended in to the core application.  End-users were completely oblivious to the fact that they were using one-off custom code, which is exactly how it should be.  But once we reached that level of integration the customers using custom code began approaching the support team for help instead of calling me.  My CSRs began falling down rabbit holes trying to diagnose problems that made no sense to them because they involved custom code.

Finally my CSRs began telling me that they needed a better way to know about custom code in advance.  We began tracking custom code as a separate type of support case, and measuring the metrics on those cases.  There weren't that many cases.  We found that we weren't spending that much more time on these cases.  But there were usually extra emails going back and forth, which caused the resolution to take significantly longer than normal cases.

And when I looked at that report I realized that all of these cases were for our most important clients.  That's when I handed the problem off to my two team leads and challenged them to work out a solution.  The solution they designed was elegant and scalable.

I chaired a meeting of the technical support and professional services teams.  We openly discussed the problem.  We drew a map on the whiteboard of the current workflow process for the creation and delivery of custom code.  The teams came up with two changes to that process, and one change to the process of supporting custom code.  Both teams were excited about the benefits that they would receive from the changes.

The professional services team began building long-term test sites for every custom code customer.  Prior to this they would only place custom code on temporary sites that they had used during coding, testing, and training.  Then the sites would go away.  Now these sites became permanent, and the support team was given full access.

The professional services team also began including a member of the technical support team in the training webinar for the customers.  During the training the support team member would make notes about the custom code, the on-screen verbiage, click locations, and affected database fields that would tell them that a support call involved the custom code.  These notes all went in to the internal knowledgebase in our helpdesk, along with the client's docs on the custom code, the link to the test site, and location of the source code in our code management system.

With all of that data at their fingertips, the technical support team took over L1, L2, and L3 support of the custom code.  When a case came in for a customer with custom code the CSR could immediately see that the client had custom code.  They could see what the custom code did, and they could immediately log in to a test site where they could see the custom code in action.  They had the full documentation of the custom code, and could examine the source code themselves, if needed.

The technical support team didn't involve the professional services team in support any more at all.  If the custom code was broken then the support team just fixed it and issued a patch like they would for any other bug.  It was more often the case that the problem was that the client had changed their configuration or requirements.  And then it was easier to have that conversation with the client, to explain that changes are billable, as the case was passed from technical support to professional services.

The time to resolution for ‘custom code’ cases plummeted to the point that it matched other types of cases.  Because the support team was ready for the custom code it took no longer to support than anything else.

One of the great side-effects of this change was that the support team began making and sugegsting improvements to the professional services team's core code library.  These changes mostly involved error-handling.  For instance, instead of erroring-out when required configuration data was missing, the support-improved code would present a simple message like, "Users _____, _____, and ______ have no value assigned for their _____ field.  Please click here to update those users, and then re-run this report."

Another great side-effect is that the professional services team spent much less time on support, which freed them up to do more pre-sales work and bill more project hours.