A Few Minutes with AppleCare


A survey request I didn’t mind receiving

This was originally published on my other blog, but I think it works here, too. I know from comments I’ve received on previous posts that some of you are not fans of Apple. I’m not so much a fan of Apple, as I am a developer who has to work with Apple as we create iPhone/iPad Apps for our employees.

I’m not trying to convince you to buy an iPhone, an iPad or a Mac. I don’t care what you use to do your job, pay your bills, process your photos or write your blog. If you’re happy, I’m happy. I use my iPhone for nearly everything one can do with a phone these days. I use my iPad in support of business, especially while traveling. I write my blog, process my pictures and do the bulk of my job on Windows laptops. My wife pays the bills.

Regardless of what technology, platform (if my boss is reading this, his eyes just rolled) or operating system you’re using, occasionally, you need help. Sometimes, you have to deal with a large vendor’s myriad-level-deep-voice-mail-to-nowhere. Sometimes, your request is routed “off-shore.” Sometimes, you’re relegated to a web-based process, be it a chat or an email exchange. Quite often, you’re left on your own to google your way out of a deep hole.

When I began my call with Apple’s Developer Support Group, I wasn’t optimistic. Mine wasn’t a technical issue, it was an account governance issue, and our two development accounts with Apple are governed (on their end) by over 2,000 pages of terms. I can’t share the details of my issue (try to hide that smile), but I want to share six things that AppleCare did well. So well that I would recommend that any organization, technical or otherwise, steal these ideas. Seriously, steal them! This is one case where you want to be like Apple.


The questions speak to the things Apple is trying to achieve.

1) Four simple options – There was no guesswork involved in the simple voice mail prescreening message. Choices 1-3 were binary. They wanted to know if I was involved with three very specific things. I wasn’t, so I pressed 4 as instructed.

2) Hold Music Options – This is one thing that could make all tech-support / customer service so much better. I had the option to: hold with pop/rock, hold with classical music, hold with jazz or hold in silence. Please, steal this idea, even if you only add “hold in silence” as an option.

3) Fast & Accurate – I was expecting my ‘4 – other’ key press to lead me to a long wait. Instead, in under 3 minutes, a cheerful human being picked-up. Matt asked me several questions. He repeated back the important information, use phonetic “N as in Nancy” spelling to verify details like my email address, and he summarized my problem and stated his understanding of my objective. Oh my word, this guy actually wanted to make sure that he knew what I wanted as an outcome!

Unfortunately, after all the gathering, spell-checking and objective understanding, Matt couldn’t actually help me. But, he said that he knew the group who should be able to help me. Now you know as well as I do, that this is where customer service sinks into a frustrating, seemingly endless, often circular journey of despair. My experience was different:

4) Information gathered and provided – Matt asked for a callback number, in case his attempts to transfer me failed. He also gave me the direct number of the group that he was transferring me to. He put me on hold (previous options, still in effect) for what initially seemed like a long time. Then Matt came back on the line and introduced me to Ashley.

5) Amazing – Number five is now known as “The Amazing Number 5!” I’m talking five golden rings amazing. When Ashley picked up she said: “Matt briefed me on your issue.” What? What tech support school did you guys go to? I was expecting Ashley to start at the beginning, run me through all the questions and then punt me to some no-nothing-schlep who would repeat the process. I didn’t have to repeat anything. She began with a summary of my problem and my expectations, as she understood them. She was correct.

Ashley couldn’t help me achieve the objective I wanted, because Apple doesn’t permit the type of account management I wanted to establish. She did, however, offer an acceptable alternative. She carefully explained the alternative and I agreed that, while different than what I had hoped for, it would work just as well.

6) Insure success – Before hanging up, she asked me if I knew all the steps I had to complete and if I knew how to complete them. She listened while I explained my next steps, she confirmed that my understanding was correct, and she offered to stay on the line while I completed those tasks.

Except for maybe giving Ashley a sweet southern accent, I can’t imagine anything that could have improved my experience. Again, I’m not shilling for Apple, but I do think there are some lessons to be learned from this experience.

The Cost Benefit of User Experience


What are people saying about the last thing you built for them?

