As our companies grow, we can't do everything any more. As our needs become more complex, we end up with data sprawled across a lot of different places and a few steps early in the life of a company saves us a lot of time later down the road. This article looks at how vendors are brought on in large organizations.
Understanding how mature organizations onboard new vendors helps young companies who need to work with larger organizations that have more complex and often regulated processes for engagement in two ways. The first is to understand what, if our endeavor is successful those processes will look like for us some day. The second is to understand what our larger "enterprise" customers will need from us and what challenges they will face.
In this article we'll look at how our needs will evolve in order to help us plan how we'll handle vendors from early on in the life of the company to when we find ourselves in that mature state. We'll start with a playbook.
Why Having a Vendor Management Playbook is Important
Once upon a time, we downloaded software and our relationship with a vendor was over several years until there was an update that was hopefully cool enough to justify buying the new version—or until the old version wouldn’t run on a new operating system. But software developers wanted to release updates faster. In a newer age of software, we moved from buying software to buying access to software. Now, we pay for our software on a monthly or annual schedule.
Another difference—we used to buy software that sat on our machine. Now, we buy access to software that sits on a cloud. Cue the security problems with hastily developed online services and the fact that data stored in that software no longer lives just on our computer but in servers far far away. As any organization grows, it becomes too dangerous to let any old employee fire up new projects and buy software, even if doing so is within already agreed upon budgetary constraints.
We could break an existing process, or there could be compliance issues around a service. Therefore, having a playbook on how to spin up a new service can help do so in a deliberate fashion, where teams aren’t surprised by the introduction of something that might impact them. Many of the aspects of this article involve licensing third party products or services (generally, web apps) for teams to go to market quickly with a new concept. However, these guidelines for developing externally-facing products and services can also be used to inform our playbook on internal initiatives.
This article was originally meant to help keep projects on track for SOC2 compliance process rather than an instruction manual for others. But as we were working on it, we realized that many of the organizations we work with are going through some of the same things with growing teams and thought it might be of use to others.
A Software Vendor Onboarding Checklist
What follows is a software vendor onboarding checklist, split into two parts. The first covers internal considerations, and the second is for initiatives that are external (or customer-facing).
Internal Considerations for Onboarding New Vendors
Are there dedicated teams for procurement, vendor relations, and management? Many organizations have one but not all. If there are people dedicated to each of these responsibilities, it makes the process much easier. If not, then the remaining steps will be key.
Does the vendor need to sign our Non-Disclosure Agreement (NDA)? If so, many organizations have what is known as a Mutual Non-Disclosure Agreement (MNDA). It may be available on an internal wiki, like Confluence. Depending on your policies and tools available for obtaining signatures, you might share it in PDF format or using your organization’s e-signature solution, like Docusign. Some vendors will need to edit the document, as they can’t abide by various terms. In these cases, they may request an editable version, like in Word. It’s good to have both versions available to speed up the process.
Does the vendor have a contract we need to sign? If so, is that submitted using a service desk or is that submitted to an email address for a legal team? Usually this same onboarding address or ticketing system will be the same for both the MNDA and the vendor contracts themselves. Keep in mind that while getting a contract executed is usually not necessary, the process can take weeks. It’s often worth getting this part started as soon as we have made a purchasing decision.
Will the vendor host our data or customer data? This is where things often get pretty specific to different types of businesses. Any organization that builds SaaS solutions or software will likely be well acquainted with filling out Data Processing Agreements (DPAs). These provide clarity on the relationship and how the data provided is handled. These are a must in any organization that handles personally identifiable data.
Does the IT team need to have the vendor fill out a security questionnaire? Again, if the vendor is hosting data, this is usually required. And sometimes it’s required with or without that. Either way, it’s best not to fly under the radar and just get all of these agreements knocked out as soon as possible. Many compliance teams are running a few weeks behind so doing all of these in parallel helps keep the progress flowing.
How will the vendor be paid? Accounting and finance teams are increasingly automating their processes. This might mean that we can more easily get budgets approved, but we still need to engage with the people that will pay the monthly or annual invoices to vendors—usually someone in the accounts payable department—even if the purchase is small enough to be put on a team member’s company credit card.
Do we need to integrate with a federated login? This is what enables single sign-on and just-in-time provisioning of accounts. The important thing an IT team is usually looking for here is the ability to have the disable account and password change actions (actions they take from a centralized repository of accounts) be applied to all the web apps and servers in use in the organization. If every team has a solution or three that they’re using, we can all sympathize with how much work it would be to provision or de-provision accounts without this type of centralized functionality. At the very least, the IT team needs a login in case we get hit by a bus.
Will the data be integrated with other systems? This is where things get fun. If the tool will bring data in or the data placed in the tool will be used by other systems, then planning for that data flow is next. This is an area with a lot of potential to deliver value to all involved. By integrating data across systems, teams can gain better visibility in, understanding of, and control over task management, ERP, data visualization, analytics, and any number of other valuable areas. In some organizations, getting data copied into a data warehouse will actually be a requirement.
Does the rest of the organization need to be informed? If someone gets a call from a customer out of the blue, how might they find information about how the organization is working with a given vendor? A clear and comprehensive page explaining what a vendor is doing on behalf of the organization can go a long way toward helping others provide an awesome service experience to both internal and external stakeholders.
External Considerations for Onboarding New Vendors
OK, we have the internal considerations out of the way, which are common to just about any new vendor relationship. Now, there’s some fun stuff to think about for external-facing solutions. These are generally more of a concern for situations where the new vendor provides a solution that will be experienced in some direct way by the people our organization serves. If it’s a tool that doesn’t integrate with our products or that users will never see, these considerations are less important. For those external-facing solutions, consider the following:
Will this be a standalone product or an enhancement that can be sold? If sold (e.g. a white-labeled service), then a SKU is usually required. No matter how big an organization is, there’s usually just one or a handful of people that manage those. Most of the projects teams take on aren’t for an entirely new product the organization will take to market, but it happens.
Will the product be resold by third parties? Any new SKU is likely sync’d every month or two with distributors or resellers. This is usually handled by the team that creates SKUs but any teams that deal with resellers should be prepared when possible, unless that activity is handled by sales or marketing enablement teams.
Is there an integration where the product needs to be put into another product? This might be a tracking code or a single pixel or even something much, much larger. If that’s the case, then product management probably has a deep pipeline of needs and the new tool being used needs to get prioritized against those.
If the product will receive any changes, is there a documentation or technical communications team that needs to be updated so they can put things into their backlog? This should be addressed as early as possible, especially when internationalization is involved, as that has a tendency to take a good amount of time.
Do training materials need to be updated or produced? Training is different from technical communication. Training often involves in-person or virtual classes. It could involve production of video content, such as would be hosted on a YouTube channel. The education arm of any organization will need to be made aware of product changes so they can determine if they need to make any corresponding changes to training materials.
Will the professional services team be impacted? To ensure they’re able to continue providing great service, it’s important to make sure these team members know what’s coming and how it will change or enhance their service options and processes. This is especially important if a valuable process will be disrupted.
Will the support team receive any calls as a result of a new vendor? Even if it’s a minor change to the product, make sure support staff have information available about that change. There are a variety of ways to support the support team—enablement training, providing test accounts, information on working with the vendor, etc. It is also often helpful to have a specialist become the subject matter expert, curating wiki or internal support enablement pages when possible.
Will international teams be impacted? If so, then take a pass back through this checklist with those teams in mind. As our organizations become more and more geographically distributed, make sure to cover your bases in those various regions.
Will the solution be accessible through a different web address? If so, this usually involves getting a change to the DNS for the organization (e.g. handrailux.pretendco.com). Those should take a maximum of 72 hours to replicate through the interwebs, but internal change control processes could take months to complete the same change.
Will there be cookies? GDPR requirements are usually handled during the information security review, but if the site uses cookies for sessions or even retargeting, then there will likely need to be some kind of a code snippet with the organization’s policy on processing those.
Will third party developers interact with the system? This is where enabling a developer relations team comes into play. Not a requirement and honestly kinda rare but worth thinking about (for example, if you turn this post into a checklist).
Can sales or marketing teams use the tool to better compete in the market? If so, then there’s probably a sales enablement team we should talk this through with. They’ll know best what should be socialized and how. Make sure to establish whether a press release or other form of communication will be necessary. This may include:
A one-sheet for account teams to hand out or email to potential or existing customers
Blog post on the company blog
Post on any user forums
Social media mentions (Facebook, Twitter, Instagram, etc)
Pay-per-click AdWord buying or retargeting
Sponsorship at conferences
Webinars
Email campaigns
Meetings with sales teams to demo the new features or products
Wow, this is a lot of stuff, right?!?! As a startup we just need to know about what's required for many organizations and build our early processes in a way that they aren't overly taxing for us, but do set a standard that lets us work with the types of customers we want to work with.
Along the way, we might find that our target customers step on toes to get our initiatives put on the priority list of other teams. We all have our priorities and we can all empathize with how much goes into big ideas. Or even little ones. So, be patient. Buy people chocolates. And if someone gets annoyed that you stepped into their lane, apologize and pledge to do better next time.