I learned a new buzzword today: “technical debt.”
I don’t know how I went so long without hearing it, because it is ALL. AROUND. ME.
Technical debt is defined by the all-knowing Wikipedia as:
“A concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.”
Oooh. Definitely guilty of doing that in some of my past orgs.
It’s so tempting, when you’re part of a small team that hustles and wants to GSD, to choose the fastest path to the outcome you want to achieve. But what’s the cost of that? Are you just punting the hard work down the road? At what point does that become unsustainable?
There are a few places I see technical debt popping up in Pardot:
1) Decrepit, decaying lists
Bad data. We all have some. And the more time you delay addressing it, the more complex it becomes.
Is it time to create some standardized processes around importing lists, validating opt-ins, managing duplicates, and purging old leads and contacts?
2) Haphazard campaign & folder structure
In a hurry?
“Just save to the website tracking campaign and the uncategorized folder for now, and I’ll fix it later.”
In the history of Pardot, I would wager that less that 10% of people taking this “time saving” saving short cut actually go back and put their assets in the right spot. Invest the time to come up with a rational organizational structure, stick to it, and your future self will die of gratitude for it.
(P.S. I actually worked in Pardot for several years before the innovative debut of foldering. THAT clean up project was not fun, let me tell you.)
3) Naming conventions
A standardized way of labeling campaigns, lists, email templates, files, and more is so helpful when it comes time to do reporting or to locate an asset from a “remember when” conversation.
And it’s so much easier to do on the front end rather than trying to clean a pre-existing mess.
You can only label so many pictures “Picture1.png” before you’re forced to ask yourself if there’s a better way.
4) Workarounds in Pardot instead of using SFDC
One of the simultaneously great and terrible things about Pardot is that you generally have several ways to accomplish what it is that you want to do — some in a more automated fashion that others.
Some tasks, though, are generally better solved using the tools native to Sales Cloud. If I could make Process Builder my lawfully wedded spouse, I would.
If you don’t really understand the power on the Sales Cloud side of the house, spend some time with your admin or consider taking a training course. It can open your eyes to a whole new world of resources you can draw from.
5) Neglecting information architecture
It’s so easy to add custom fields in Pardot! And in many organizations, Pardot is under much more relaxed governance that Salesforce — you can go right to marketing with changes, and not have to funnel through a slow IT ticketing process or go through rounds of internal reviews.
So the temptation to put things in custom fields that maybe shouldn’t… or to use tags instead of creating and mapping the requisite fields… I totally get it. But you’re creating extra work down the road.
6) Manually managing lead assignment
When you’re just getting started and only a handful of leads are coming in, a lot of times I see marketing departments say things like:
“Oh just send me the notification and I’ll forward it on the the right salesperson.”
If you want to grow your business and your marketing department – act like the team that you aspire to be. Spend time mapping out the process that makes the most sense, work through lead scoring, and then configure the busines logic in either Salesforce or Pardot.
How does a lead get captured? What nurturing activities take palce? When is it ready for sales? Who decides what’s “qualified”? How do you close the loop on reporting? All worty questions to work through with your team.
7) Scalability of forms
This is one I didn’t quite appreciate until I had the opportunity to support a Fortune 500 deployment of Pardot. A common workflow for me, in past roles, when creating forms and landing pages is to save a copy, make some tweaks, adjust completion actions, and then deploy.
But if you start increasing the number of products you have… or webinars… or any other type of activity that requires a form… over several years… the number can very quickly explode.
You may find yourself running up against org limits on number of forms, and paying a hefty fee to upgrade. But even more costly is the additional complexity involved in reporting, training, and searching for the content you need.
Are there opportunities to reduce the number of forms you have? If you have closely related forms on several pages, could you use hidden URL parameters to consolidate these and ‘recycle” on various pages?
8) Effing tags
I have a love/hate relationship with tags. In a bind, they’re pretty nice. They can help you move quick and do things on the fly.
But if you’re using tags to capture a data point that you’ll need to use and reference in the future — use a custom field, or a list, or a campaign, or something (anything) a little more permanent.
9) Skipping the Email Preference Center
I’ve worked with several companies that only offer a global opt out — because they just never “got around” to setting up a pref center.
According to a survey done by ReturnPath, 47% of people say they’d “opt down” rather than “opt out” if you give them the option.
Just do it already. It might take you a couple of hours to work through the logic, but it’s totally worth a 47% decrease in unsubscribes.
Technical debt in your organization
Again, I’m super guilty of this, so I don’t intend to be even the slightest bit preachy here.
But when you find yourself taking shortcuts, ask yourself… are you REALLY saving time, or are you just borrowing it from your future self? Is your future self going to thank you, or shake their fist screaming “WHY?!”
Think about it.
Are you a teeny bit guilty too, or am I alone here? What sources of technical debt do you see with Pardot?
Brilliant!
You say “Are there opportunities to reduce the number of forms you have? If you have closely related forms on several pages, could you use hidden URL parameters to consolidate these and ‘recycle” on various pages?”. Do you have an more information about how you would use hidden URL parameters?
You create hidden fields on your forms and populate the hidden fields with ‘context’.
A Salesforce Campaign ID is a really good one, but a bit hard to do because we need to pass that into SFDC and have a workflow in SFDC to actually do the SFDC Campaign assigment off the ID on the Lead/Contact record.
Gated Content file name & URL are two great ones as well. Now you can have a SINGLE gated content form, and pass the context of this particular form field and use Merge Fields in the thank you content to provide the link to the file download as well as in the in the autoresponder email. This one just works, and is a great way of getting away from one of the most common duplicate form types.
You can pass along a product line as a hidden field. You can use this for Pardot content delivery, or use this inside SFDC for Lead routing to the correct sales team.
All of these are great for pushing down the form count in Pardot. You still need to have a large number of forms in your CRM that can hold onto the hidden field details. This isn’t really much different between using lots of different form destinations, or some hidden fields for each different page. It’s still work for the web team either way.