Our company is in the process of implementing Marketo, which is our first ever venture into the marketing automation world. We are still in the middle of setting up our instance and going through onboarding.
I have some experience in being an end-user of automation platforms at other organisations, but I'm brand new into an admin role and all the things that need to be done in order to get Marketo up and running. And I'm feeling slightly nervous about the responsibility and ensuring its success!
So my question is - thinking back to when you or your company first got started with Marketo, do you have any tips or advice to share? Things you wish you'd known? Things I need to watch out for?
Is there any documentation available which lists some of the ongoing 'housekeeping' activities which I should be thinking about? This is definitely one area which I'm unsure about.
Thank you so much in advance!
Oh there are so many things, and this is such a good question to be asking.
To keep it short, the number one thing I would say is naming conventions. Decide on your naming conventions and get them on LOCK - make sure they're followed consistently and don't be lax on it. There's tons of stuff in community about naming convention structure (defs including a few rants from me), but this would seriously be my number one.
That and be very very selective about custom fields. Don't go creating them left right and centre
Great insight. Why is selectivity about custom fields so important in your opinion? I'll look elsewhere in the community as you suggested, but wanted to know your thoughts.
Yeah - what Pamela said. Support are the only ones that can delete fields once they've been used, and it just gets INCREDIBLY messy as an instance scales and ages if you're creating custom fields left right and centre for one-off needs. You want to be only creating custom fields for things you ABSOLUTELY need, and you want to be incredibly clear on your naming conventions for them and very well thought out about how they're used (and ideally document that somewhere).
Paul Wilson shared a brilliant tip with me earlier this year which I would implement from scratch if I had a clean instance, where you create a number of fields of each type with generic "Custom String Field 01" names, and then users can check those fields out for temporary use, wipe them when they're done, and return them like library books. I do this now and it's proven really brilliant - just make sure you have a clear process for "checking out" fields
But also little things like subscription management fields - if you're doing any custom ones here - it should be immediately obvious from the naming convention whether a true = yes or true = no. I've had scenarios where I've inherited instances and it's not clear either from the naming convention or from historical use of the field whether it's meant to be a true for opt in or a true for opt out... don't do that, it's challenging to unpick!
100% agree with Grace on naming conventions. They will keep your instance clean and make it much easier to scale. For example, we just added scoring for nurture emails only, and I am confident that all nurture emails start with "LN" so I can score on "clicks link in email, email starts with LN".
We are also implementing fields to "check out" to use on different website forms, etc. For example, we're scheduling meetings with people at an event, and they can pick their time preference and it stamps "MarketoStringField1."
Another thing about fields - you do not have to sync all your CRM fields to Marketo! We have 700 fields synced, and I'd estimate less than 100 of them are ever used. Work with your CRM admin on this. It will save you later with a much faster sync, and less confusion about what field to use where.
I really like this idea of "checking out" fields - we need to implement this!
I completely agree on naming conventions for a couple of reasons.
Other things I would mention:
There are lots of great ideas on this thread. I hope I was able to also help. Good luck with your implementation
Grace is totally right - having a strong set of naming conventions goes a long way to make sure your instance is kept tidy and searchable.
The other thing I would add to that is documentation. We run a process where every program within Marketo has a corresponding brief that outlines stakeholders, intent and goals, visualisations, description, and changelog for us to refer to.
It can be a pain to keep on top, but it has saved us a lot of time trying to work out what happened to a program 2 months/years ago when something goes wrong.
Your documentation sounds great and like something that I would want to implement. Do you happen to have a template that you'd be able to share?