Since the first restaurant Point of Sale went on the market, software integrations have become exponentially more common - and more essential. Amid the dramatic expansion of digital ordering, payment, and service channels and the digitization of restaurant operations front to back, integrations that work without fail are even more critical to a restaurateur’s success. Your third party ordering partners’ solutions must talk to your POS which must talk to your inventory software and your staff scheduling and labor cost tracking solution which must talk with your recruitment and onboarding solution…and so it goes.
The process of evaluating a software can be fraught with missteps. How can you discover whether the software you are considering truly integrates with your current tech stack? And whether it will create problems such as technical debt in the future? Too many technology buyers end up with remorse they could have avoided by asking a few simple questions and documenting their use cases for software vendors.
Ask the right questions to avoid getting your toes trampled.
Often, buyers start with the question ‘Do you integrate with (X software)?’ That’s a great question and shows due diligence. But it doesn’t necessarily get to the heart of the matter, which is whether the software delivers the business value the buyer is looking for.
Ultimately, the software must serve the needs of the business, including ‘playing nicely in the sandbox’ with other software the business uses.
Similar to a ballroom dance, the buyer and seller must actively participate, and each plays a role. But unlike a ballroom dance, there are no standard prescribed steps or moves. The software vendor must ‘feel out’ the buyer to understand their needs. And the buyer must carefully ‘read’ the software vendor to see if there are any gaps or weaknesses that would signal ‘red flag’ concerns.
Who leads in this dance? And when it comes to getting the business what they need, who is responsible for what?
‘Does your software integrate?’ is just the start of a series of questions software buyers should ask. Later in this article, I’ll share several suggested follow-on questions. But first, let’s look at the missteps sellers typically make in this ‘dance.’ I’ll base this in part on an actual conversation I had recently when I was looking into the integration capabilities between a leading POS and a Voice Artificial Intelligence (AI) company. The POS is deployed nationwide at restaurants of all sizes, so it’s not a small startup or an insignificant player in the restaurant POS segment. The company has been around for quite awhile but the product in question isn’t antiquated.
A restaurant group I represented in the conversation wants to use a Voice AI solution to serve guests. And it must integrate with the POS software currently in use. The Voice AI product is fairly new.
I asked the Voice AI representative if they integrate with the POS software. The answer was a quick and resounding, ‘Yes’.
So then I asked, ‘since you integrate, that means you can use the restaurant’s menu to power your AI at my customer’s locations, right?’.
The answer, which I expected, started with, ‘Welllll…’
The Voice AI software rep went on to say that they would set up a lab and work intensely with us for a week to develop a way to train their AI. Three to four months later the system would be live. You read that right: Three. To. Four. Months.
Which led me to wonder…so what is the integration, exactly?
Change happens
My next question was: ‘Say we go live and then a couple months down the road we make a change to our menu. The Voice AI can support that, right?
Rep: ‘Welllll…..You should let us know about those changes in advance, and we’ll work with you and we should be able to accommodate them in a few weeks.’
Hmm. It sounded like they were tap dancing around my answer, rather than trying to dance with me and give me a straight answer.
Me, in my head, again: ‘So what is the integration, exactly...?’
Me, next question: ‘Do you support both English and Spanish languages?'
Rep: ‘Yes, absolutely. It’s on our roadmap and we’ll support Spanish four months from now.’ Four. Months.
It takes two to tango
While software makers and sellers should be transparent, answer honestly, and avoid tap dancing around questions, software buyers need to take an active role in getting the answers - and the solutions to their business problems - that they need.
Besides asking good questions, buyers should also take the important pivotal step to document the business use cases they are trying to solve. Without this, how can a software vendor know exactly what the buyer needs?
Your use case will describe software user actors, description of the function, purpose, and goal, preconditions, postconditions, and main, alternate, and exception flows.
Documenting use cases will dramatically increase the likelihood you’ll get what you need. In addition, if there is another software vendor involved in solving your business challenge, having your use case(s) documented raises important questions and should prompt essential dialogue that will help everyone work together toward your common goal.
The essential questions
The following list of questions should move you several steps toward discovering whether a vendor’s product offers true integrations and will help you achieve your goals.
- Do you integrate with [Software X]?
- In what way(s)?
- Do you offer APIs (Application Programming Interfaces)?
- Are your APIs documented? (After they share them, look through them.)*
- Do you have Software Development Kits? (After they share them, read through them.)*
- How are data integration challenges handled?
- How do you handle updates to data, data structures, or data exchanges between different clients?
- Do you have a sandbox with sample data to access?
- When there is a problem, how is it handled? What means of communication and support can I expect?
- What are your Service Level Agreements for integration issue resolution? What is the average time to resolution?
- Can you please provide me with three actual customer references I can speak with about your software and your support levels?
*A note on technology and documentation: Technology changes constantly, and not everyone uses the same vocabulary. Don’t be intimidated by unfamiliar terms and acronyms. If the vendor throws out a word or abbreviation you don’t recognize, ask what it means. And then ask them to explain how that thing helps you accomplish the business goal(s) you are trying to achieve. If it’s not clear, ask them to use less jargon; you might even go so far as to ask them to diagram their answer for you. When it comes to documentation, you don’t need to be a coder or have a doctorate in Information Technology to grasp, for example, an API’s overview (including purpose and features), explanation of expected data types, data transfer method, and the like.
Finale
You don’t have to get stuck in a contract paying for software that doesn’t serve your needs. Catch tap dancing early. Have clear documented business goals. Evaluate integration resources. Note support holes upfront as an early warning. Hopefully your team is now better equipped to fully evaluate any software product vendor that might be on your purchase consideration ‘dance card’, and soon you’ll be dancing with the stars.