A Few Minutes with AppleCare

email

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.

Survey-3

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.

In Search of Value

Value Hierarchy

Apologies to Maslow

One of the goals that I have maintained throughout my career has been to add value to a process. Long before SharePoint, in fact long before (OK, little before) Microsoft, value was a key requirement in the systems I was building and designing. As a young systems analyst, I remember receiving strange looks from my “customers” when I would ask: “how would that report help you?” I used reports as an example because people always seemed to want more reports than they needed. Once, when I moved a system from one platform to another, I didn’t bother recreating 90% of the reports. I promised to build each one as the need became critical. I only ever recreated about another 5% of the missing reports.

I would get equally strange looks when I would ask my IT colleagues: “how would that add value” or, somewhat more surprising: “how can we build this and be sure we are adding value?

Don’t let me paint too rosy a picture. I’ve built my share of systems that missed the sweet-spot of the target and I’ve left more than a few valuable features laying on the cutting room floor. Systems development has always been affected by drama and budget, in addition to logic.

As I am managing what will likely be my last long-term development effort, I am focusing more than ever on value. I have 3-5 years left to make a start on a new generation of systems, and if I am successful, those systems will be built on a foundation of “adding value to a process.”

I haven’t had much to share on this blog in recent months, but some projects are reaching a point where I can talk about them in generic terms. In most cases, I can’t talk about the work, because I’m not doing it. I can’t talk about the players, because some would rather not be a part of my blog entry. I can’t always talk about the details of the project because legal/accounting/human resources – ‘nuff said. But I can talk about goals and objectives and the way a focus on value has led us to some interesting decisions. Decisions I might not have made back when I started this blog and was bent on using SharePoint whenever possible.

By way of introduction to what I hope is a small series of blog posts (maybe enough to satisfy @Sympmarc’s Saturday addiction) let me share a couple of thoughts on how we got to this point.

Success moves you higher – I am old enough to have participated in systems development projects where the primary goal was to automate transaction processing and save money by eliminating jobs. Oh, we told ourselves that we were improving accuracy and letting people focus on higher-order tasks, but we were also letting them find those tasks at a different company. By the time SharePoint became available, we were way beyond that kind of development and we were looking for ways to use the information we had been gathering. SharePoint offered us a way to move up the hierarchy shown at the top, just a bit.

Failure also moves you higher – The reason I put the “Process Improvement” layer in quotes and in red and with the snarky bit at the end is because it wasn’t always the result. Often, process improvement was a collective bridge too far. Business leaders wanted magical solutions and technical managers and staff couldn’t wait to buy/build/use new toys in pursuit of that magic.

Automating a Business Process

There are times when you can run the table and automate the whole thing. There are also times when that would be a bad idea.

The diagram above illustrates where we sometimes went wrong and how we are correcting those mistakes. Consider the five boxes across the top. Occasionally we have felt that we could automate all of them. In fact, we could. Unfortunately, automated analysis and decisions, by default become arbitrary. A report is on-time, because it is not yet late, or a report is late the moment the time allotted has passed. People on the other hand, understand that a report nearing its due date may be in trouble and people understand that sometimes life gets in the way of an arbitrary due date.

Note: I have been doing this stuff since the ‘70s and yes, I know that systems can be made to be more holistic in nature. However, the effort in building those systems, as well as the effort to maintain those systems is very often too high. Humans are much better at making holistic decisions than machines.

We have recently taken technology out of some steps of a business process that we had previously automated, in order to improve the process. Instead of automating all of the steps, we are focusing on “what information would help humans complete this step easier/faster/with better results?” I put this in the win column because we have the information we need (because we built good solutions in steps one and two). Now, by utilizing SharePoint’s native features, we can provide good information for people to consider in steps three and four. And yes, since nobody wants to do recordkeeping, we will automate that last step.

That’s it for today. I have some stories in mind that build off of this foundation, but those can wait for another day. Maybe not next Saturday, but let’s keep this a Saturday kind of read.

Proximity Revisited

imageEarly in the life of this blog, I wrote several posts about ‘proximity’ and how important that attribute is to the user experience. I was recently reminded of that fact, and I realized that I my previous examples were too limited.

I was talking about designing a home page or a site page with all the appropriate web parts and without any of the inappropriate web parts. So, if you need to see a task list and a calendar, both of those should be represented on the page, not just sitting over in the quick launch area. Conversely, if you don’t want to have a picture on your site, then you should delete the one of those pretty people.

I also mentioned proximity in association with building dashboards. Having everything that you need being available at a single glance is the key benefit of a dashboard, so I guess my emphasizing proximity wasn’t much of a revelation. I also talked about proximity in terms of business process automation. As our engineers work though the recommendations resulting from their inspections, we tried to give them a view of each recommendation’s life-cycle that was meaningful.

It sounds like I covered all the bases. But, you know that I’ve never written a blog post with less than 250 words, so I must have missed something.

Earlier this year we built a payables process in SharePoint. People can select a vendor, enter a payment request (invoice) and spread that invoice around (allocate) to all the various GL accounts that are affected by it. For example, when we buy a new laptop for someone, we might buy them a case. Those are different types of expenditures.

I have always looked at accounting from a “money in” or “money out” perspective but our accountants seem to be in agreement with my Management Accounting professor – you have to pay attention to stuff like this.

Anyway, the system does all of that stuff reasonably well but there are a few things that the accountants wanted it to do better. Fortunately, one of the women in accounting is also working part-time with my team. One of the things she told me that they want isbetter views of the transactions at all of the various points. They have a view that shows payment requests that are pending, requests that still need someone’s approval, payment requests that are approved but not processes, as well as requests that have been paid and requests that were voided. Seriously, money in / money out works a lot better.

When I sat with her to find out what they wanted, Iimage experienced that old familiar feeling. The presence of that gap – the gap between what people can imagine and what they can’t. In this case, that gap separated the end users from what we SharePoint folks know as Data View Web Parts. As we work together, we are bridging that gap.

She said that they need more detail in the view(s). When I asked “why?” she said “sometimes, we need to know things about the vendor, or we need to know what GL accounts had been affected by this payment.” That made sense, except for the “sometimes” part. I don’t like views that show things that are only needed sometimes. I prefer views that show what you need ‘all the time’ but can be made to show what you need ‘sometimes’ on demand.

I wired up a imagelittle example of one view with the addition of two Data View Web Parts. One web part contained more detail about the payment request and one contained more detail about all of the allocations. I connected those web parts – OK – I really want web part to be one word…webpart, why can’t we just call them webparts – Sorry, I just had to say that. I connected those web parts to columns in the view. SharePoint easily let me show those columns as links, and now when they want the additional detail, they can click on the link and populate the web parts. If they click on the payment request ID, they get its details and its allocations. If they click on the amount, they just get the allocations. Easy-peasy.

To keep all this stuff proximate, we also have to constrict the original view by limiting the number of rows it contains. Most people hate paging, so I gave her an array of options to consider. All Payments, All Payments This Month, All Payments this Quarter, and then of course, this year, last year, etc. I showed her how we can set the page limit and how we can dynamically filter the list to render things like All Payments for a specific vendor. Then, I gave her a homework assignment – go back and sketch out the perfect view. Next week, I’m going to help her build that perfect view. Maybe then I’ll have a better illustration.

Will We Ever Get This Right

Almost every IT shop has an inventory of projects. imageSome have been on the shelf for a long time and curiously, some pop into inventory and immediately get addressed. What causes one project to leap ahead of 10 or 20 others? Well, it might be an executive sponsor. It might be a pressing regulatory need. It might be a staffing change. Sometimes, it’s not logical. We are reexamining our priorities this summer for all these reasons. I’ve been at this a long time so I take change in stride. So far, nothing has ever stopped the show from going on.

Ironically, I started thinking about what drives technology projects not from the perspective of a producer of technology, not even as a consumer, but as an innocent bystander.

