One of the early decisions that a new Salesforce professional has to make is which track is best for them: admin, developer, consultant, architect, business analyst, etc. There’s a version of each of those tracks that I’ve noticed often gets overlooked so I wanted to take some time to dive into that for those who haven’t yet been exposed to it.
In all fairness, it’s more so a forgotten part of the Salesforce outreach process than it is an entirely different track. But it’s called pre-sales, or pursuits. First off, this role is primarily for consulting firms. In-house admins don’t need this particular function, although it would definitely improve their effectiveness.
Consulting firms begin pre-sales activities when they’ve identified a potential customer and they want to put together a compelling proposal. Or sometimes they will respond to a request for proposals (RFP). A team of people with skills ranging from account manager or accountable executive, all the way down to the developers or business analysts work diligently together to build a presentation deck and whatever other necessary assets are either specifically listed in the RFP or that they believe will improve their chances of winning. Their goal is to configure a Salesforce org that, once demoed, contributes positively to convincing that company to work with them.
Sometimes these orgs are combinations of prior projects. So the effort is spent tinkering with a new set of features and making sure they work together enough to demo. Sometimes it’s determined that building a custom demo is worth it, so teams build out custom components and experiences to hopefully win the business. At times, there’s a combination of both, going as far as setting up custom integrations.
The reason not all firms do this is because it’s an investment. Small teams are often required to work solely on the pre-sales effort for weeks at a time. Or sometimes people juggle working on existing client work and also pre-sales efforts. Those can make for long days. Even worse, those are wasted labor hours if the deal doesn’t close, and more deals don’t close than do, on average. So there’s a risk in putting all your eggs into one basket. Or, rather, putting any eggs into a basket too soon. You wouldn’t want to have an egg in the basket too long or else you end up with a rotten egg and a stinky basket.
Nonetheless, there are still some of us who just enjoy building new Salesforce solutions that solve different problems. I certainly fall into that camp. Most of the Salesforce systems I build, don’t get used. Either because they’re dev orgs that I created for fun, or because of pre-sales efforts that didn’t pan out, or even pre-sales efforts that did pan out but used my org as a muse more than anything. It happens, doesn’t bother me one bit because, while I may not be able to add that to my resume, I can still count that as experience added to my toolkit. I can still speak to the key processes, milestones, and design decisions required to make that system work, all of which make me a more informed Salesforce professional.
If you’ve taken part in any of my Anchor courses, how you feel tackling challenges like those can help dictate whether or not you may be a good fit for pursuit roles. What we’re essentially doing is rooting ourselves in a particular business or scenario and then building a Salesforce system to address the obvious. Then we can address the next layer of slightly-less obvious problems and/or questions. And eventually, we end up with a comprehensive system built on few requirements that still addresses the more predictable needs of the company. That’s probably 80% of pre-sales roles. Having prior experience or industry knowledge helps too, because it means that you can bubble up the less-obvious problems or questions, making your proposal that much more relevant.
All of this to say, while you’re searching for and applying to job roles, consider adding, or avoiding, these keywords to better refine your search and hopefully increase your chances of landing that perfect next job.