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.