I had to see a doctor this week. I hurt my shoulder and I needed the advice of an Orthopedic specialist. My primary care physician has recently added an Orthopedic PA (Physician’s Assistant) to his staff so that made scheduling easy. No referral required. Unfortunately, when I sustained a similar injury to my other shoulder several years ago, I was under the care of a different PA who was working with a different physician. Those records were “transmitted” verbally by me during my exam. Later, my wife quizzed me – “did you tell her about the…?” How nice it would have been for all of that information to have been available during my exam. “Oh, it’s in the works” I’m told, but it’s probably a long way off.

Fortunately, this PA did have access to my medical allergies and knew better than to prescribe any form of NSAID in the Propionic Acid class, to which I am allergic. She prescribed a topical gel from a class that those records indicated that I am not allergic to. Yay for accurate and complete, albeit isolated records!

An hour later, I was at the drug store trying to get that prescription filled. The ointment she wanted me to use is not an approved medication according to my medical insurance provider. The drug store has that information because they have access to my insurance provider’s database. They have access because having access allows them to charge me the right amount and get paid faster. My doctor, who might have prescribed something different had she known what was approved, has no such access.

I explained why my doctor had prescribed this medicine. I explained my allergies and how this stuff is in the Acetic Acid class rather than the Propionic class. They, the clerk and the pharmacist, both felt that that explanation would convince my insurance provider to agree to pay for it, but only if it came from my doctor. Not wanting to wait for the wheels of medical deliberation to turn, I agreed to pay the “retail” price instead.

Once the clerk confirmed the price and my willingness to pay the price, she handed the script to the pharmacist who had been at her side during the entire discussion. Before I got to the waiting area, the pharmacist called me back to the window.

Our records indicate that you are allergic to NSAIDs.

Without being snarky to the last human being standing between me and relief from pain, I recalled the conversation we had just finished. I explained again that I appear to tolerate a specific class of NSAIDs and that this gel was in that class. He apologized and then he explained.

I heard your explanation and it makes sense. Our system doesn’t differentiate by NSAID class; I wish it did because this is common. As for making you provide the information again, I am only following protocol. I have to check a box that says you provided this information to me in response to my question about your allergy.”

Oh, it’s a liability issue. If I were to end up in an Emergency Room, this drug store doesn’t want to be in court having their employee say “well, I overheard him say to our clerk that…” I get it.

I get all of this:

Having accurate and complete information helps people make better decisions.

Having access to information can sometimes save money.

Information is good but authoritative information is better.

Protocols are important and should be followed.

I also understand that the systems that exist and the connections that have been made are the ones that either save money or reduce liability. The ones that would merely benefit the people involved are still sitting in inventory. ROI, whether you prefer ‘return on investment’ or ‘risk of incarceration’ can’t be the only driver when deciding what system to build. Sooner or later, we have to find a way to place value on the information that would simply help people do a better job.

Business – not SharePoint Solutions

imageTwo recent projects have caused me to realize that SharePoint has finally arrived in our small organization. I don’t mean that it’s here and in use, it’s been here since 2006. I don’t even think I’m talking about “adoption” the way that word is often used with respect to SharePoint. It’s arrived in that it’s now part of the permanent landscape and that’s a good thing. It’s good because people aren’t fighting the idea of SharePoint. On the other hand, SharePoint has only managed to shove itself into the mix. It isn’t the dominant player. It isn’t calling the shots. It’s on the team but it has to play by the same rules as everything else.

One of the projects we are close to completing has SharePoint in the leading role. The application is a portion of our payables process and people are now creating payment requests in SharePoint. Other people are reviewing those requests, adding comments and still other people are approving those requests. If all of this lived in SharePoint, SharePoint would rule the day. However, the back-end of this process is a desktop application that takes those approved requests and prints checks. That application also creates ACH transactions and wire-transfers. Eventually SharePoint will be the starting point for all those transactions, but everything SharePoint does has to feed that system.

