Turns out SMBs care about tech. Doesn't have to be fancy, just has to make their life easier. New computers top the list.
Master the art of local commerce
Tips, tutorials and data to help you make the most of Ordrx’s platform
Hospitality tech has been a laggard for many years. Complex merchant ownership structures; legacy property management solutions; notoriously long sales cycles and small budgets; minimal coordination between properties, business units and corporate… A mess. Marriott has over 20 mobile apps, some with no reviews and others with just 3 stars.
Meta search like TripAdvisor already control much of discovery; GDS’ control a big chunk of the booking market. Customers are perfectly happy getting their info and booking their rooms through intermediaries. Hotels, though, are paying a price. When you don't satisfy consumer need someone else will.
The next frontier is on-premise experiences. This is the world in which operations like Order Inn have provided outsourced room service, and the local pizza shop buys key cards with their phone number on it. Companies that write code laugh, but those solutions have stood the test of time.
Analog industry after analog industry has fallen to technology. The hospitality world is falling to technology. Today 90% of U.S. adults have a smartphone. If my hotel won't give me services in the way I want them, I will stay elsewhere or use an alternate service provider. Check out Alice App and Travelnuts.
Hotels, when all you do is provide a bed, will that feel like a missed opportunity? Will you pay others to provide the services you once did with less cost and more control? Change is always coming.
We are super psyched and proud of Ordr.in interns and developer evangelists, Eric Song and Sam Agnew demo’ing at NYTM tonight. Check out HungryBot on the Ordr.in Github repo. We’d love to see the hubot community check it out, get fed and have fun. Hipchat? Slack? We're talking to you!
This is what it looks like ordering pizza live from the stage at NYTM.
The awesome cartoon up top is by artist Andy McNally. It perfectly captures the moment when hunger overtakes you and everything becomes food. His robot is even called Hungry Bot! Mmmwwaaaarrrr!
It was fun for our CEO David Bloom to join host Paul Barron and MellowMushroom's VP of Marketing Annica Kreider to discuss the future of mobile for restaurants. The video clocks in under 15mins and is a light way to learn about the here and now, plus the imminent future. Check it out and let us know what you think! Click on the image to watch.
The great joy of a platform business is seeing what gets built on it. What cool, unique, innovative, hysterical, powerful applications are brought to life. Just a small sample is on our app gallery. We especially love the explorers who go off the beaten track.
We've been interested in the distinctly different UI presented by Windows 8 and how that affects the food ordering experience. Recently we worked with a restaurant chain and an agency to explore just this. What's the best UI? Who is the customer for a desktop food ordering app - is it a corporate customer? Is it hungry folks? As far as we know, there aren't *any* desktop order apps for any OS so it's a bit of an experiment!
A few weeks ago we launched v1.0 in the Windows app store. So far the results have been good. Several hundred installs and a small number of reviews, though all five stars (humble brag J). We are collecting feedback and will launch v1.1 and with it we will open source the code. In the meantime we would love the Microsoft community to install the app, order food and send us your thoughts to email@example.com.
Alright lets cut to the chase and go through the flow of placing a food order. I will try to be framework/language agnostic and just talk from a high level perspective. There are a few steps you need to follow in order to go through placing an order. The exact order (pun intended) of these steps is not set in stone. They can be switched around a bit, but this is a fairly typical way to do it. Lets get started using guest order as an example.
Gather address information: You need to gather all of the necessary information about the user's address to determine which restaurants can deliver to them. This can be hard coded or stored in environment variables if you are making something for yourself. You can also prompt the user if you are making a web/mobile/cli app.
Call the delivery list endpoint: This will give you all of the restaurants that are delivering to the user's address. For each restaurant, you now have important information such as the name ("na"), address ("ad"), expected delivery time ("del"), minimum order cost ("mino"), and cuisine types ("cu"). Cuisine types include categories like "Italian" or "Thai." That stuff is all important, but the thing you need to continue with order placement is the restaurant ID (“rid”). So have your user select a restaurant or pick a random one for all I care (it is your app after all!), and save the rid for the next API call.
Call the restaurant details endpoint: This gives you access to the nitty gritty details of what the restaurant has to offer. It gives you the location based details and the cuisine types again. What you really want from this, though, is the menu! For the scope of what we are doing here, this might as well be called the "menu" endpoint. Here you can display the menu to the user and build a tray based on their actions or use your own magic to design it for them. This is probably where you’ll spend the bulk of your development time either in a UI or in magic. If you need a recap on how to deal with menus, here you go. [link to menu 101]
Collect credit card info: This is something you also could have done when collecting the user's address info, but people are used to entering their credit card info at a some sort of "checkout" phase.
Call the fee endpoint: This is something you want to do so you can tell your users how much extra money they are being charged in whatever type of delivery fees exist for this restaurant. You’ll send the restaurant id, time (this usually defaults to ASAP), subtotal of their tray so far and delivery address.
Call the guest order endpoint and PLACE THE ORDER: Now the moment of truth has arrived! You can now take all of this information you have been gathering, and put it to use in one final, truly epic API call. And I mean epic! This one is a doozy to type out, and you will probably make some typos. Send the tray string along with the email, phone number, delivery address info, billing address info, credit card info, etc in the body of the post request (or the params object or regular function parameters depending on which API wrapper you are using), and an order will be placed! A confirmation will be sent to your user's email. Make sure you look through the response object to make sure no errors occured!
Debug what just broke: Your first (or second, or third...or more) order will not go through due to something you missed. You might have typed one of the field names incorrectly in the API call. Look at the error message, and try to gather any valuable information about what just went wrong. Go through the last few steps over again, and double check your code. Once that is fixed, it is time to fire up that post request. Lets get this party started!
Party like it's 1999!: Once your first guest order goes through on the test servers, and you are done thoroughly testing your app, get ready to place some real food orders! Order as much food as you can afford, and invite me over for a couple of beers to celebrate your awesome new hack!
If you don't feel like having to deal with all of that header setting nonsense of using REST APIs, you should check out our various API wrappers! I especially like the Swift API wrapper because I built it the day after the language was released, but that's another fun story.
Please check out the other 101 posts:
The menu structure (you get this from the Restaurant Details endpoint) is fairly complicated, at least compared to what you would expect. Putting together an order than is both valid and complete enough for a restaurant to deliver food requires a lot more detail than you’d think if you’re normal experience with food ordering is calling the restaurant and asking for a pizza with mushrooms.
So here are the basics - a menu is a hierarchy with up to 4 tiers, it looks like this:
Groups -> Items -> Option Groups -> Option Items
So one example could look like this:
Entree (a group)
-> Large Pizza (an item)
-> What topping would you like? (an option group)
-> Anchovies (an option item)
Each thing is modeled in the data as a JSON object, and if it’s not a leaf, it will have a “children” key which will lead you to the next level. That’s children in the sense of computer science not biology. :)
Items (the second level) are orderable with IDs that you can add to a tray - some of them require a specific number of option items. Inside of these menu items exist "option groups" which are not things you can add to a tray. Option groups (like "toppings", "dressing" or "sides”) contain sets of option items. Option items (the 4th and lowest level of the tree) are the actual options that you can select to add to a tray.
Some menu items require a specific number of options in order for them to be valid in a tray. A good example would be a menu item called "teriyaki platter" which has options for a type of meat. Lets pretend these options are "chicken", "beef" and "salmon." You wouldn't be able to order a teriyaki platter without specifying which meat you want with it, so this would require at least one option to be valid tray element. This logic is represented by two fields in the menu item called "max_child_select" and "min_child_select", which refer to the maximum and minimum number of options that need to be selected in order for this to be valid. NOTE - if max_child_select is 0, it’s equivalent to infinity (that is, you can select as many as you like) it does not literally mean, you can select at most 0 items.
Lets recap the structure of typical menu data using this teriyaki platter as an example!
"Dinner Entrees": [
"name": "Teriyaki Platter",
"name": "Meat choices",
"Other stuff": ...
In this case it goes:
Dinner entrees -> Teriyaki Platter -> Meat Choices -> Chicken
Build a tray: This is the food that the user wants to order. Maybe you will have an interface for them to select what to order or maybe you will programmatically select something for them. However you decide to do it, you know how the menu items are structured. Now you need to build a tray with the IDs of the selected items and option items to order.
The tray is composed of groups of menu items and associated, optional sub-items. A single menu item's format is:
[menu item id]/[qty],[option id],[option id]...
Multiple menu items are joined by a +:
[menu item id]/[qty]+[menu item id2]/[qty2]
Means 2 of menu item 3270 (with no sub options) and 1 of item num 3263 with sub option 3279.
And now you know how to validate a tray! That's the hardest part of using the APIs!
Please check out the other API 101 posts:
The Ordr.in servers you choose to use will determine whether your order actually goes through and charges a real credit card. This is the difference between a demo and delivering real, delicious, delicious food. If you are using the raw HTTP API, then the subdomains "r.ordr.in" and "r-test.ordr.in" will be what sets these apart. If you are using an API wrapper, then you would pass an argument like "ordrin.TEST" or "ordrin.PRODUCTION" when creating the ordrin object.
The test API is what you want to use when you are developing and testing (go figure), as well as when you are demoing at a hackathon (unless you have a good 45 minutes to stick around and wait for food to arrive). You can access to the test servers just by registering an account and creating an app, which will give you the keys you can immediately begin using, no approval required!
When you want to throw your app into the wild and have users placing real food orders with it, then you switch to the production API. Your API key needs to be approved by ordr.in before you can use the production servers - you can email them with some details of your app to get approved. And then let the food come rolling in.
Both test and production servers have the same underlying data - if you can place a test order without any errors you can feel confident that the same order would have succeeded in the live server. So please test as much as possible on the test servers!
One important thing - when your key is approved for production it doesn’t remove access to the test servers, so you can continue developing/testing with the same key. You’re also free to start another app to specifically have test only keys if you’re worried about accidentally specifying the wrong server - it’s up to you!
Please check out the other API 101 posts: