How Self Service Fails

From the Internets…

I read a post yesterday from Mike Brace at EV World entitled “Engineering Can Be Sooo Frustrating.”  In it, Mike opined on a few things, including the lack of “support resources” from other functions…

It was hard to suppress how bad I felt when I told my wife that I missed the 10-day window to renew my annual Flexible Spending account that our corporate insurance has set up for us. Without an Office Manager to keep us on those things that we didn’t do 5 years ago (but now have to) I failed to remember it myself. With HR, Accounting and Payroll down to the bare minimum number of employees (needed to keep the department open) more and more of their duties and responsibilities fall on me to see them through.

Cry me a river…

Now, I’m sure there are some knee jerk reactions from the HR world to this.  It’s not your job to hold his hand.  It’s not your responsibility to make sure he takes care of his benefits.  It’s not your fault if he is too preoccupied with other things to keep track of open enrollment when he is the one getting the tax benefit.

You have other things to worry about.  You are under pressure to reduce operating costs, not to mention headcount.  You are trying to leverage technology all day long to get people paid and keep them productive.  You don’t have “operational” process, so you have to lean out the transactional stuff, which means leaning hard on self service.  You aren’t just an administrator, you are a strategic partner who has more to offer than reminders about the employee’s responsibilities to their family needs.

And that is all true.

Except when it isn’t.

Like it or not, HR is a service organization.  And whatever other pressure you face, you have to remember why you are really there.

We recently talked about SIPOC charts.  I mentioned that there is value in thinking about your customers before you start to redesign a process.  This sounds like a great example of process design that missed something.

If your customers are living in the real world, where we all do three jobs and no one is ever caught up on their email, are you designing your enrollment process specifically to their needs?  Or are you building one that will shorten enrollment and reduce your processing cost 5%, regardless of the needs of the front line?

The key to great processes

