After about six months of learning the ropes, and then actually getting good at the ropes, SJ decided that his job was pretty decent as far as tech support went.
Instead of just being some phone-drone for Initech support, SJ was the first line of defense. He spent his days filtering out the easy problems, passing the hard ones off to the system and network admins, and generally making sure Initech's customers (often sysadmins and developers themselves) got the solutions they needed. It was easy but meaningful work.
Then came the Multitrode Insurance support contract.
Multitrode Insurance was one of the Initech's bigger clients - a state insurance firm that did data tracking and risk analysis and whatever else big insurance firms do, for a bunch of other insurance firms.
Recently, Multitrode decided to roll out some fancy new web application for submitting insurance claims and somehow Initech got hired to support it.
It landed in SJ's division because, frankly, they were the least busy and most able to take random support calls. Of course, Multitrode didn't write this new application themselves, a development firm did that for them. Initech just managed the servers that the application ran on; nobody there had any clue of what it did or how it worked.
To make matters worse, SJ had never dealt with a big client like them before. He had spent all his time working on the problems of medium and small clients which he assumed would appear positively miniscule by comparison.
Eventually they got Initech's ticket system tied in with that of the consulting company that actually made the software, and which was going to actually solve the problems that SJ and his coworkers collated for them.
Even a few procedures actually got created, which looked something like this:
- Customer has problem with Multitrode's application.
- Customer calls or emails Initech.
- Initech, in the form of SJ, collects relevant bug report information from the customer, and forwards it on to the developer to get fixed.
- Developer fixes it.
For SJ, and others, one question remained: "Why can't the customers call the developer directly?" It wouldn't be a problem, SJ was told; Initech just had to gather information and send it on. The developers would receive it, prioritize the task, and take it from there. Besides, the contract was signed, so there was no point trying to get it changed now. Initech was getting paid to do next to nothing, so why complain?
Simple, right? Well…in theory perhaps, but in actual execution the process left a little to be desired.
One important problem was that Initech's phone queue system didn't yet recognize when a call was coming in on Multitrode's support number. This made every call a coin-flip as to whether SJ would get one of Initech's actual clients (many of whom SJ was on first-name terms with), or some insurance person looking for the correct form to submit for fulfilling some arcane process.
As a result, CJ’s typical phone conversations tended to go something like this:
SJ: "Initech Hosting, how can I help you?" Client: "Huh?" SJ: "Multitrode Insurance, how can I help you?" Client: "Oh hi, I'm from Foobar Insurance, and we're trying to submit our MMS form through the new member page. After submitting, it isn't letting us print out the receipt page... I click on the link and nothing happens." SJ: "All right, can I just get some information from you?" Client: "Okay..." and at this point, cue the usual user ID, company ID, IE version, whether or not cookies and ActiveX are enabled, and hopefully a screenshot out of a non-technical insurance person... SJ: "All right, I'll get a support ticket submitted to our developers and they'll work on the problem." Client: "So... when can I expect to hear back from you?" SJ: (mumbled) "No idea." Client: "Pardon?" SJ: "They should get back to you within a day or two." Client: "The form's due on Thursday, will it be done by then?" SJ, completely winging it: "Well if it takes too long to fix, we can put an exemption in the system for you." Client: "Oh, okay."
After which SJ would create a ticket, invoke the appropriate magic flags to make a copy of it in the developer's ticket system, and...that would be it. Initech’s responsibility technically ended right then and there. The ticket disappeared into a black hole, and if anything ever got fixed, nobody ever told SJ or anyone else Initech about it; they just had to hope that the consultants were actually doing their jobs.
SJ spent his shifts praying that no customer ever called in asking for a status update.
Eventually, at last, things started getting better. After a month, the developers actually put a password reset link on the application's login page. just in time for the system to go live, too. It was also around this time that a bit of investigation by one of SJ’s coworkers revealed how to get into the application's client database from the server, so they could actually check whether someone had an account, what their login information was supposed to be, and even reset passwords themselves (which until then was an unheard of amount of transparency for them).
After two months, they had an actual documented procedure for dealing with a short laundry list of known issues, and some of them had even gotten fixed. And after three months it seemed like most of the more gratuitous user-visible bugs had been fixed, the big deadlines for whatever it was that Multitrode was doing with this application was past, and in general it stopped being as much of a problem.
Most of the support requests at this point were internal fixes from Multitrode which just had to be tagged and forwarded to the developer without any painful data gathering or finger crossing.
Of course the application was still slow, flaky, difficult to use and generally horrible, but at least people didn't usually call SJ about that. SJ hopes that eventually the contract will expire and not be renewed, or at least he'll be somewhere else when the next round of insurance deadlines rolls through.