Other processes are involved too. For example, we can’t present a payable for payment without making sure that the person / company we are trying to pay isn’t a terrorist. In that case, the back-end process is actually the starting point. We check vendors before we authorize them to be paid and we continue to check to make sure they don’t become terrorists. I suppose the back-end stuff could be done in SharePoint but it’s easier the way we’ve done it.

Note: All of those processes involve data that is stored in SQL Server and my crew had to battle with every imaginable issue (all of them permissions) to get those connections working reliably.

The second system we are working on is a storage system for some very important information. In order to make sure this stuff is available when we need it, it will exist in SharePoint on premises, some of it will be replicated in SharePoint Online and some will be replicated on a bunch of iPads. In this case, SharePoint is cast in the boring supporting actor role. Yes, SharePoint is holding all the stuff in house and holding all the stuff online, but the iPad app is the cool kid. Accordingly, SharePoint has to try to fit in.

We decided that the way the content is organized in the iOS app will determine the way it is organized in SharePoint. In other words, the list and library structure in SharePoint will correspond to the structure of root categories and detail topics in the iPad app. The app design is intuitive, something that SharePoint struggles with out of the box. The design is simple enough that it won’t take much work to make SharePoint look and feel consistent with the iPad. Still, a few years ago, this wouldn’t have been a consideration.

SharePoint and SQL Server was an arranged marriage and like many of those, it works, but it’s weak on love. We are making the connections work, the connections do work, but they all seemed to have taken more effort than should have been required. SharePoint and iPads? I’m pretty sure that was never part of anybody’s plan, but it has to work. We have to build a solution that spans those platforms and looks like it was meant to be.

Welcome to the real world SharePoint.

Divide and Conquer

imageWhen I was making the coffee table that sits in my office, I learned a lot about bending steel. Specifically, I learned that bending square steel tubing isn’t easy and often doesn’t end well. Some bends were wide enough that I could negotiate the turn and repair the damage, but others were just a bend too far. For those, I took it in steps: cut, bend a little, cut again and then weld back together. I thought about that process this week, as I struggled with a workflow issue. I’m not sure if this is a common issue, but it seems to come up for us quite often:

“Is it better to build one big, ugly, complicated workflow or is it better to create a few additional lists and spread the work across them?”

We almost always tend to spread the complexity around. In the solution I’m working on today. I need to accomplish three major steps in order to reduce a 12-15 page Word document into a series of entries in a custom list:

  • Parse all of the recommendations out of the Word document
  • Determine if the recommendations are New, Open, Pending or Closed as of the date of this report, and
  • Create entries into either a custom list of recommendations or in a custom list of updates to existing recommendations.

All of this can be done by a workflow, but it’s a complicated task. A single big ugly workflow would need to keep track of individual recommendations, whether they are new or some other status and look up the details about the inspection report metadata and copy it into the other lists. I opted for a process that involves two additional custom lists:

One is a list of what I call “splits.” Splits are the big chunks of parsed text. All the new recommendations are in a split. Likewise, all the pending recommendations are in a split, and so on. A workflow that runs when the splits are created doesn’t have to determine what kind of recommendation it’s dealing with, they are all new, or pending, or some other status.

That workflow parses all the recommendations into individual entries in the second list. That list is then built up of individual recommendations which have a status (new, pending, etc.) and all the metadata that they need to be transformed into an item in the ultimate destination list. A final workflow that runs as these items are created takes care of dispatching those items.

The cost of this solution is the creation of a couple additional custom lists and a bit of duplication of data (although the items in these intermediate lists can safely be deleted). The benefits include:

Easier to plan – The overall process is easier to plan and stage. The process becomes a fairly simple routing exercise. Big boxes of the same thing arrive at one list where they are opened, separated and distributed to a second list. It’s like a wholesale-to-retail operation.

Easier to build the workflows – Rather than a complicated workflow with lots of variables and lots of steps, I have three single-purpose workflows that are each of a manageable size. I built the process in discreet steps, only moving forward once things are working at each level.

