Overcoming End User Solutioning

Overcoming End User Solutioning

Every administrator experiences it. Users coming to your desk, sending emails or calling you on the phone asking for a new field or to implement a new process without sharing any part of the problem that is trying to be solved. This is called “end user solutioning.”

Administrators don’t always know how to handle these situations. As a result, poor configuration gets implemented, users get confused, and the Administrator has no idea what just happened.

End User Solutioning Example

When users need something from the Salesforce team in my organization, they complete what we can Admin Requests. The form includes several fields including an area where a detailed description can be added.

I recently received a request from a user asking for a new text field to be added to the page layout. The details of the Admin Request contained the field name and a description of where this field should live on the page layout. Everything for me to complete the request was there.

Depending on the day and the tasks at hand, even I will complete these requests without asking additional questions. But this particular day I asked for more details.

I asked the requester what this field was to be used for and she explained the problem she was trying to solve. Her team needed a way to add context to field updates on the record. The idea was to add the text field where users would indicate the changes made, the date and time and the users initials. To the requester, this was a great solution.

The user was trying to solve a problem and the solution in her mind was a new text field. While this new field would have met the requirements for the team, it was inefficient. As a Salesforce expert, I was able to offer a solution that was far more efficient and effective. My solution was to enable Chatter feed tracking on the object and track the handful of fields that they needed to add notes to. The user modifying the record would then make a comment in Chatter to add the reason for the change.

This is ultimately what we decided to do. Several weeks later, I have heard from several users that this is working really well.

End User Solution Example

via Cheryl Feldman on Salesforce Success Community

How to Manage End User Solutioning

The Administrators I have talked with want to know how to stop end-user solutioning. I don’t think that this is possible. Human nature forces us to want to solve problems. The solution isn’t to train users to stop providing solutions. Instead, the behavior of the Administrator needs to change.

Ultimately, the Administrator is responsible for implementing a solution that solves the users pain, is scalable, follows best practices and is efficient. The only solution then is to learn how to overcome end user solutioning. Here’s how to do it.

Ask for Context. Get to the “why.”

In the example above, I asked a simple question that provided me the reasoning and justification behind the request. With this information, I was quickly and easily able to present a more effective solution.

Don’t be afraid to ask “why.” Administrators sometimes feel that asking questions will put them into a bad spot with their peers or management but this is not the case. And for those who feel they need to explain why they are asking questions, preface your conversation with a brief explanation on why.

If you haven’t already, you need to listen to this podcast on ButtonClick Admin which dedicates the entire show to this simple concept. I have listened to this podcast several times and even bookmarked it for future reference.

Obtain Detailed Requirements

Don’t make assumptions. Ask the user for detailed requirements. Get them to be specific. This may require additional questioning but the more information gleaned during this initial conversation will reduce the number of follow-up conversations needed and the solution will be complete. I’ve seen Administrators make assumptions on requirements and it doesn’t usually end well. I personally have made assumptions on requirements and provided a solution that didn’t work.

Obtain detailed requirements.

Whiteboard_with_Object_Diagram

Develop a Working Model

Once you have a good understanding of the problem and know the requirements, build out the solution in a demo environment like a sandbox or developer org and present the solution.

With the example above, this was done easily by logging into the sandbox environment and making some changes to a record and showing how Chatter would meet all of the requirements.

Ask for Feedback

Demo the working model and ask for additional feedback. Obtaining user input is a great way to make the user feel like they have contributed and that their voice has been heard.

Working With Executives

Over the course of the past few jobs, I have worked through a legitimate fear of executive staff. Whenever I had a meeting with someone from the executive team, I would sweat through my shirt with anxiety. I felt like I had to please these individuals and provide them with whatever their hearts desired.

This was so bad in fact that with every position change, I made it a point to engage with executive staff as soon as possible and go into those introduction meetings with the mind set that they are just normal people like me.

I think I have worked through that fear and I can now successfully engage with executive staff and have a productive conversation. I now feel the confidence to say “no” to executives without fear of being looked down on.

If you struggle with this and fear that any answer other than a “yes” will add some sort of peril to your job, then you need to work through this. Your companies executives are people just like you and me. They eat the same food, they wear the same clothes, and they breathe the same air.

