Someone asked me recently about Client Success Management — Huge topic, really. But briefly, from my personal experience, if you're looking to do an implementation which is the beginnings of Client Success Management, make sure you talk with not only the people the company designated as point persons, but the people who will be actually using that software on a day-to-day basis. They are the ultimate stakeholder.

Without their buy-in, whatever is designed, developed and deployed may result in project failure; money wasted — potentially a lot, and sometimes that software being abandoned. And you probably want to do this before user acceptance testing.

Ask them how they structure their day. What steps do they take, literally? Do they open a number of tabs? Do they work within one window? Adding in behaviors they don’t expect, forces people to rethink and relearn how they do their job, making them slower and more inefficient in the process. making their jobs much more difficult. No company wants that, but if the ultimate end user isn’t involved in the analysis and planning of software and how it’s designed, that can be what happens.

That’s analogous to buying someone a piece of clothing without asking them what size they are, what they do or where they work. It's also analogous to the army designing a pair of boots, without asking the soldiers who were going to use said boots, how or where they were going to use them.

When people are forced to use software that no one asked them about, or asked them how their jobs are done, it can and does tank user adoption even for Salesforce. Not only are you competing with whatever they are using, but you are asking them to adopt new software and figure out new ways of working. Taking a performance hit because the Salesforce software you set up runs slowly because of too much code on the back end, or because the page is so long that it reminds you of Argyle’s hair on Stranger Things, makes for lot of inefficiency, and a Salesforce implementation that is disliked especially if you made your users’ lives more difficult. Don’t make your users’ lives more difficult. 

Remember, simpler is generally better. Ask companies to simplify their procedures. This will generally mean less code that needs to be maintained and may break, generally at an inconvenient time. This also meets Salesforce’s guidelines of click versus code.

And finally, and this is key - just because you can, doesn't mean you should. If you're about to do something, pause, take a knee so to speak, and think. Ask yourself: should we do this? What are the long-term effects, in 6 months; 1 year of say, giving everyone administrator access and the ability to create fields? What are the implications of checking that box? 

Remember, Salesforce has that field that says "Created by" and you can't get rid of it. It's the equivalent of those little bronze plaques you see on sidewalks that have lasted a long time. For the sidewalk that has lasted a long time, it's generally the mark of a job well done. In the case of an implementation badly done, it's the opposite.