Setting up an integrated tech stack is challenging. You need to establish which solutions you want to enable, and then you need to find a way for everything to work together. And it can take time to get everything right.
But getting the integration right is so important. It means no double work for your recruiters, and it ensures that your candidates and clients are receiving all the information that’s important to them, ideally inside of one system and interface. Chances are you’re bringing a new solution in to make one or all of their lives easier, so you need to make sure it actually does.
For the purposes of this article, we’ll assume you want to integrate a new mobile solution into your existing ATS because that is what we have experience building. But these learnings can apply to integrations beyond that.
We’ll also assume you want to build a full two-way, real-time integration between these two systems. Because, well, why settle for anything less?
What to consider when choosing tech partners
If you are looking to integrate a new tool, one of the first roadblocks you may come across is your current system not offering an easy way to do that. If you are already working with an ATS that you love but are simply looking to enhance certain workflows, then the onus of the integration is likely going to rest on whatever new solution you are bringing in.
Open up lines of communication between providers
Ask your ATS account rep to connect you with someone on their technical team. Ideally they’ll offer a time when technical representatives from both companies can get together and discuss the integration immediately so there’s an open dialogue about intentions and a path to how to make it happen. It’s critical to open up these lines of communication as soon as possible.
Keep an eye out for open APIs
If you are reevaluating your entire tech stack, or starting out and building something from the ground up, building an integrated ecosystem will be easier if you work with solutions with open APIs (this basically just means that the two software solutions can speak to each other easily). This will allow development teams to work more independently from each other and speed up the process by eliminating the need for constant communication.
How to set everyone up for success
Provide access to your systems right away
It’s not enough to simply learn what your employees goes through in a day to understand how your systems need to integrate. If someone is building an integration for you they need to get hands on with your other system(s). If you are able, provide access to your ATS right away and offer to walk your customer success rep or solutions engineer through your actions. Ask your ATS about the possibility of setting up a separate sandbox environment.
Walk through your workflows in depth
Anyone providing you with a tech solution should already have a good day to day understanding of your work and systems. But building an integration requires an even deeper knowledge.
For this, they’ll need to understand not just what you do in a day, but why you do it. It can be pretty simple to understand that a client’s address field or employee’s communication record need to be brought back and forth between systems. But what about more complicated things like employee statuses.
Consider questions like this:
- When, and why, does a candidate status change from consideration to hired?
- How do workflows change for certain job statuses
- How are recruiter commissions calculated
Knowing the answers to these questions early on will ensure a clearer path to fitting everything together.
Ensure company wide consistency
Learning workflows also means learning intended versus actual usage of the systems you have in place. Your team might use the system in a different way than leadership originally intended, and recruiters in different branches might use the system differently than each other. The company who built the software might even have a different idea of its intended uses and therefore may advise certain things that might not be your reality. Make sure everyone is aligned on how the system is to be used, place they are consistent across the company.
Clean up your data
As with any system we use, it’s easy for an ATS to house incorrect, out-of-date or irrelevant data (like having thousands of unread emails in your inbox). Make sure you do some digging to figure out what this data might be, and be open to a type of system “spring cleaning” when you begin your integration. There may even be certain things the integration can actually help you clean up. For example, in the past we’ve offered the use of Google’s Places API to correct address data coming in from integrated systems. Rest assured that limiting the passage of bad data between systems will make everyone’s lives easier.
How to keep everyone on track
Define and document your scope
Make sure you have detailed documentation that defines the scope of your integration. This will usually include at least a data mapping chart which identifies what pieces of information you need to pass back and forth between systems. It should also include a list of specifically what statuses or classification of information you want flowing between systems.
This will make it easy for the development team building the integration to translate your ideas into actionable requests. These documents can then be used to verify completion of the integration when finished and give you something to test against. Keep in mind things may be modified along the way, but start out with as defined a scope as possible.
Make sure you know what success looks like
While you are documenting your scope, also make sure you are communicating the results you wish to see. The team you are working with should be obsessed with helping you reach your three month, six month, one year goals using their system, and having a good idea of this going into the integration might help them make suggestions for how it will work best. Are you hoping to impact your communication process? Are you hoping to lower your time to fill? Establishing goals will help the team identify which system is better able to deliver on which metrics and build accordingly.
Get in there and try to mess things up
When all is said and done, you’re going to need to test the results. Nothing is going to be perfect right away, but it’s not about that. It’s about how the team you are working with responds to the issues you surface. Give yourself a few weeks to use the system(s) internally before putting your roll out plan into action so you can limit the amount of friction when the system is finally put in use.
Then, take those scope documents you put together and get to testing.