Sharing insights into the world of Restaurant POS
In my last blog entry, I discussed some POS Integration related business issues. Now I would like to discuss the implementation issues associated with POS Integration on various platforms. Doing POS Integration is kind of like my ascent up La Plata peak (14,336) outside of Leadville, Colorado. Before you even begin the true climb, you have an approach hike of several miles, uphill, through a forest; then you take a left and start climbing up a gully to reach the saddle below the summit. Now, the climbing guide we used left me with the impression that the hike up the gully was fairly short and had just a few switchbacks. Yet, THAT’S NOT WHAT IT FELT LIKE TO ME! I distinctly remember that gully as being incredibly grueling, with what seemed like a THOUSAND SWITCHBACKS. When we finally got to the top of the gully and reached the saddle, we still had 1600ft to climb in 1.25miles, according to the guidebook. Ugh! The wind was blasting and all the new snow on top of the boulder field made it quite treacherous. Though eventually, we made it up to the top and was rewarded by the fantastic view.
So is POS Integration really like that? Well, sometimes, YES, but it’s generally not that bad. There have been a few times when I felt like my back was absolutely pinned to the wall – when the POS is crashing and you don’t know why and the POS dealer and POS manufacturer take the approach that since the POS didn’t randomly crash before you connected to it, it must be YOUR FAULT! You don’t want to be in that situation. So let’ talk about what you can do with each POS Manufacturer’s SDKs. Please understand that since I am under NDA (Non-Disclosure Agreement) with a number of these POS companies, I am can only share my opinion as I am unable to divulge the specifics of each POS SDK.
Let’s start with Aloha – I’ll discuss other POS platforms in a future blog entry.
We have worked with every software interface Aloha has created (except the credit card API which was never released to us). I would describe the types of Aloha APIs as being: 1) Order Placement / Cashiering; 2) Event Monitoring; 3) Print Modification; 4) Data Dictionary.
Let’s first discuss the Order Placement. Like all Aloha APIs, the Order Placement API uses Microsoft’s “Common Object Model” or COM (DCOM), so it is easy to link into any Microsoft Visual Studio project. The interface is designed to mimic what a cashier does when placing an order. There are a lot of function calls available via this interface, which is good. The bad news is that all the calls are fairly low level. If your goal is simply to add 1 item to a new check, say “Diet Coke,” you have to make a lot of calls to the API; a minimum of 7 calls to the API (only 2 of which are specific to the item), in the right order, probably need to be made. Items have to be ordered EXACTLY RIGHT. By this I mean Aloha WILL NOT accept an incomplete order for an item or one that is improperly structured. For example, consider the following order: “rib-eye steak medium rare, dinner salad with French dressing, baked potato with bacon and sour cream.” Complex Aloha items can be defined as a tree structure, where choices are configured as children of the parent item. In this case, if dinner salad and baked potato are configured as children, then the order has to be placed via the Aloha API in that same hierarchy; the structure continues down to the next level as well, with the “French Dressing” being a child of the Dinner Salad and the “Bacon and Sour Cream” a child of the Baked Potato. This makes placing orders for items in Aloha quite challenging because both the order of the calls and the structure of the data in those calls must be correct, otherwise, Aloha rejects the entire item. As Aloha allows for an infinite level of children in the item structure (or even the definition of infinite loops in menu items which we have seen very frequently), you really have to have your act together when coding a robust ordering interface for Aloha. If you don’t place the order correctly, Aloha reports an error back to you, effectively telling you a piece is missing; BUT ALOHA DOESN’T TELL YOU WHAT IS MISSING.
You can also pay for orders via this interface, including credit card and non-credit card payment types. If you want to use Aloha to process credit cards, this interface works well. This interface’s weakness is promotions. For years the documents have said that although the promo parts of the interface are “defined,” they are not “implemented.” I have come to discover that some are implemented for certain versions; but Aloha doesn’t share that information, you have to discover it yourself by writing the code and seeing if it works. 😦
The Aloha Event Monitoring interface allows you to create a DLL that links into the Aloha Front of House interface to “listen” to what is going on at each terminal. This isn’t a “keystroke by keystroke” type of event monitor: Aloha has predefined a collection of “events of interest” which roughly correspond to the life of a check and employee events such as “login” and “logout.” Effectively, when one of these events occur, say adding an item to a check, Aloha calls out to your DLL, telling you a few details of what just happened (“Added Item 123 to Check 456”), and gives your DLL full control of the terminal. At this point you can take the appropriate action: query the Aloha data dictionary, write to a file, call another service, start a program, whatever you need to do.
This brings up a commonly asked question: “Can I make a call out to the internet from a terminal?” The answer is NO. For PCI compliance purposes, you’ll find that Aloha terminals are configured to have no Internet access. Typically the Aloha Back of House Server is configured with 2 NICs: one for the LAN (to talk to the terminals), and one for the WAN (connecting the Server to the Internet), thus isolating the terminals from the Internet. In theory, you can configure the terminals to access the Internet; I have done it, but that was way before PCI compliance was a consideration. Try doing that now and you’ll be fighting the Aloha Dealer and Aloha itself, as they want to protect the Restaurateur and themselves from any security breach liability. So if you want to access an Internet enabled service (who doesn’t?) from the Front of House, you will need to route your request through the Back of House server. In practice, you’ll need to take the same approach with every POS you integrate.
Another point to ponder when designing for multiple POS integrations is code reusability across platforms. If you have been following this blog, you have probably realized that the integration points across POS platforms vary widely, so what can programmer’s re-use? For all intents and purposes, the only thing that will be reusable is typically the back-end logic of communicating with the target Internet web service. If your integration requires you to interact with Wait Staff, Cashiers, or get real-time data AND communicate with a web service, you will most likely be building both a Front of House and a Back of House component. On Aloha, it’s usually easier to extract data from the terminal; on Micros, it is often easier to get the data from the Back of House Server. In each case, it depends on what data interests you and how you will use that data. That’s why integrations across multiple POS platforms get so expensive!
Let’s talk about the Aloha Print Modification API. How this works is that you create a DLL that links into Aloha Front of House; each time Aloha is going to print something, the DLL “sees” the document before it is printed and has the option to change it just before Aloha sends it to the printer. When Aloha calls out to your DLL, the DLL receives 2 pieces of information: 1) What type of document is being printed, such as a “Guest Check” or a “Kitchen Chit;” 2) The actual print request. The Print Request is in the form of an XML document consisting of Aloha-defined print requests. The challenge here is that there is no explicit context about WHAT is being printed. For example, if a “Guest Check” is being printed and your program wants to know what guest check number it is, then your program needs to traverse the XML document and find the check number. There is nothing in the XML to say what the check number is; you just have to find it somehow. Suffice to say, this type of programming can be very tricky because although every Aloha check looks the same, they are NOT! The document contains everything that is going to be printed on the check, such as “Diet Pepsi” or “Visa,” not “Item 123” and Tender ID “6.” Like the Event Monitoring Interface, once your DLL is called, you have full control of the terminal to do what you need to do: read the Aloha data dictionary for more information, call another app, read a file, etc. So now that you have the print document in your hands, you can change it as desired to meet your requirements. This is a process of inserting the appropriate XML fragments as defined by Aloha into the print document and then returning control back to Aloha to let it perform your defined print request.
Moving on to the Aloha Data Dictionary . . . This is a rich interface into just about every piece of data in the Aloha system. The Aloha Data Dictionary allows you access in real time (through the Front of House terminals) all the available data available in the aloha system such as Checks, Employees, etc. This is the good news: you can learn almost everything about Aloha through this interface. The bad news: getting to the data is quite tedious. The data is highly structured and for the most part, you have to start at the top of a data tree and work your way down to the desired point to access the data you need. You can only ask for a single piece of information at a time; there is no way to ask for all the attributes of a menu item, guest check, or logged on employee. I am not kidding—it is really tedious to get the data! Often I am asked if we can write something that gives the third-party “EVERYTHING;” I used to answer that question, “Yes, but please send me your first born child as payment!” Now I just answer, “NO, don’t be lazy, tell me specifically what you want and we can figure out how to get for you.” The other problem with accessing data in the data dictionary is that the process is CPU intensive; meaning, it’s slow. If you really need to access a lot of data via the data dictionary, then you run the risk of slowing down or freezing the terminal while your program gets the data it needs. So sometimes it’s better to cache static data from the Data Dictionary at startup to eliminate redundant lookups that just chew up time.
Finally, from an Aloha interface perspective, I need to discuss the Aloha database file system. Instead of using a single large database file to store all of its configuration information, the developers of Aloha elected to put most of this information in Dbase format files (DBFs). You can read these files with Excel and you can read these files programmatically. You can write to these files, but that’s dangerous, because Aloha adds fields to these files from time to time with new versions—so you can end up having to write code that treats the DBFs differently, depending on the version. I am often asked if we can decrypt the transaction log. The answer is “NO;” I have never tried. I think reverse engineering something like a POS is a big waste of time. Aloha does generate DBFs at the end of each business day that records the day’s sale history.
The other point about Aloha you need to understand is that this interface is highly dependent on the Aloha configuration setup for the location. Although all Aloha APIs work the same way for either Aloha Quick Service or Aloha Table Service, for them to work properly, the Aloha Configuration must be properly defined, licensed (the Aloha Connect license purchased from the dealer), and properly running. This is by far the biggest headache with Aloha integrations: getting the configuration to stay up and running. I can say with confidence that 99% of our time spent supporting our Aloha integrations is actually spent on trying to get and keep Aloha itself running, not the integration itself.
So what I have shared about Aloha Integration is really just peeling back the top layer of the onion. If you are going to be successful in integrating with Aloha, you really need to develop a deep understanding of how Aloha works. It’s a time consuming process, and Aloha really doesn’t provide a lot of support to you in the process. Nor is there any community support. The dealers are experts in configuring Aloha for in-store operations, but really have very little input on how to interact with Aloha from an integration perspective. So you are pretty much on your own.
If you are going to climb the Aloha POS integration mountain, just keep trudging up those switchbacks and take on the boulder field one step at a time!
For my next blog post, I’ll discuss Micros Integration.
A couple of years back, my oldest daughter and I were hiking up to the top of Mount Elbert (14,433ft), Colorado’s highest peak, when I was amazed to see a mountain biker coming down the trail! I spoke to him briefly and realized he was just a few years younger than me and that his bike was about the same as mine. I started thinking, I CAN DO THIS! I can bike to the top of Colorado! Fast-forward nine months: after losing a few pounds and getting my bike tuned, I started training at Deer Creek park, just outside of Denver, on a rather gnarly bike trail. I was battling a trail up a ravine when I hit a boulder that stopped me in my tracks; then, since my feet were locked in my clip-less pedals, I starting falling to the right, down into the ravine!
Fortunately for me (and this blog), the Good Lord put a willow bush there to catch me. Twenty minutes later, after extricating myself from the willow and realizing I was still in one piece, I trudged on, only to suffer a similar fate ten minutes later. But this time, instead of a willow bush, my landing zone was a pile of rocks. Instead of a couple of willow scratches, I considered myself lucky to only have a couple of bloody scrapes and a number of bruises. But my day was done, and I realized that making it to the top of a mountain on a mountain bike was going to be VERY HARD. I share this story because to tell you the truth, POS Integration can be quite similar to my “Biking to the Top” experience; you think it isn’t going to be that hard, and then once you try to make it happen, reality sets in! This is particularly true on the BUSINESS side of POS Integration. The technical side can be challenging as well, but believe me, the business side can cause a tremendous amount of hair pulling.
I’ll start out this discussion by delving into Aloha, Micros, and then Positouch. Over the years, that’s whom I have worked with the most due to their dominating position in the market. I’ll also briefly touch on Digital Dining, Dinerware, Aldelo, Posera Maitre’d, and Expient.
Let’s talk about Aloha. Obviously, it is a big gorrila in Restaurant POS. If you are a third party integrator with the next great idea for connecting to restaurants, then you need to integrate with Aloha! Having been a Aloha POS Integration business partner for about a decade, I have received hundreds of calls asking about how to make an integration with Aloha happen. Historically, Aloha has made it very difficult for anybody to integrate with its system. Technically speaking, Aloha has several integration points built in, allowing third party integrators a great deal of personal flexibility, so long as Aloha approves the integrations. In my opinion, corporately, Aloha has a very closed business philosophy making Aloha protective of their customer relationships and having no interest in sharing them with anybody—including third party developers. Aloha wants its vast cash flow generator to be for its stockholders and their dealers. Therefore, it’s almost impossible to create a true “partnership” with Aloha. Third parties such as Gift, Loyalty, Reporting, Ecommerce, and Mobile Payment providers are viewed as competitors to Aloha’s own offerings, discouraging any relationship between companies. Consequently, getting traction with Aloha can be very difficult.
How do you reach a decision-maker at Aloha? The Aloha dealers will typically try to put you in contact with a “Partnerships” person at Aloha. In my opinion, the Partnerships person has a tough job at – they spend almost all their time saying “NO!” to people. Most of the time, when someone contacts Aloha Corporate about third party integration, they just blow you off and continue to blow you off until you either give up or you give them a reason to listen to you. What’s a good reason? Well, the angles I suggest typically revolve proving your business model using some POS other than Aloha! If you can get traction outside of Aloha restaurants, then when you talk with Aloha, you are more likely to look like you have your act together and they might be more inclined to give you the time of day. Another approach is to bring a significant Aloha customer to the table with you, one that’s willing to go to battle for you. I typically suggest a “Big Gorrila” but I don’t think it always has to be that way. It may only need to be a customer with some “influence” in the Aloha world; however, remember that since Aloha is in over 100,000+ restaurants, any one restaurant will typically not be enough to persuade Aloha to listen. In one case I know, the threat of legal action got the necessary cooperation, but who wants to write six figure checks to lawyers each month?
So now that you have gotten Aloha’s attention, what typically can you get out of them? Assuming you are a third party solution provider, you want to connect your product to Aloha. How is that done? Can you have Aloha do the work for you? LOL! I have never heard of Aloha doing something like that. Besides, the issue with Aloha is that they have 7000+ requests for changes to their software. If they do add a feature, it takes at least eighteen months to make it happen! Unlike Micros, Aloha doesn’t offer professional services, so your only option is to purchase an Aloha Software Development Toolkit (SDK) so that you can hire some software developers to link your solution/product package to Aloha’s. This is where the costs come in. For years, IF Aloha is willing to sell it to you, the SDK costs $25K. Besides the SDK, you will need to buy an Aloha system for development. BUT, besides these initial costs, Aloha charges a “per site” license fee called “Aloha Connect.” Aloha Connect is a feature of the Aloha software that enables third party packages to talk with Aloha. Aloha dealers sell this for $800 to $1000 a location, and most Aloha restaurants DO NOT have this feature turned on. So if your business model can’t absorb these costs, you probably need to rethink your business model!
Of course, there are other ways of extracting data out of Aloha without requiring an SDK or Aloha Connect license, but there’s NO WAY to push data INTO Aloha without a connect license. So if you are trying either to push items or payments onto a check, then there’s no way of doing it without Aloha Connect.
Another cost is annual support. Your developers will need this to deal with development and support issues for your integration. It’s important to know that Aloha dealers can provide you with VERY LITTLE support for Aloha Connect integration problems. Most have no experience in this area. If you want dealers to be your installation/technical partners, you will have to train them on all the specifics of your product.
If you do get to the point of an agreement, don’t expect a “partnership” agreement from Aloha, but rather a highly restrictive license agreement that limits your ability to utilize the SDK for purposes other than what you have specified. Aloha controls the relationship; therefore, it will never be a partnership!
Also, don’t be surprised if after six months of talking to Aloha about an agreement you still haven’t seen one. Delay after delay in the Aloha legal department is typical.
Once you have FINALLY obtained the SDK and your Aloha System (congratulations!), you can start development. I have lots of thoughts to share on this, the technical side; that will be in the next blog posting.
Let’s talk about Micros, the other big gorrila in Restaurant POS. If your business model is something that requires POS integration and you are thinking about Aloha, you should be thinking about Micros as well. Micros can be tough to engage, but they are much easier than Aloha. Over the years I have been involved with different efforts where people were able to partner with Micros. It seems that if you have a competent and experienced team and a strategy that properly targets Micros’ clientele, then Micros Corporate may listen to you and actually even help you! However, from a business perspective, Micros is extremely daunting because unlike Aloha, which has one POS product to integrate with, Micros has four platforms, all of which require different integrations!
The Micros 3700/RES 3000 product has been around for a long time in restaurants in large-scale use around the world; but Micros also sells the newer E7 platform in restaurants and I am frequently asked about its integration functions. Micros’ 9700 platform is used in Hospitality applications (Hotels, Cruise Ships, Casinos, etc.). The 9700 platform appears to be technically similar to the 3700 platform, but from a business perspective I encourage you to think of it as separate from the 3700 platform. Finally, there is the 8700 platform, which has recently been replaced with the 9700 platform. Although Micros no longer sells the 8700 system, it’s still a popular Hospitality System. If hotel restaurants are important targets, you may need to develop your solution on both platforms, creating versions of your solution for both the 3700 and 9700 platforms. And, don’t be surprised if you find yourself pondering whether to develop for the 8700 platform to capture one key customer! The E7 platform is problematic from a third party integration perspective considering that the official word from Micros is that there is NOT an SDK available to third party development on that platform, due to technical constraints. To make matters even more complicated, the 3700 platform has FOUR (4) different methods of performing integration, each requiring different integration methods or licenses!
All these different interfacing methods can create a perplexing business / technical problem. In about half the integration requests that come our way, the required functionality is not available in any one interface, which means that two interfaces need to be implemented. And this isn’t always obvious when the project is started; it may take some time and development to understand how the various interactions need to occur and what options are really available. To add to the confusion are the licensing costs and choices. Even if you make the right choice in completing the integration, getting the licensing setup at location can be surprising difficult. That’s because the each integration method has a different licensing technique and it seems that almost every time the dealers are not able to get the licensing right the first time, even when they have been given the proper Micros Licensing part number to order! It seems that somebody either in the dealer office or from corporate will suggest a “better” way of doing licensing, setting up their recommendation, seemingly ignoring the requests of their customers. I see this especially with the 3700 Platform “RES POS” APIs (of which there are two flavors of licensing). Of course, Micros charges roughly $800 to $1000 per site license for each integration as well; so if you are forced to use two, the cost may well be $2000 per store in license fees that somebody has to pay to Micros just to “enable” your interface to work! Beside the site license fees, some of the SDKs will cost you as well – the 3700 “RES POS” SDK seems to run about $15K. And then you’ll need to purchase annual support as well. So making the wrong choices about which integration method to utilize can be quite costly and time consuming.
What most of the startups that I work with have a hard time understanding is that Restaurant POS systems are black boxes, all built differently, and all with different integration points; there will be hazards on almost every road, but even in the best of circumstances you often can’t see them until you get around the next bend. So I say, expect some bumps (or even some landslides) on the road.
When it comes to getting the actual integration work done, Micros does offer Professional Services that can assist you. Also, Micros Dealers are typically far more capable then their Aloha counterparts in developing integrations and add-ons since many dealers can create what are called “SIMs” (I’ll discuss these in a future blog as well).
Technically, you really don’t have to engage Micros Corporate prior to creating your product if you don’t want to. There are third party developers that can perform the integration for you, and they don’t need to get a rubber stamp from Micros Corporate before proceeding.
Now let’s turn to Positouch. My experience with Positouch, from the business side for POS Integration, is that, as a smaller company, Positouch is much easier to work with than either Micros or Aloha. There are fewer layers of organization and Positouch is willing to work with most anybody. That attitude seems to percolate down to their dealers as well. I believe Positouch sees the value of your POS needs and requests. Thus, they will install their software with the necessary SDKs on a PC you provide, to assist you in the future. This proactive policy is really VERY helpful! The question is, can you accomplish what you need to with your integration on their platform? I have to say that the Positouch Integration points are more limiting than Aloha and Micros, but that isn’t to say they don’t get the job done. Like Aloha and Micros, POS Integration with Positouch can get technically challenging, but lots of integrations have been completed. Because so many integrations have been completed, Positouch dealers can be quite helpful in addressing technical issues regarding configuration. However, you will still need your own team of developers to get the work done. Like Aloha and Micros, Positouch does require license fees for the interface licenses, but unlike Aloha/Micros, it seems that many customers already have them.
Now, here is a brief breakdown of some remaining, aforementioned POS technologies:
Digital Dining: Like Aloha, Micros, and Positouch, Digital Dining is another POS where we have seen requests for integration over the years. It’s not obvious that they support third party integration, but they do have interfaces that allow you to extract data from the POS as well as an external Order Placement Interface (which I helped them develop).
Dinerware: Unlike the manufacturers previously discussed, Dinerware encourages third party integration. Just go to their homepage and you’ll see the tab for “Developers” right there. It’s easy to engage with Dinerware and our experience has shown their willingness to work with you to help your team get the information you need so that you can complete your product integration.
Posera Maitre’d: This Canadian POS manufacturer has provides SDKs for third party integration for some time now. Our experience in trying to provide Online Ordering integration has been difficult, as the interfaces always seemed to be in flux and fairly complicated to use.
Adelo: This is another POS manufacturer that makes it known on its website that it has a collection of available SDKs that support a wide variety of integrations.
Xpient: This POS manufacturer also boasts a well-defined SDK that is available to third parties.
Let me conclude this blog entry for now by stating what should be pretty obvious – the business side of POS Integration is a big challenge. Since every POS manufacturer has different philosophies about POS integration and (as we will find out in the future blog posts) different technical approaches to integration, connecting all these solutions together requires a large capital investment. The bigger problem the POS industry needs to focus on surrounds the idea of providing customers with a mechanism that accommodates and encourages independent innovation, thus allowing restaurants and retailers more customization regarding their specific business transaction needs. Though I have some suggestions for how POS technology can improve, that discussion is for another time. . .
For my next blog post, I’ll delve into the technical side of POS integration.