I’m doing you a favor today. I’ve written about this subject before, but I’m going to spare you the trouble of searching my blog and I’m going to spare you the accidental navigation (if you’re reading this on a mobile device and trying to scroll) caused by me inserting a bunch of links to previous posts. I’m looking back over my 35-plus years doing systems development and I’m going to summarize the whole thing for you:

The people who use the systems you build deserve the best experience you can give them.

There. That’s it. That’s really all you have to read. If you are wondering how I came to that conclusion or why I’m bringing it up, feel free to continue reading but if you’re content to nod your head and even grudgingly agree with me, well then, off you go.

OK, you stuck around. You know what that means. You’re going to have to read a story.

In 1988, I was in a meeting with my boss, a representative of our underwriting department and one of my better programmers. We were discussing a feature the underwriters wanted in the system we were developing for them. First, a little background (hey, you had your chance to leave):

Nuclear reactors get shut down for stuff like refueling and when they are shut down we charge them less for insurance. The way we do this is by dividing the year into a series of consecutive time intervals, each with its own set of state variables and its own pro-rata premium. Creating a new time interval was a big deal and a difficult process prior to the system we were writing. The designer wanted to make it easy. He wanted the system to show a list of time intervals and let the user highlight one and press the “+” key to insert a new time interval after the highlighted one.

This seemed like a simple request and I agreed to it. The designer wanted more. Since we had never had such an interactive feature in a screen before (this was running under DOS), he wanted us to build a prototype. I told him that wasn’t necessary. I told him that he could see the working element as soon as it was done. He argued that a prototype was necessary because this was a “radical departure from any previous approach.” He also added that he wasn’t sure we could make this. I slammed my hand on the table and said:

If the feature you want can be programmed on a DOS PC, she can build it. We don’t have to prove that to you up front, just let her do her (expletive) job!

After the meeting, the woman came into my office and said:

I appreciate your confidence in me and I like the way you stood up for me, but I don’t actually know how to do that.”

I knew that, but as far as I was concerned, that fact was irrelevant. She could learn. The feature was going to make someone’s job easier and that was worth learning how to do.

Today, as we are in the early days of a new wave of development, I am more convinced than ever that the effort required to build a better user experience is a price worth paying. The math is simple. You build a system once every three to five to seven years but people use that system every single day. Where do you want them to register on the UI-O-Meter?

As an added benefit for those of you who stuck around, I am giving you the answers to a few common problems. Note: I have tested all of these:

We don’t have time to do this” – Give them a choice of waiting a little longer or accepting a second phase to the project.

We can’t do that in SharePoint” – Buy an add-on feature or hire one of those SharePoint whiz-kid consultants who can.

This can’t be done in SharePoint” – Move the process to a different platform.

This would take too many development hours” – Do the math. Development hours vs. hours spent using a crappy system.

If all of those fail, slap your hand on the table and sprinkle in a few bad words.

If you have your own favorite excuse and an alternate way of looking at it, please add your thoughts to the comments.

Maybe, Just Maybe

clip_image002I’ve been on vacation this past week, trying to put great distance between my thoughts and thoughts of SharePoint. I have spent most of the week doing what I love to do – woodworking and construction. Both hobbies give me the opportunity to build things and to use some pretty cool tools. Ironically, the opportunity to use some pretty cool tools brought my thoughts back to SharePoint. The manager of our small group has installed a trial of Nintex Workflow and due to some budget magic we might actually be able to afford this product this year. Our tasks are to determine two things: 1) can we get by without the Enterprise Edition (if you’re new to Microsoft or SharePoint, ‘enterprise’ is the word they use in Seattle when they mean ‘expensive’) and 2) is there enough utility in this product to justify the expense.

We have been drooling over this product for a long time, but our desire rose dramatically after listening to Marcel Meth talk about it at an AIIM New England event last November. We like products like this because we like adding functionality to SharePoint but we don’t like writing a lot of code. I have only started poking around (I am on vacation) but I’ve seen ‘Calculate Date’ and ‘Regular Expression’ categories and I have wanted those for quite some time. I also noticed ‘For Each’ and ‘Loop’ and that makes me think I can stop writing those three-cushion bank shots to force SharePoint to iterate over a list by updating an unrelated ‘index list’. I know that Microsoft has added looping to SharePoint Designer 2013 but we’re still using 2010, and I’m guessing Nintex’s implementation will shine a little brighter than Microsoft’s.

