The Technical Side of Micros Integration

I try to climb at least one 14,000ft peak in Colorado each year.    I once met a guy who told me he thought climbing 14ers was boring (he had done several).   His complaint was that every climb was about the same: you get above the tree line, climb over a bunch of boulders, and then you sit at the top of a mountain and see pretty much the same type of view each time: a bunch of other mountain tops.   Well, I suppose what the guy said is technically true, but believe me, does he ever miss the point of climbing a mountain, especially one of the highest points in the U.S. where spectacular views abound!  And the journey up and down is never the same no matter what mountain you are climbing.

On this post I want to focus on the technical aspects of Micros POS Integration. For today I will focus on the Micros 3700 platform but also make some points about the 9700, Simphony 1, and Simphony 2 platforms.

It’s important to understand that Micros (now Oracle), offers at least 5 different POS systems for Restaurant and Hospitality (Micros 3700, Micros 9700, Simphony I, Simphony II, and E7). And yes, Micros 8700 systems are still in the field as well!  Each of these has their own APIs, which means that if you want to develop solutions to support all of Micros / Oracle, you are looking at creating at least 5 different integrations!

Micros 3700

In my opinion, the Micros 3700 system is bloated as it suffers from a lot of legacy design features that make setup a really ponderous task.   For example, I recently tried to count all the configuration options available in the Micros POS Configurator.   I came up with approximately 4600!   Although the POS Configurator has an integrated help system, getting the configuration right so that your integration will function properly can be a big challenge.    So purchasing support from Micros can really make sense.    It’s not cheap, but it can save you a lot of time and frustration.

The Micros 3700 Platform has 3 different APIs available for third-party integrators, as well as a large, accessible relational database.   These are SIM, Res POS API, and Stored Value Card.  I’ll discuss the Micros database, also.

SIM Modules

SIM stands for “System Interface Module” and is a common way of creating a Micros Interface.  SIMs are written in ISL (Interface Script Language), a Micros specific programming language.   SIMs allow you to create custom interactions with Micros users on the FOH terminals.   SIMs work by inserting keystrokes into the POS as if a user was doing it.  SIMs are also designed to process events that happen on the terminal such as starting a check, adding an item to check, adding a payment, etc.  They provide a means to interact with another program running on the Back of House server.    You can extract data off the current check and insert data onto a check, plus you can send requests to printers.    You can really do a lot of things with SIMs, but you want to avoid developing SIMs for a number of reasons.  First, on the business side, the Micros customer will need to have a SIM license from Micros activated, which is another $800 to $1000 per location that restaurateurs will have to spend to use the product.    Second, SIMs are hard to write.  There are really no development environment tools to write a SIM and the only way that you have to debug the code is to run it on a live terminal; additionally, the programming resources in the ISL language are quite primitive compared to other modern languages.  You won’t be able to reuse anything you to create in a SIM with any other POS platform.   In my opinion, the main documentation about programming a SIM is very difficult to use (however quite extensive).   SIMs error-handling mechanisms are intended to tell the terminal user what went wrong – there isn’t a way to get an error back to your program – all you know is that the process stopped working.   SIM modules do provide you a way to customize printing on Micros, and can be a good mechanism for capturing real time data from terminals.

RES POS API

The RES POS API allows you to add and update checks, including making payments.   You can also query for checks and send print jobs to the printer.  This API is a COM interface and you can easily manipulate it using Microsoft Visual Studio (.NET). The Micros API has just a few calls; each call supports a large number of parameters, which can be either good or bad, depending on your point of view.   It’s typically bad while trying to get the interface working, as gaining the knowledge to properly build all the structures to properly place an order takes some time.   However, Micros does provide a method in the API to test different data pieces in the order, which is a definite help.  A nice feature of the  Micros API is that it will accept an “incomplete” item order.   In other words, while an order for a dinner salad may require a salad dressing selection, the Micros API will typically accept the order without specifying the required modifier.    This definitely makes it easier to get a working interface in place since you can always enrich it later.     The Micros order placement API does not have specific areas where you enter in customer data or “non item” data such as an order ready time or delivery address.    Micros does provide a place to enter in free form text onto the check so that this information is printed (although I find forcing Micros to print this information is sometimes challenging because the configuration has to be exactly right).  You can use the Micros API to process credit cards through the POS.

There are 2 ways to use the interface: either locally, on the Micros Server via COM or via a web service interface (intended for remote use, but can be used locally as well). It’s extremely important to select which way you are going to implement the interface up front because each requires a different Micros license.   If you use the web service interface, then in theory you don’t have to have any custom code running locally on the Micros Server.    However, as the API doesn’t give you any access to the Micros Menu you may have no choice but to run code locally if reading menu data is important to you.

