In part 2 of Serious Insights for Salesforce Admins second episode, host and Salesforce MVP Kristi Campbell welcomes Emilie Jensen to the show.
Hello and welcome back! This edition of Serious Insights continues Kristi Campbell’s chat with Emilie Jensen, where they discuss a familiar topic: Build vs. Buy. To listen to last week’s talk on the framework to use when deciding between building and buying, click here!
In our experience, we’ve come to learn that a new workplace’s CRM environment is like using an iPhone when you’re an Android user. No two companies' systems are the same, each having its own origin stories — unfortunately, none involve radioactive spiders. Your company’s CRM solution has most likely been a gradual project, built to the immediate needs your organization had.
We believe being aware of this natural progression is instrumental to deciding between buying and building. So much so that we dubbed this concept, “The Process”!
In line with Kristin and Emilie’s talk on this episode of Serious Insights, we’ll discuss The Process, as well as “Being Your Own Customer”, continually improving your system/having a plan, and share our recommendations.
As sports fans already know, you need to “trust the process.” Kind of like how growing prospects into all-stars isn’t a linear experience, building your CRM solution is often a ›years long process with twists and turns along the way. Typically, our solutions are hodgepodges of our organization’s needs over the years. And perfectly normal!
A phased approach to our CRM solutions is a natural result of how our organizations operate. Every Salesforce Admin has been in the situation a million times: someone from inside their organization has the next groundbreaking idea that needs automation today! While oftentimes admins have to reject these ideas, sometimes changes really are worth making. For harder skills, like those in support executive roles, these requests may be as simple as creating solutions to drive reports. Soft skill roles, like sales, may request changes to the interface, like giving access to fields. Admins themselves may even feel the need to make changes to the organization’s system in order to improve their own day-to-day. Regardless of the reason, as Salesforce Admins it’s our job to make these updates happen.
At these junctions in The Process (where we are actively looking to upgrade our solution) is when the Buy vs. Build consideration comes front and center. As Salesforce Administrator, each time a good suggestion comes around you should look both internally and externally at possible solutions. In a world with AppExchange and Salesforce Partners, there are thousands of automation and integration software available. It’s very possible that you may find a solution that fits your company’s needs that also hits your other criteria (budgets, training, set up, etc.).
Recognizing when you should think about building or buying isn’t very helpful though, right?
Well, remember part 1? The time to “Think Like a Journalist” is when we find ourselves at these forks in the road. Like catchy newspaper headlines, we need to consider the Who, What, Where, When, Why, and How of our needs and solutions. This means utilizing that framework (it’s okay if you don’t remember, you can revisit the convo here.)
Once you’re done identifying the Five W’s (and One H) you should be able to comfortably decide whether to buy a solution or build it yourself. Regardless of the direction, the decision should best meet your company’s current needs, as well as additional criteria like budget, timeline, training, policy changes, etc.
It can be tempting to want to do it on your own while overlooking a fantastically built solution. Similarly, it can be easy to find a “perfect” plug-in that is significantly more expensive than the fix you need. No matter where you are in The Process (spoiler: it should never end), the framework is here to help. By thinking like a journalist you can make better decisions for your organization, lower costs, and improve your workplace.
Your work might not make the front page, but it sure does solve Build vs Buy!
But beyond just considering buying and building, an important part of the process is:
Did you read the spoiler or did you close your eyes when you saw the alert? Be honest now…
We know you did. And that’s fine. Because, you know, we wrote this…
It may seem obvious, but a central part of The Process — and thus the Build vs Buy dilemma — is the process actually moving and growing your environment. Far too many companies, however, install a temporary solution that becomes the new norm for years. While negligible at first, these honest mistakes can result in significant losses to productivity when scaled over years.
As a Salesforce Administrator, it’s our responsibility to prevent this tech debt from happening in our organizations. We can’t just be updating our systems impulsively, though, because that may create more havoc than good.
Instead, you should develop a philosophy or architectural design for your organization's system, preferably before making major changes. This road map can help guide your decisions over the year, including creating rules to prevent certain changes. For example, sales teams may request to have access to a restricted field, but can we trust everyone in the organization with that access? Sometimes we block fields literally to prevent people from making the entire thing come down!
Questions like that are why we like to have a philosophy to our systems — a modest method to our madness if you will. If your ideal plan has rules like “don’t unlock X field”, then your answer is set, no matter who asks! Simple guidelines like this can prevent consequential updates for your system.
Further, when thinking about Build vs Buy, improving your system from the data stewardship perspective can simplify the decision-making. Where a custom field is located may feel important at the moment, but it likely isn’t from a data perspective. From a data side, a custom field’s location doesn't solve too many significant problems. It also generally doesn’t play a role in long-term business problems. So is it worth it, RIGHT NOW?
Because you’re a Salesforce Admin who not only understands The Process but the importance of improvement, I won’t patronize you and expect an answer. I know you still have questions, though, like...
How do you really go about it all? How do you stay on top of your game, especially when you’re trying to look out for your ENTIRE organization?
At the core of the Build vs. Buy, the conversation is determining which solution best fits your needs as an organization, while meeting most of your other criteria (budget, training, timeline, etc). At the end of the day, there is only one person who knows what your organization’s system needs… and they happen to sit at your desk!
It’s you. You’re the one. No one took your chair. I promise.
As the Salesforce Admin, there is no one that knows your organization’s needs as you do. From fielding constant requests and questions about your Salesforce solution to learning new and innovative solutions, you know this operation. As a result, there is no better person to be than your own customer. Whether it's for customer-facing roles or for improvement for internal productivity, you know the needs and best focus for your organization. Using our framework can even help improve the conversations that need to happen to implement those changes!
An example, when Kristi joined us here at Cirrus Insights, she felt she needed Elements.cloud catalyst, which is typically used to tie your metadata. However, she also knew it had tagging, notes, and descriptions. As a new Salesforce Admin, she used those features to catalog what she learned about the organization — whether it was something she noticed or some feedback she received. Elements.cloud let her document everything in one single place so she could make our organization better than ever. By putting herself as the customer, she was able to make the best decision for herself and us!
She adds, "During the 'getting to know you' phase as an Admin coming in to manage a mature Salesforce org, you're going to be asked to make changes to support the business before you've really wrapped your head around everything. While we had some documentation in Confluence, I was interested in something more closely tied to our metadata to help me make updates with confidence. By adding Elements.cloud Catalyst, I was able to get that relationship data around key fields, and have been able to tag and note details about fields, processes, and more while on the (never-ending) journey of discovery for our Org."
No matter what, your build’s opportunity will always come down to the complexity of the project. And if not the project, your organization, or users. To best choose between buying or building, you should have a complete understanding of a solution’s impact on your operation as a whole. By thinking like a journalist, however, and treating yourself as the customer, you’ll be in a good place!
As a part of our weekly episode, our host Kristi asks her guests to share recent media that has helped them grow as professionals. These can be anything from articles to videos that had something worth sharing or even something worth including in a build. We hope they can help you too!
To start, Emilie recommended Jen W. Lee’s Salesforce blog on why you do not want to hard code IDs into your automation sequences. For new admins, the easy-to-read article is a great summary explanation as to why you cannot hard code IDs to your automation. For pros like Emilie, Jen’s article is still a great reminder! Sometimes you just desperately do not want to look up the correct record type. You just don’t. And you want to just put that record type ID in there. You just want to fill the field and deal with the repercussions later.
We’ve all been there. And as Emilie’s recommendation reminds us, it’s not worth it. Jen even offers memorable reasons why hard coding an ID is never an option, so you won’t forget. She even offers alternatives to that tempting, but ultimately detrimental, desire.
Alternatively, Kristi Campbell recommended a Medium article by Gordon Lee. At its core, the article is about wanting to be able to differentiate yourself utilizing work and tangible experience. For Salesforce Admins, the organization systems we make (whether in Experience Cloud or other solutions) are our greatest representation of our work. In what is kind of a radical idea, the author tries to relate the experience of being a high school volunteer for a nonprofit to showcasing your professional talents. Much how volunteers leave behind references and tangible impact, you do the same with your organization; specifically, your organization’s system. Using your old work, you can show tangible problem-solving and management skills.
Both are great recommendations! We highly recommend the reads.
While we’d love to continue discussing Build vs Buy, Kristi only recorded about one hour of footage. If you’d like us to continue the conversation, though, please feel free to let us know by leaving a comment or emailing Kristi at kcampbell@cirrusinsight.com emailing our general inbox.
In this episode, we completed our talk on Build vs Buy, specifically on how it fits within The Process. The Process is essentially the lifespan of your organization’s system — constantly changing to the needs of the times. Within the process, each decision point is when Admins will confront the Build vs Buy conundrum. Thankfully, our framework is built to help this decision!
As our host notes, Admins should be looking to continually improve their operation’s systems. Stale organization systems, with outdated solutions, are a costly mistake. To best improve your system, Emilie and Kristi recommend being your own customer. You, after all, know your organization best.
Regardless of how your system changes, we hope this article helped! To listen to a candid conversation about Buy Vs Build, listen to today’s episode (we promise you’ll enjoy it!). You can also read the transcript for today’s episode below!
“The decision process for selecting a commerce solution is no exception. When identifying the path forward, businesses often face a dilemma: to buy a purpose-built solution that already exists on the market or build a custom commerce platform. Purpose-built solutions are enterprise systems that enable businesses to scale their commerce offerings based on industry and customer needs. On the other hand, a custom-built solution often puts a single need at the core of construction, such as shopping cart functionality or invoice and catalog management. Custom-built solutions are often preferred by businesses that believe this will help them maintain complete control of the process and tailor the platform to their unique needs.”
-Ray Grady, President and Chief Customer Officer (CCO) of CloudCraze