HubSpot Integration Scope Template

Well begun, half done – anonymous. How true that quote is when we see our day-to-day tasks in the same manner. If we proceed with proper planning right from the beginning, the further steps become easy to manage. In an IT agency world, every project needs to begin with the planning stage, which is all about finding the answers to the right questions. Each right answer takes us closer to a better understanding of the project and brings us and the client on the same page. Once that synergy is achieved, next comes the action stage.

Being a HubSpot Partner, we do get regular HubSpot Integration projects. HubSpot does offer default integration options, which meet the basic requirements for sure. For a company that deals with complex data and wants things done their way, custom integration is the path to choose. And, in that path, we and the clients both get a volley of questions thrown at to get to know what exactly the client’s vision is. We saw a pattern in the requests we used to get and the questions we used to ask our clients. So, we studied that pattern and built a template of questions that helped us in a better and quicker understanding of the projects and made the process a lot easy for the clients as well. Now, we decided to share it with the world as we have tested the template with many clients and it came out as a success.

Our communication with clients became concise and precise.

Our clients were able to share their requirements in a more precise manner – basically in the language that a developer would understand. That’s the whole point of reducing the gap in communication.

We reduced our deal closing duration which helped us get more business in less time.

Computan’s HubSpot Integration Template

This is a sample document we made between Computan and a Fictitious Donation Management System – CompuDonate. You can replace CompuDonate’s data with your integration requirements.

This document mentions the right fields and what you need to fill in those fields. Both parties come on the same page for discussion even before the first meeting. They can have the discussion keeping this document as a foundation. Some clients already have such documents to fill, while some don’t.

Apps to integrate with - The applications field is here to mention all the applications the clients want their HubSpot account integrated with.

Hosting - Computan developers or clients specify how they want the integration built and where it is to be hosted. Some clients won’t have a preference. Others will. Some might have their own EC2 instance at AWS they want to use, others might say to use HubSpot’s Serverless Functions feature to code the middleware etc.

In this case, let’s say this integration will be built using a custom middleware and hosted on Computan’s Digital Ocean account.

Versions of Codes - Computan developers or clients specify where code will be deployed and how different versions of code will be handled. Some clients won’t have a preference. Others will. Some might have a Github repo they want code pushed to, others might be using Bitbucket (Let’s assume here we are using Bitbucket).

End goals of integration - Computan developers or clients need to summarize what exactly they want the integration to do. Ideally, this part of the document explains in a paragraph or two what the situation is now, and how they want the situation to be once the integration is complete. We should be able to tell from here if the integration will be bi-directional (data going from HubSpot to the other system and vice versa) or one-directional (data only going from HubSpot to the other system or data only coming from HubSpot to the other system).

For example, The Money In My Pocket Fund is a deeply underfunded non-profit based in Canada. They need to integrate HubSpot and CompuDonate to help their fundraising arm secure its donation revenue.

Contact, company, and deal data will flow in two ways – from CompuDonate and HubSpot.

Objects - Here we outline any custom or standard objects or properties in the various systems in play.

Data Flows - Here we describe the information of the different places from where one system needs to be passed or received. For example, if deals need to be created in HubSpot after a certain action happens in another system. We also specify how often the data needs to be fetched (pulled) or sent (push)…this is called the Sync Type.

Mapping Document - In this section, we need to outline what specific fields correspond to one another in each system. This mapping document helps us understand what data needs to go where.

So since in our example Donation and Entrants data needs to be integrated we need mapping for both areas.

Historical Data - Sometimes clients want historical or current data to be synched and others prefer to start from launch onward. Kind of like when you are setting up email on the new device you can choose to sync email from 1 month ago, 9 months ago, the beginning of history, or not at all. The same holds true for integrations.

We need to discuss with clients what the best option for them is.

In this case let’s say historical data sync of contact, companies, and deals from CompuDonate to HubSpot needs to be considered as part of the project scope.

System Access - We should have system access or documentation on the system integrating with HubSpot to properly scope out what options are available and how, if applicable the APIs, are being handled.

In this section, we should have access instructions and URLs to API documentation if applicable. Sometimes JSON files can be linked to or downloaded here too.