When you purchase this API, Micros does provide some sample code to show you how to use these interfaces.

You can use both Micros SIM and the RES POS API together at the same time, but you will need both a SIM license and an RES POS API license.    You definitely want to use the RES POS API for adding items to checks and processing payments (you can do this with SIM, but it can be really problematic due to the lack of error handling).

The Micros RES POS API seems to be fairly stable when it comes to ongoing operations.     The Micros API is either working or not working; restarting the machine is usually sufficient to recover if an issue occurred.

Stored Value Card API

If all you are looking to do with Micros is provide a payment or loyalty integration, then the Stored Value Card API may be the right choice for you.   This API works with 3700 (and I think some other platforms as well).   The API provides functionality so that you can implement a collection of services associated to perform Redemptions, Refunds, Balance Inquiries and Transfers, and Coupon functionality.  The setup of the Micros Store Value Interface is straightforward, but entails quite a few steps.  The SVC interface of course requires a separate API license from Micros then the RES POS and SIM licenses.

Sybase Database

The Micros Database can be a real challenge to understand.   Micros uses the Sybase Database System for the 3700 platform, so it’s straightforward to access.  However, a typical Micros Database has 950+ tables, which can make it very daunting to even figure where to start looking for data of interest.  I think the database is horrendously complicated.    While I like to think I finally have a decent understanding of the menu data structures in Micros, honestly, I always have to go back to my notes and review my code each time to get it straight and remember all the different table names.    As a rule, I never add new tables to a POS system database; I always build something exterior to it when needed.   I have learned that while adding something to the system database might seem the natural thing to do from a developer perspective, the reality is that when you do, you open yourself up to all kinds of support issues whenever the POS dealer or manufacturer get involved.   They almost always fix the issue and leave third-party applications left to fend for themselves (i.e.: wiping out what you have setup in the DB).

Micros 9700 Platform

The Micros 9700 system is equipped with 2 Web Service APIs, one for extracting configuration information about the POS so you can have enough information to place an order and the other for actual placement of the orders.   The Configuration Web Service certainly provides a rich level of Menu Information.

Simphony I / Simphony II Platforms

The Simphony I and Simphony II platforms are very similar in architecture.  Both are cloud based POS platforms; what this means is that the POS applications  run locally (not as a web app) on Micros workstations, but the back end management and reporting tools are hosted in the cloud.

What this means from an integration perspective is that in reality you may not be able to directly access the Database of these POS Systems (typically Microsoft SQL server but can also be Oracle) without extensive discussions with the customer.   More typically, for each of these systems, to get data out, you will need to rely on the customer providing you with custom reports generated thru the My Micros web portal.  These reports can be configured to run automatically an then emailed to you.   You will need to create a solution to parse the data from these reports.

What makes the Simphony platforms challenging from a POS Integration perspective is that the APIs for the two platforms have significant differences.  The Simphony I API is much more robust then the Simphony II API.    With Simphony I’s API, the facilities are there so you can get detailed order and menu information, place order (create new checks and add to existing checks), and make payments, allowing you to create a variety of robust solutions without needing to get direct database access.    The same cannot be said of the Simphony II API; for some reason, critical functionality such as obtaining line item detail via the API is lacking.    This means that for many applications built for Simphony II, realtime database access will be required, which may be challenging to obtain given PCI security concerns.

Summary

Depending on what Micros platform you are targeting, there are a number of integration points to consider.   Micros does provide substantial documentation for all these interfaces; you need to study, carefully, the limitations of each interface before you start your project.   It’s critical for you to understand how you want your interface to work in conjunction with the POS, recognizing where you have flexibility in your business model so you can compromise if needed to circumvent limitations placed on you by the Micros POS.

For my next blog entry, I’ll focus on technical integration of the Positouch platform.

The Technical Side of Aloha POS Integration

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.

The Business Side of POS 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.

The Best POS?

A few days ago, my wife and I took a drive on the “Peak to Peak” highway, which runs along the Rocky Mountains outside of Denver.  One of my favorite stops along this route is the Sundance Café just outside of Nederland.  While the food is certainly not spectacular, the views certainly are!  I love to take out-of-state guests here so we can sit on the patio, sip some beers, and watch the sun set over the 13,000ft summits of the Indian Peaks Range on clear, Colorado days.  On this occasion, after imbibing Twisted Pines’ Amber Ale (my wife had the Twisted Pine Cream Stout which she loves), we got our bill.  A handwritten bill!  Being a POS Integration Guy, I always scan the check to see which POS is used.  So when I see a handwritten check, I’m thinking thoughts like: Why don’t you have a POS?  Don’t you realize what these systems can do for you; such as track labor, inventory, and of course, your sales?!?  Then I start thinking about the question I am so frequently asked:

WHAT IS THE BEST POS?

Restaurants of all sizes have asked me that, as well as many third party integrators.  I am flattered people want my opinion; I suppose they think that due to my integration experience with multiple POS platforms, I have some “inside” knowledge and strong, personal opinions regarding currently available POS systems.  And, while I certainly do possess deep knowledge and I certainly do have strong personal opinions about various POS platforms (which will all be honestly revealed and shared on this blog), it is difficult to crown any one of the current POS systems as “the best” considering the extreme variability between each platform and every restaurant’s unique needs.  Therefore, since the “perfect” POS model does not yet exist, the POS selection process becomes exceedingly important as each restaurant must select a POS platform best suited to their needs.

When selecting a POS, it’s mostly about the restaurant business’s requirements; but, it’s also about relationships (between you and your POS dealer/manufacturer) and your appetite for managing technology.   Let’s talk about the requirements’ side first.

When it comes to business requirements, the restaurateur needs to think deeply about how they want to run their business and how technology can best benefit their business.   A memorable restaurant blends together an intriguing mix of food, entertainment, and an atmosphere that achieves a very specific vision and ambiance for the patron to enjoy; technology can aid or detract from many aspects of the total patron experience.  Some questions are very basic, such as: “What is the basic format of the dining experience?” and “Will the menu be essentially static or frequently changing?”  Other, more developed questions are: “Is the menu conducive to takeout and delivery? If so, will these options be made available to the patron and how?”  Updated technology and POS systems can also answer questions regarding labor control and kitchen interaction with the Front of House staff.

Regarding the question of restaurant POS “format,” I use some specific terms: “Post-Ring,” “Pre-Ring,” and “Multi-Round.”

A “Post-Ring” format is one where the patron’s food order is made prior to the order being entered into the POS system.  This is typically the simplest POS system environment; no kitchen display or printers are needed, and there is only one interaction (typically very simple) with the patron and the POS.  In this environment, minimal order details are put into the POS; it’s common to enter in only the item itself and any extra cost choices (Turkey Sandwich, add Bacon) and to process the payment.  In the “Post-Ring” environment, POS requirements typically revolve around making the transaction as simple and quick as possible with the patron, making this format unsuitable for detailed inventory or sales tracking.  The bottom line is that if you like having lots of different metrics available from the POS, a “Post-Ring” approach may not be your best choice.  However, both Subway and Chipotle utilize Post-Ring solutions, so this type of POS should not be considered a limiting factor in a business’s potential growth.  Also, since a “Post-Ring” system often consists of a single POS station with attached receipt printer and cash drawer, it is usually the cheapest way to get a POS up and running and it’s the easiest format to program.

A “Pre-Ring” format is where the patron’s order is placed into the POS prior to the food being prepared.  In these scenarios, the patron is typically standing at the front of a line talking to an order taker (cashier) at the ordering counter; the cashier is entering the order into the POS as the customer is verbally placing the order one item at a time.  In a “Pre-Ring” environment, the order taking process is usually highly detailed, with all order detail being captured by the order taker into the POS.  The order may be displayed on a patron-facing display, assuring the patron their order is correct.  The order is sent to the kitchen via kitchen printers or video systems for preparation, typically once the customer has identified how the food is to be packaged (Order Mode: Dine-In, To-Go, etc.); but sometimes, the order is sent to the kitchen as it is being ordered, expediting preparation. The patron pays for the order immediately after selecting the Order Mode and prior to the patron typically receiving any part of the order. The POS terminal is equipped with a cash drawer and a receipt printer; as previously mentioned, the system may well include a wide variety of kitchen video/printing solutions.  “Pre-Ring” systems are great from a metrics viewpoint; with this model you can marry sales metrics to kitchen/labor performance statistics providing a comprehensive picture of the operation’s performance.  A typical “Pre-Ring” solution should allow the restaurateur to highly customize the process flow on the POS terminal to meet specific needs.   With “Post-Ring” environments, there’s a greater richness in interaction variety regarding the patron, including Line Buster applications, Drive-Thru, Self Service Kiosk, Online Ordering, Order Status Boards,  and even Paging Systems.  From a cost perspective, expect a “Pre-Ring” solution to be more expensive then a Post-Ring format, but more rich in its functionality.