In addition to looking ahead to SharePoint 2013, we are also looking at the possibility that we will one day want to move SharePoint to the cloud. As we invest in tools, we want to be careful to work with vendors who are also looking to the future. Nintex seems to have that same view, so I think we are safe in that regard.

The main reason we look at solutions like this is because we want to be able to move activity into SharePoint. Content management is more than storing documents. Documents often get created through a collaborative process. Once created, documents sometimes cause other processes to start. The notion of content-centric applications is one that we are very keen on seeing come to fruition, and we want that to happen within SharePoint. We have had some success building solutions that let documents get created, be processed through a basic life-cycle and move to become company records, but we want to be able to handle complex processes as well.

I’m not sure if we’re going to pull the trigger on this purchase, the price is high. Being in the insurance industry, we are grounded in the concept of necessary volume or critical mass – a.k.a. there has to be enough premium income to cover the potential risk. Similarly with this product, we have to see enough utility to justify the cost. In making that determination, we will consider:

How much time will this product save? Let’s face it; we could probably do most of this in client-side code so this product has to make accomplishing our goals easier.

How often will we use it? This is really the volume question. Even if owning Nintex will reduce our development effort by 75%, if we only use it twice a year it won’t be worth the investment.

Is Nintex critical to anything? Some products are justifiable simply because, when you need to do “X” it’s the only way to get it done. I doubt we are going to find anywhere where Nintex is the silver bullet, but we should look.

If the evaluation is positive, I’m sure that I will write about our experience with the product.

Have a great Labor Day weekend; I’m going back on vacation now.

Disposable SharePoint

clip_image002I was pretty sure that I have written about this subject before, but I can’t find it so here goes. One of the things I love about SharePoint is one of the most often overlooked features – the fact that sites can be destroyed. When I say “destroyed” I mean exactly that, deleted, eliminated and removed from use. When I say “overlooked” I mean that we are usually focused on building sites to support an ongoing need or to automate a permanent process; I mean that we are thinking long-term or permanent. In our case, it’s because we tend to focus on Content Management solutions as opposed to playing to SharePoint’s strength of collaboration.

This week, we started the process of setting up a new temporary site, just as I was getting close to eliminating a similar site. Both sites were built in support of a systems development effort, and both benefit from several of SharePoint’s out-of-the-box technology.

The older site was built to organize documents related to a major redesign of our policy rating system. We used SharePoint to hold spreadsheet models, sample reports, SQL Select statements, documentation and we even used a SharePoint wiki to design changes to a user interface. We had a discussion list to track problems and potential solutions and we had a task list to keep people aware of pending deadlines. Today, as we are beginning to build out a more comprehensive site for our underwriting department, we are moving the useful artifacts from the development site to a permanent home. Soon, we will simply delete the old site. I must say that I wish SharePoint had some of the features of my daughter’s old game, Kid Cad, which let you delete structures by running a bulldozer through them or by using explosives. Microsoft could have at least added some sound effects to list, library and site destruction.

The new site will be used to help us as we design and develop a replacement for our foreign reinsurance management system. Right now, we are simply providing access to some reports that are being used to verify our data conversion process. As the system grows and as we start breaking ground on design issues, we will likely expand our use of SharePoint. This makes sense for a few reasons.

Proximity – If you’ve been reading this blog for even a little while, you knew that was coming. Having the things you need clustered together is a good thing. People like being able to find everything about a project in the same general area, and SharePoint allows us to quickly assemble highly functional little areas.

Feels Like Home –Yeah, I’m dreaming, but people are getting used to SharePoint and we are starting to benefit from the fact that they generally know what to do to get from A to B and how to get back to A. That may not sound like much, but navigation was a big complaint early on, so either people have figured it out, or they’ve stopped complaining. We have already delivered some reporting solutions to this department in SharePoint, so I think the feeling of familiarity will actually help us.