There is no reason to treat executives differently when it comes to overcoming end user solutioning. After all, executives are end users and will propose their own solutions. But just like with regular end users, you shouldn’t fear asking questions or saying no when it’s appropriate.

When I was in high school I worked in various customer facing positions and one of them was Subway. Being in food service, you regularly here the phrase “the customer is always right.” We operated under that pretense, but I never really cared for that phrase because the customer is almost never right.

But they almost always get what they want.

This is how we should operate in our orgs – especially with executives. End users are not always right, but we can almost always get them what they want.

 

Load More Related Articles
Load More By Brent Downey
Load More In Admin Basics

20
Leave a Reply

avatar
10 Comment threads
10 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
11 Comment authors
Linda TitusVedrana MadiahBrent DowneyCourtneyLeslie G Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
Katie
Guest
Katie

These are great suggestions. This interaction with end users is a psychological dance and quite an art. Thanks for breaking down these key points.

Graham
Guest
Graham

I like that line – “End users are not always right, but we can almost always get them what they want.”. Great way of putting it.

Teresa
Guest
Teresa

Hear hear! Especially when you’re a one-admin shop, it can be especially difficult to make the time to do this. My company had adoption problems, and it turned out they were almost universally related to the fact that business owners had simply dictated system design with inadequate push-back to get to the real solutions. We’ve changed this now, and we’re seeing increased adoption because we’re discovering that most of the field updates that users wanted was a lack of education in how to use Salesforce, lack of training in the existing implementation. As a result, our usability suffered dramatically from… Read more »

Curt
Guest
Curt

This is a great post and very timely. I sat in a meeting just yesterday to learn more about an end user’s request and they wanted to focus on the solution rather than explain their needs to me. In many instances, I find it very beneficial to “shadow” a user and watch how they interact with the application. This helps me more easily identify areas where I can provide immediate and impactful solutions.

Robert
Guest
Robert

As much as anything else, I think this is a process issue. End users understand business requirements, not data design or application ergonomics. We need to be proactive in these cases, establishing process where there is none, or shoring up existing processes that fail.

Fraser
Guest
Fraser

Timely post and something that we discussed recently as well. Agile and user stories are no different when a user story is written to include the “how” and includes too much detail. Ask yourself if you’ve failed the “Question Test”.

You can tell that you’ve gotten into the how or started providing too much detail when you fail the ‘Question Test’.

Leslie G
Guest
Leslie G

Great post (and comments)! Just yesterday, my Sales VP turned around (we sit next to each other) and asked “Why is it such a challenge to get SF implemented correctly, and in a way that doesn’t need a whole lot of correction a year later?” To which I quickly replied (with a smile) “‘Cause gathering detailed business requirements and walking through and then documenting every tiny step of how a salesperson does their job is incredibly tedious/icky/boring, and it seems like a waste of time for sales to stop (selling) long enough to talk and think about it during the… Read more »

Courtney
Guest
Courtney

Hi Brent! Great post! As a system admin myself, I constantly run into this a lot from our executives, leadership, super users and managers. My question to you is – how do you overcome when a seemingly good idea is decided as a “no” by leadership the minute a user requests it? Before I even have time to evaluate the situation and take in requirements? Sure, leadership should decide the direction for the system and where to allocate resources, however, users have stakes in the system as well and should at least be heard out. Have you or anyone experienced… Read more »

Vedrana Madiah
Guest
Vedrana Madiah

Brent,

This is simply amazing. Just what I needed to hear. I struggle with ton of user requests on a daily basis, and most of the time I am so excited to provide top customer support, which in most user eyes means quick turn around, that I forget the “why”. Thank you! Very helpful.

Linda Titus
Guest

Great post! HOWEVER, not all bosses feel that way. I worked for 4 months as a company where I was told at my 90 day review with my boss that I was NEVER to ask questions of the requestor. We needed to have the requestor feel we knew everything! I was appalled! It went against everything thing I had ever learned. Thankfully, a month later there was a layoff and I was laid off. Now I’m with a great company that encourages questioning.

SUBSCRIBE ALREADY!

SUBSCRIBE ALREADY!

Join the bomb diggity Admin Hero email list and never miss a post. Like, never ever!

Hizza! You're subscribed! Nothing but good times ahead!