|
After AppleLife, After Apple |
|
User login
|
One of the things that really annoyed me when I worked in AppleCare was the Knowledge Base. We were told when we started working there that it was the end-all and be-all of troubleshooting knowledge, but most of the time it came up with printer cleaning articles for an LW 16/600 rather than the answer to your question. In addition, the beast was slow. Very slow. Slow enough that if you used it on a call the other person would think you were “slow” for having to think that long. A lot of times, you felt like it. The folks that had been working there for any amount of time before my class came in showed us that the Tech Info Library (TIL) was still online, internally. It was the precursor to the Knowledge Base and, yet, was more advanced, supporting boolean searches, and was both fast and accurate. So, the KB simply fell into disuse among internal users. Time and time again we were told not to use the older server and that it would go away someday, but, honestly, when something works you use it. Then, one day, they stopped updating the TIL servers with new documents. While this was annoying, we wound up searching one and then the other instead of relying on the KB for everything. It really didn’t phase us. It was still only marginally slower to search the TIL and then the KB because the TIL was more accurate and faster, and it usually had the answer. Seeing that that plan didn’t kill the practice, there were then the meetings. Some of the KB people came to our team meetings, then some of us went to theirs. Sometimes there’d be a survey or two, or some very unlucky soul would go around asking how it could be better, only to be greeted with the obvious, “Well, the article search could actually find articles, maybe?” We thought this was just general harassment and an attempt at understanding the social reasons for using old technology rather than that new-fangled piece of crap they were forcing on us. We thought wrong. About a year later the TIL server stopped responding. It was officially dead. And with it, any hope of a call less than ten minutes. This was not today’s Knowledge Base. This was a system created by a whole other company that Apple licensed to make the KB more modern and useful. Honestly, they got ripped off. It was a piece of crap. But, as it Apple’s way, they wanted desperately a return on the investment and wasted more and more time and effort on it. Eventually, as I understand it, they went with a solution from a little company in Mountain View instead. The problem was even deeper than the search methodology, however. It was also in the content that was added to the KB. For the longest time (years) only known issues and trivial how-tos had a chance of making it in to the KB. For anything else, and especially anything involving esoterica, one was expected to actually call in to Apple for support. This gave rise to such great articles as Stay away from the Sync Services Folder and other similar “aimed at the masses” articles. The tradition is being maintained in the consumer articles, and for quite a while that’s all they would take. Someone, or several someones, actually thought that was as advanced as help should get. A couple of years ago, though, several small heros yelled very loudly that they were inhibiting adoption in large enterprises because of the lack of technical documentation. Many procedures people were using on the phones were known by rote, but the articles were turned down because the solution involved using the Terminal. Once it was explained that this market loves that there was an exception, and the floodgates opened for articles that were beyond useful and downright cool.
However, there’s still the problem of getting people to believe a phone agent when they say that something is broken. There’s some historic disconnect where engineering simply chooses to ignore phone agents. There’s some pros and cons there, so I won’t bother with that. However, it does mean that it takes a lot of evidence to make a change happen. One issue seen in the Enterprise group is that of Cyrus sucking. Cyrus handles POP/IMAP in Mac OS X Server and it uses an external database (Berkley DB, blech) to maintain meta information. It does so badly. Over time, this will break and need to be reset. Well, an article was written for that in 10.3 Server and it helped. A lot. Instead of stepping through things, we were able to just point to the article and say “Here ya go.” and off they went. Then 10.4 came out and someone decided the bug didn’t exist anymore, contrary to evidence. Happily, the only difference in the instructions was the name of the user used in the
The Knowledge Base is a great tool, now. It took a lot of brow-beating and internal displeasure before it got to this state, but its current form is fast and usable. The only caveat now is getting an article into the KB. Anyone at Apple can write one, but it can take an act of Heaven to get the proper people to move together so that it makes it in sometimes. For what it’s worth, I saw that two articles I wrote made it into the Knowledge Base months after I left Apple. That should be an indication of the process… |
This is more about the engine itself than the policies for article inclusion, but…
The company that Apple hired first, before going to Mountain View was an acrid pile of crap with no equal. Their engine was horrid and unuseable beyond compare. I had been in AppleCare for a bit over a year and a half when my manager came to me with the address for a hush-hush internal systems rollout that I and a small handful of co-workers were being asked to beta test. It was impressed upon me that I was to use this database exclusively on my calls but that I was not to breath a word of its existence, even to others in the program.
In the first week, the group reported up that the engine was completely unusable in its current form. In the second week, we reported that not only was it unusable, but not a single one of the entire group’s filed bugs had been fixed or even responded to. In the third, we all reverted back to the TIL en masse.
When asked why we weren’t using it anymore, we explained that we had jobs to do and, if the tool was unusable, we couldn’t do our jobs. Ergo, we reverted to something that worked. We were derided as being non-team players and largely dismissed from the test group and our bugs were essentially closed without comment as “biased.”
A few weeks later, presumably after a similar experience with another test group, I alone was called into a meeting with a couple of managers and a couple of engineers. Why me? I have no idea. Someone I’d never met had a stack of printouts of the bugs I’d filed and the group proceeded to quiz me about the finer aspects of some. One bug, in particular, seemed to garner quite a bit of ire.
You see, I had this impression that in a database that contains articles detailing numbered error messages… one should be able to search for that error number and actually find it. If I search for “error 119”, I better damned well find this article. The engineers couldn’t fathom why I wouldn’t search for “Adobe ATM” instead. As I explained how the error number is all I have to start with, in this case, I could see the lights starting to turn on in their heads.
Their manager saw this and tried to save face. He claimed that I was wrong and that it already worked the way I wanted. My manager shoved a laptop in his lap and told him to put his money where his mouth was. It took the man 10 minutes to realize he was wrong.
….and they still never fixed it before Apple fired them and moved to a more reliable vendor.