You may have experienced the thrill of seeing how Salesforce.com could be customized without software development. Realizing that you could set up fields within customer records and add sales information that was important for managing and closing deals was exciting.
There was a large amount of information that could be gathered by your team to analyze and make predictions from.
Furthermore, other people could easily collaborate by looking up a record and finding out what a customer’s location, past communications and dog’s name is. It’s all right there in the Salesforce record.
But, you show up one day and you find that you can’t find the dog’s name, much less information that can be helpful for getting some follow up work done. That’s because the information is not there.
When you examine what happened, you find that your team stopped consistently entering information.
This is not an uncommon problem across the thousands of organizations using Salesforce.com. They bought the software but success was a whole other challenge.
They got in their own way and overdesigned their system.
Users and Usability
There’s a magic tipping point with Salesforce.com. As you are starting out, users find it helpful to find contact information. But as management wants more information and are attracted to the reporting and analysis capabilities of Salesforce.com, it becomes enticing to get as much information as possible.
This is where slop starts to get introduced. The users are the ones to input information into the system and management wants to get as much as they can.
When there is too much information or the layouts and flow of the Salesforce.com system become difficult to navigate or use, then users typically give up.
They do what is easiest to get their job done and may bypass all of the expectations set forth in a highly customized Salesforce system.
It’s slop and a user doesn’t want to wade through such rigor when they have deadlines and metrics on their own head.
Avoiding the Slop
If you want to avoid this demoralizing state of affairs, it takes both self-constraint and focus on specific goals. After all, software is meant to be a slave, not a master to us. It is there to help.
There needs to be a key architect of the requests and requirements from different users and managers within the system. They have to make judgment calls and trade-offs for requests from different parties while keeping a larger goal in mind.
If the goal is to make more sales, then overburdening users with multiple related data objects or endless record fields will impede this goal.
Thus, the leadership role that the Salesforce architect has should be both advisory and implementing. The dialogue between stakeholders and the architect is healthy, but having someone who can make the systemic judgment calls based on business realities is critical to avoid slop.
You want your users completely bought in and excited about using the system you set up.
You want everyone to be clear about process and steps for the customer experience.
You want real-time reporting that helps you make management decisions.
These are all trade-offs that have to be carefully managed. If you have to err, err on the side of simplicity and allow demand from stakeholders to build up. It will keep your system much cleaner and easier to use.
Otherwise, having an unusable system may even warrant an expensive and wasteful overhaul just to get to a place where working in Salesforce makes sense again.