Easy to Delete – I have been doing systems development for 35 years, and one thing that hasn’t changed is the amount of stuff that gets generated. Not only do we create a lot of tables, diagrams, reports and data, we tend to spread it around, and forget where we put it. I am reasonably sure that I could find documents related to development projects from the early 1990’s if I looked hard enough. When we do tear this site down, just like the one I mentioned earlier, it will go in one smooth motion.

SharePoint sites can be made to stick around and serve future employees, but they can also be built for a single, temporary purpose. That’s one of the good things about this platform. Unfortunately, humans have a tendency to hold a certain pride of authorship that causes us to keep sites after they have served their purpose. We tell ourselves that “this data might be useful someday…” or “we may need to show this to the auditors…” or “we may want to review this when we make the next change…” Those aren’t hypothetical; I’ve said all three of them before. If the site is good, make it a template, and then light the fuses.

Information Management 101

clip_image002When AIIM decided to increase their emphasis on people, and spread their net beyond Content Managers to attract Information Professionals, I was thrilled. It may be minor semantics, but ‘information’ is easy to understand and ‘content’ – well content makes me think of ingredients. Ingredients are sometimes managed, like when a factory produces bread, or shampoo or beer, but ingredients are just as likely to be thrown together when you and your 6-year-old bake a pretty good cake. Ingredients sound like the stuff hidden in the fine print. Information sounds important, it sounds vetted and validated and downright useful. I decided to launch a series of training sessions around the concepts of information management because we are involved in a wide variety of systems development projects right now, and many more lie ahead.

The first training session was short, in fact I finished 5 minutes ahead of my 45 minute goal, but that may have been the only thing that the audience enjoyed. The message was simple but not entirely appreciated. That we are all ‘information professionals’ sounds flattering, but pointing out what constitutes ‘professional behavior’ isn’t so appealing. One of the slides that wasn’t accepted well at all was the one titled “What’s Not a System”. From the thousands of things that aren’t systems, I chose four that cause the most problems for me:

Templates – Word, PowerPoint and even SharePoint all make great use of templates, but the idea that building a solution from a template is enough to insure consistency, reliability and usefulness is folly. Templates are like the recipes that guide our use of ingredients. We can change templates, ignore portions, delete portions or put the wrong things in the wrong place. Saying “I used the template” isn’t really the equivalent of saying “I followed the rules” – It’s more like saying “I had the rulebook open at the time.

Spreadsheets – I like to think about spreadsheets the way I think about sports cars. In the hands of the right people, they are both fantastic. If the people are unskilled, unwilling to follow the rules of the road, on the wrong road or trying to do the wrong thing, the end result will not be pretty. You can move furniture in a sports car, but… Spreadsheets are good at so many things, but pretending to be an automated system isn’t one of them. Spreadsheets are fragile, hard to debug, hard to document, way too easy to copy (and then confuse the copies), and way too easy to be made to look official. Even worse than when people try to use spreadsheets as a data processing system, is when they try to use them as a content management system. The simple row-column interface of a spreadsheet encourages people to store, track and categorize stuff the way the top left kitchen drawer attracts gadgets. When you go back and try to sort and filter your list though, you realize that ‘Cars’ are not ‘Automobiles’ are not ‘Chevys’ are not ‘Vehicles’ and so on and so on.

Folders – My target here wasn’t just the myriad file folders on the remaining share drives in use on our network. I also took aim at the SharePoint libraries that were created, from some of those file folders. Folders and unmanaged libraries are not systems, and they provide minimal (at best) support for managing information. Yes, folders do help us to organize information, but they can’t enforce rules, they can be moved, renamed, and they can hold so many things that don’t belong in them that they are the top left kitchen drawer. Folders are a good starting point, if you have better places to put the things that are in them and if you are willing to throw some things away.

People – Actually, in a failed attempt to be cute, I said “You” are not a system. I went on to explain that people are pretty unreliable when it comes to managing information. People make the rules, but they also forget the rules they make. People take short-cuts through the processes they define, ignore the procedures or convince themselves that rules and procedures were meant to apply to “other” people. The most dangerous thing about people is that they think, and when they think, they convince themselves that changes should be made and then they make them. Systems can change, but only when the changes are confirmed to be appropriate by everyone who will be affected and then only under the control of the same process by which the systems were built. I wish people wanted to manage information the way some want to play football, then I could try something like this.