They start with the end in mind.  And that end is the customer’s goal, not yours.  Define success from their perspective and work backwards.  Because if build something new, faster and cheaper, but the customer hates it, you failed.


  1. Ouch Dwane. There surely is a sense within HR of “get with the times people, I’m not your mother – use the ESS.” Cuz let’s be real…the EEs who don’t complete these processes on-time online; weren’t completing them on-time when using paper forms. It’s the same people. And they grew accustomed to getting multiple phone calls and reminders – but at the end of the day it just was a more cumbersome process with lots and lots of redundant paperwork and data entry. However, there are simple ways to retain the ‘human’ element even within the most automated process (i.e. the open enrollment benefit process). At any given moment, the HR staff person (cuz back there somewhere IS a person overseeing the system) can run exception reports or quickly, at a glance, see which employees haven’t completed the process (enroll or decline). And then the phone call or text message or email comes in. That final human touchpoint CAN still be retained within the newly designed process. The intent of implementing ESS is (or should be) ultimately to provide everyone with a “win” – the HR/payroll staff AND the managers/employees.

    • agree Robin, The exception report punch list is a valuable tool.

    • Ah, the exception report. Our blessed safety net.

      Of course, having an exception report and getting someone to look at it would be, in my opinion, very much part of a customer centric process. We give you the tool to do it yourself, but we make sure you meet the deadlines.

      I’m all for the technology, of course. But the technology has to support a robust process. 🙂

  2. Dwane–Such an important, valuable element that is often forgotten. Designing systems and process for the reality rather than some perfect future.

    • Agreed, thanks James. And as my organization launched self service this morning, it’s a lesson that has been in the front of my mind for some time now.

      Thanks for reading!

  3. Dwayne, you did make an interesting point:
    “Now, I’m sure there are some knee jerk reactions from the HR world to this. It’s not your job to hold his hand. It’s not your responsibility to make sure he takes care of his benefits. It’s not your fault if he is too preoccupied with other things to keep track of open enrollment when he is the one getting the tax benefit.”

    But MY job is HR’s job. I am HR’s job. Period. If your job isn’t to make my job a better fit, to increase my productivity and keep me happy, what is it? Why does my company pay you? Without me, the employee, do you even have a job? But that’s not the issue in my blog. The issue is that what I do and what you do are two completely different types of tasks, and you really don’t want me to change my methodologies to fit your lack of assistance or your task profile.

    Chances are you have the luxury of being able to start and stop your job, and your train of thought, 30 times a day and not skip a beat. Your end-product doesn’t suffer and (once again) chances are that your results would be acceptable (or changeable) every time. I would even wager that the odds are that every task on your daily list of ‘things to do’ can be started and ended within an hour; 8 hours tops. I [on the other hand] have very, very few tasks on my engineering list of projects that can be done in 40-man hours (a week) AND that’s only if I can go non-stop once I warm up my calculator. Stopping to fill out a “Denial of Benefit Claim” and mailing it to the address on the back of the notice (which I just had to do today) put an abrupt halt to everything that I had started working on this morning because (as most engineers will tell you) every time I break my train of thought chances are I make an error or missed a digit. I don’t like to start the drawing, drafting, designing, calculating and researching for my work unless I know that I won’t get interrupted for at least 1/2 the work day. Call me a prima-donna if you will but we have two completely different work ethics and means to earn a living. Why should I learn yours when you don’t have to learn mine?

    You make mistakes and people suffer emotional trauma; the company could even loose money. I make mistakes and people could not only loose their livelihood but their lives as well. No brag, just dealing in facts (which is my chosen medium).

    • Mike –

      I appreciate your response, but I get the impression you didn’t actually read the entire entry.

      I won’t defend the work I do, nor compare it to yours. I don’t know enough about your job, and I would say you don’t know enough about mine to judge it.

      But the point of my piece is that regardless of the job you (meaning the employee, the customer of HR) are doing, our (meaning HR) job is to build processes that are efficient, inexpensive, and, most importantly, meet the need of the customer. Meaning you, the employee.

      Your response seems to be focused on just the paragraph you quoted. I hope you take the time to read the rest. In the end, I think we agree.

      • Dwayne,

        Yes, we do agree. I did read the piece (and I apologies for not alluding to this first) and I did appreciate you taking the time to highlight it in your blog as something worth commenting on, especially with a view from the other side of the fence. I guess my comment was more directed to the other ‘you’, those in your audience who might sympathize with your comment “Cry me a River” and not understand the details of my grip (which, as my blog alluded to, didn’t just single out HR as a source of consternation).

        My wife has her Masters in IO Psychology and supports your point of view, She can see the logic in your train of thoughts and your comments, however she has seen many others in her profession think I am just professing to what others have alluded to: sour grapes.

        I didn’t present that perspective [above] in the first blog because it was directed towards an engineering audience. You blog afforded to chance to tell the rest of the story but to a different audience.

        We’re cool. Thanks again for your comments and your blog.

        • No worries, Mike. Thanks for replying.

          You (and your wife) are correct, of course. There are many in my profession who miss this point. But I think it is out of a lack of understanding, not malice.

          I hope our stories and exchanges will help shed some light on the subject.

          Thanks for visiting!

  4. Absoluteley agree Dwane,
    When designing such processes the VOC must be considered. It may well be that out of that survey / questionnaire the customer (the emploee) would have preferred auto renewal or a series of daily email reminders during the renewal window . However without their input into the process you would not know what was required.
    We use DFSS to design such processes and always consider the VOC and what’s Critical to Quality (CTQ) we find it helps capture all eventualities.
    However, at the end of the day having designed a process where customers have been involved in the design i feel it would be wrong to say the process had failed because someone had failed to respond to several email reminders to renew an insurance premium. Employees have to take some responsibility when using Self Service, particularly if Employers have built in checks and balances to try to mitigate any potential issues like this.
    Having said that the 10 day window seeems far too short, what happens if people are on vacation during that period?

    • Paul –

      Agreed. One employee issue does not make the process a failure. My point is more that if you don’t design with the customer’s needs in mind, you have failed. And, I think, that is true regardless of whether or not there is a problem such as this one.

      We all deal with processes that work, but aren’t user friendly or even user optimized. Those, to me, are design failures.

      Thanks for reading!

  5. Great post Dwane. HR is here to serve others, period. One of the greatest gifts in my professional life was moving out of HR for a year to manage several clinical programs. I suddenly realized there were other priorities in my organization beyond the forms, forms, and forms that pumped out of HR. I now have a great appreciation for those that juggle their primary job, plus, the additional work we expect of them.

    No more excuses HR….step up and provide world-class service.

    • Thanks, Jay. It is something that is easy to lose sight of, but creates the potential for massive failure if we aren’t vigilant.

      Thanks for reading!


  1. […] This post was mentioned on Twitter by leanhr, leanhr. leanhr said: Today at -> A discussion on how/why self service systems fail. #hr #hrblogs #hrtech […]

Lean HR is using WP-Gravatar

%d bloggers like this: