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.
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.
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.
Admin Hero 
These are great suggestions. This interaction with end users is a psychological dance and quite an art. Thanks for breaking down these key points.
LikeLike
I could not agree more. I think this is why I like what I do so much. Finding new ways to dance is a lot of fun. It’s amazing what you can do with some basic psychology knowledge.
LikeLike
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.
LikeLike
Thanks Graham! I have found that looking at it this way puts me into a different mindset. If the end user is always right then think of how messy your org would be. There would be no need to discuss requirements – just implement! But if we have the mindset that they are not always right, then it gives us the ability to explore options and get them as close as we can to the want.
LikeLike
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 adding random fields and that further drove down adoption. We’ve been on a mission to clean up page layouts, and that has forced a lot of healthy conversation around process, audit-ability, and reporting. As a result, we’re retiring a LOT of fields, improving usability, and we’re seeing a great response from the user-base to these changes. It’s a lot of work, but the validation is awesome.
LikeLike
This is great news Teresa! It just goes to show that the solutions provided by users are not always the best and the role of the Salesforce Administrator is critical to the success of Salesforce within an organization.
LikeLike
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.
LikeLike
That is a great suggestion Curt. User shadowing is super important to ensure that solutions fit within the workflow of the users. Thanks for reading!
LikeLike
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.
LikeLike
I couldn’t agree with you more. Thanks for the comment Robert.
LikeLike
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’.
LikeLike
Great suggestion and resource Fraser. Thanks for sharing it!
LikeLike
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 implementation, much less on an annual basis…So, solutions often get put in place that are close enough – until they’re not.”
The good news is my Sales VP appreciates my candor, but I’ve had to work up to being able to respond that way 🙂
It’s absolutely heartwarming to see admins posting about fear and anxiety, I truly mean that – in a good way :-). As SF admins, we are in all experiencing careers that did not exist even 10 years ago (yes SF is older than that, but the day-to-day responsibilities, and the recognition of the value of these to business, is still very new). I’m preaching to the choir here, but prior to SF Admins, the “line” between development and business groups (or end users) was pretty clearly defined, and there was a huge time gap between coming up with an idea or request and seeing it materialize. Since SF promotes (as they should) the Ease and Speed of platform solutions compared to “back in the day”, the “Why exactly are we doing this again?”and the real business requirements often get lost in the rush.
It takes real psychological strength to hold the line and go back to ask “Why?” in whatever style works for you, and I love to see posts about this specific issue for admins!
LikeLike
Thanks for your comments Leslie. This is a constant struggle for administrators. Just like you, I had to become comfortable with saying things like this to executives. I appreciate your comments. Thanks for reading!
LikeLike
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 this? If so, any tips on how to overcome in order to make multiple parties happy? We are not currently using the “Ideas” object. Do you think directing users to this object so more eyes are on the idea might help overcome the obstacle?
LikeLike
Hi Courtney! Thanks for the comment. You pose a great question. The answer to this somewhat depends on your relationship with the leader in question. In my organization, we are very open and collaborative and many of us are not afraid to tell the founders “no” or correct them – as long as it is in front of the right audience. However, some managers or leaders are prideful and need to be handled in a slightly different manner. If this is the case, I would take some time to ask why the answer is no in order to better understand the rational. This can be done during the conversation or afterwards behind closed doors. Again, this will depend on the leader in question. It is always good to have data to back up the request so if Ideas was implemented, you may be able to easily show that the request is valid and needs to be addressed. Otherwise, you can use a feature request record (create one uses Cases or a custom object) to track what users need and report on it.
It is never easy to manage multiple view points but I would encourage a dialogue where everyone can share their opinion. However, make sure that everyone can color their opinion with context. Understanding why someone provides a “no” response is really important to make any sort of progress.
LikeLike
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.
LikeLike
You are very welcome Vedrana! I’m glad you enjoyed the post!
LikeLike
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.
LikeLike
It’s a good thing you were let go then! I would have left shortly after that conversation! A healthy organization thrives when people ask questions.
LikeLike