The “Multi-Round” format is designed for classic “Table Service” environments where the patron is seated at a table (or the bar), and a waiter/waitress take a series of orders from each party throughout the dining experience.  POS Terminals are typically placed throughout the facility.  In this format, each POS terminal may be used by several wait staff at one time; one wait staff logs in, adds an item or two to the patron’s order, then logs off; the POS is responsible for “routing” the order details to different stations at the kitchen or bar.   Like the “Pre-Ring” model, “Multi-Round” POS system are typically integrated with Kitchen Video/Printing solutions that are placed at various prep stations throughout the kitchen.  Unlike “Pre-Ring” and “Post-Ring” formats, the “Multi-Round” POS format helps the wait staff manage multiple orders for patrons sitting at tables in different states of the dining process.  In the “Pre-Ring”/”Post-Ring” format, the life of the check/transaction on the POS is measured in seconds or sometimes a few minutes, and typically only one check is being actively managed on the POS terminal at a time; in the “Multi-Round” format, the check/transaction is “alive on the POS” for as long as the patron is sitting at the table, perhaps even longer, and each wait staff member may be managing 4 to 6 tables at a time.  From a metrics viewpoint, a “Multi-Round” format provides a comprehensive set of data that tracks the entire dining experience.  Similar to “Pre-Ring,” numerous patron interactions abound, including reservation, wait list, online ordering, delivery systems, self service kiosk, as well as shared wait staff/patron ordering solutions residing on kiosks and of course, mobile payment solutions.  The Cost of a “Multi-Round” POS should be roughly comparable to the “Pre-Ring” POS, at least on a per terminal basis, and kitchen system costs should be similar as well.

Now, let’s switch gears and talk about “relationships” and POS choice.  By “relationships,” I mean to discuss how the restaurateur hopes to interact with their POS dealer over the long term.  When it comes to POS management, are you a DIY person or a delegator? Do you want to be able to manage significant menu changes on your own or do you want the dealer to do it?  This is an area you have to analyze carefully, as not all POS systems are alike in this area.  My experience is that some of the newer, market POS solutions are much more DIY oriented.  And, even though they are typically unable to offer as rich a feature set as the more established POS providers, they can save you from having to deal with INCREDIBLY COMPLICATED configurations that require you to rely on the dealer to make any changes.

I like to think I know both Aloha and Micros pretty well, but I sometimes wonder how I can waste so much time trying to locate a stupid switch that is necessary to turn on/off a feature!  However, if the POS dealer is really service and customer service focused, then does that matter?  Some established POS manufacturers compliment their solutions with a dealer network that really has their act together whereas with others, it’s really “hit and miss.”  The question is, do you want a dealer that’s only in it for the “transaction,” or would you like a relationship with a dealer that will be there for all your future needs?   The cost of the former will most likely be less than the latter, but the latter can be agonizingly expensive over the long term as you may get “locked in” to the only dealer in your market.

Another question: do you want to make calls to only one phone number for all your technology issues, or are you committed to using the “Best of Breed” solutions?    We all like the “one call does it all approach,” but what if your online ordering needs or your patron interaction systems are unique and extremely important to your brand?   If you need “Best of Breed,” then POS Integration Capability becomes an important question for you to consider prior to buying a POS.   That’s the topic for my next blog entry.

Sharing what I know…

It has been over a decade since I started Lone Tree Technology.  In that time, I have developed a deep knowledge and understanding of just about every issue you can think of that is related to Point of Sale Systems Integration in the restaurant industry.  I get calls every week from people with ideas for products to integrate with a POS.  I spend a lot of time educating these individuals on the “ins” and “outs” of creating an integrated product that truly works with their POS system.  As a result of this demand, I decided to start a blog, sharing what I know with the hope of answering any and all POS integration questions.  By sharing my knowledge, I wish to empower entrepreneurs in their quest to become more effective in bringing their creative ideas to fruition within the restaurant industry; additionally, I would like to help foster a creative community of developers, all armed with the information and tools necessary to improve POS.  I have many topics planned to discuss over the next several months.   Look for a new post on the 2^nd and 4^th Tuesday of every month.  You may wonder what I hope to gain from this: my goal is to create a place for active dialog within restaurant and POS industries where issues regarding POS and POS integration can be brought to light and discussed.  I personally feel that POS manufacturers are not adequately addressing specific POS issues adversely affecting the restaurant industry; thus, through this blog I hope to illuminate better, alternative solutions.  I also encourage every reader to participate in the discussion, adding to blog’s quality and content.