Easier to control new vs. update action – By the time I need to know whether to create a new recommendation or an update to an existing recommendation, the list item I am working with includes that information as well as everything I need to create those items.

Easier to debug – This is a big deal for the developer (me). As I am configuring these workflows, there’s really only one way any of them can fail. That is so much easier to deal with than a workflow that can fail any of three or more ways, especially given the current state of SharePoint Designer’s debugging tools.

Easier to rerun – Some of the workflows trigger alerts, some set metadata in other lists and change the status of other processes. Working in smaller segments means there are fewer things to fix if something ultimately goes off the rails.

It might be tempting to just keep on grinding out steps in a single workflow. However, dividing the steps into logical groups and taking advantage of storing partially processed items in interim lists is a very powerful concept. This approach makes design and development easier. By the way, it worked for that coffee table too. If you want to read more about that project, take a look over here.

Baby Needs a New Pair of Shoes

imageSometimes you get a little beyond peoples’ ability to imagine when you start describing what, as far as you’re concerned is a simple SharePoint solution. It’s not hard. Depending on how often your audience has been exposed to SharePoint, their ability to imagine might be quite limited.

That is not their problem

That is your challenge.

We are facing this challenge right now, and we are going to work through it by building a straw man solution. If we are lucky, we will roll a 7 (since many of you just returned from Vegas) and we will be able to continue building from our first result. If we are not so lucky, we will roll an 8 and we will be able to continue to roll and maybe work our way into another 8, at which point everyone wins. If we totally miss the boat, we crap out, we tear it down and we start over. If we don’t go nuts, if we don’t spend a lot of money, if we don’t invest a lot of time, none of those options are going to make me cry. Keep in mind that I am not the one building the solution that we might tear down so someone on my staff might cry a little.

Why would I do this? Why don’t we just ask people to trust us? Why don’t we draw a bunch of illustrations in Viso and PowerPoint and make them sit through a boring presentation full of buzzwords and jargon and technobabble that none of them will understand? That approach has worked in the past…hasn’t it? Oh, right.

To keep my customers happy and prevent my people from crying, we had a meeting to discuss the approach. We reached an agreement with the manager of the business unit that we will be working with and we established a few key assumptions about the solution and our approach:

Assumptions – The process will require support in the form of a site on our on-premises SharePoint server that will house critical support content and historic content and business records. The content deemed critical for operational support will be replicated in a SharePoint Online site. The stuff that is so critical for operational support that we just can’t risk ever being without will be included in an iPad app.

If you’re wondering why we don’t just move the whole shooting match to the cloud, there are two reasons: 1) Bits of the historical information processing relies on add-on products that aren’t fully in the cloud yet, and 2) We’re scared. OK, we’re not scared but some people are and we think that asking them to take baby steps is better than asking them to run a marathon.

If you’re wondering why we don’t just point the iPad at the SharePoint online site, there are two reasons: 1) Bad things happen. During the snowstorm in 2011, we lost power for 10 days and cell service for 3 (we did have a working land-line phone), and 2) We want a dirt-simple process and nothing says simple like pushing a few buttons on an iPad.

If you’re wondering why we aren’t using a different brand tablet, one that might work better with SharePoint for example, well lets’ just say that we aren’t and leave it at that.

Straw Man – We have agreed to focus on one library that we know will be included in any solution that anyone involved could dream up. We will replicate that library in SharePoint Online and we will wire up a quick and dirty workflow to keep the in-house library in sync with the online version. We will also create a one or two tab iPad app that will include the information that is related to the content in that one library. The manager of the customer department likes the approach. We will show the straw man to everyone else involved in the project to help them better imagine the nature of the full solution. We have an agreement, we will tear this down and start over if we have to, but we don’t want to do that twice.

If you know me, this post might seem a bit out of character. I like prototypes, but in the past I have always said that prototypes should be disposable. This won’t be a prototype, this will be a gamble but it’s a risk I’m willing to take.