Top tips for onboarding new martech vendors

There are plenty of virtues to engaging a new vendor. In addition to bringing new capabilities and functionality to an organization, they also bring a fresh perspective. However, onboarding a new vendor seems far easier than it actually is.

The onboarding stage is crucial to establishing a positive and productive client-vendor relationship. Fortunately, martech practitioners can help ensure onboarding proceeds smoothly. 

Contract gotchas

The contract negotiation and approval phase is likely complete before the project kickoff, but it’s important to keep project stakeholders informed during this phase.

In an ideal scenario, martech practitioners have had a chance to engage relevant stakeholders to:

• Determine the true business needs.
• Identify how a new vendor will support organization-wide goals.
• Establish solid KPIs.
• Rule out any potential solutions already in place at the organization. 

These activities will help determine what exactly is needed in a contract.

Once that’s done, stakeholders should review specific contract parameters before executing the contract, as these will impact the project and the ongoing relationship. Key considerations include product support, the number of iterations allowed (especially important for design approvals) and training provisions.

Requirements gathering

Whether two people or a larger group are involved in onboarding a vendor, plenty of assumptions are made. The more acquainted people are, the more they understand beyond what’s said.

For instance, when a new vendor is brought in to enhance an existing platform (like a website), there is a lot of existing functionality to consider. Requirements should factor in how new features affect or interplay with existing functionality.

An existing vendor who has completed several projects on a platform will have learned and accounted for existing functionality. Thus, the client and vendor may no longer need to explicitly mention many things in the requirements.

However, a new vendor will not have the same background. As a client, it is important to account for that when providing requirements. You need to explicitly connect new features to existing functionality for the vendor. It is not fair to expect them to know what they have not had a chance to learn.

Current state

If you want to change a feature or functionality, detailed current-state documentation is helpful. It helps the vendor understand the current setup and visualize the desired future state more clearly.

The great thing about martech documentation is that it helps prompt folks to ask questions and mention things that are not on their minds. This is a great way to jog people’s memories.

Do you want to change features and functionality that aren’t out of the box (OOTB)? Then, clarify to the vendor that the scope includes enhancing an already customized solution. If there’s a need to return to OOTB functionality for simplicity, then you have to call that out explicitly.

No telepaths

It is very common for clients to provide vendors with design assets as part of the requirement-gathering process. Clients may elaborate on the design specifics in different ways.

For example, some companies have their UX teams extensively annotate design assets. This is one of the main ways UX requirements are provided. If vendor teams need to use these annotations when they start to write user stories, it is important for the client to state this upfront. 

No one I know is a mind reader. Understanding this fact and acting accordingly will make things easier in the vendor-client relationship.

Further, when starting a project, make sure the vendor’s solution architects have a chance to review the project scope early. If anything is not feasible or advisable, it is much easier to address those concerns as early on as reasonable. No one can read architects’ minds.

Be pragmatic

Another important factor to consider during the onboarding phase is understanding the martech vendor. Are they a big player or niche specialist? 

There are certainly virtues and tradeoffs to both types of vendors. However, do not expect a big player to exercise leniency over contract terms or a niche specialist to provide a large team of specialists. In other words, don’t expect a dog to meow like a cat.

Another angle is how much your company pays the vendor – regardless of their type. If you have a beer budget, don’t expect to get champagne.

Expect the unexpected

Further, there are the inevitable project snags and delays. Do you, as a client, have a good process for tracking inevitable delivery delays and how it will affect downstream teams?

It is far easier to explain QA and user acceptance testing (UAT) processes earlier than later. This would involve explaining team composition, processes and SLAs. Even if defect classification and expectations are in the contract, explain them clearly to the project team. This way, if a stakeholder identifies a major issue close to a deadline, everyone will understand the situation better and avoid unnecessary drama.

Delays are common in projects, so it’s crucial to recognize, track and communicate them with the vendor early on. It’s best to set up these processes before the project begins. This is also a great time to share any project management artifacts with the new vendor. Such artifacts include templates for backlogs, Gantt charts, process diagrams, user story and ticket formats, dashboards and presentation templates. Don’t forget to share the expected meeting types and cadences. 

Worth it

Like any business-related process, even seemingly simple things get complicated quickly. That certainly applies to onboarding new vendors.

This is not a reason to avoid onboarding a new vendor that can offer fresh perspectives and robust capabilities. However, the process is far more likely to go smoothly with some preparation. Martech practitioners are well-equipped to help facilitate such an initiative.