# How does your ordering system work, and any comments about that?



## srix55 (Feb 5, 2014)

Hi All,

I am a software developer writing a software for restaurant management, that compliments the existing ordering system. I am facing a lot of problems owing to my lack of understanding of how restaurants work on the inside. I would greatly appreciate it if you could help me understand.

I need to know a few things about your workplace and your opinion about that.
1) Are orders taken from the customers via paper? Or are orders taken via a mobile device like a tablet / mobile phone / iPod ?
2) How are the orders passed on to the kitchen? Are the orders punched into a system which prints/displays the order in the kitchen? Or, the hand-written order manually passed on to the kitchen?
3) How does the waiter come to know that the food is ready to be served?

I believe many of you would have come across different types of systems. Among the systems you have come across, which type of system, in your opinion, was the most beneficial? Please take a few minutes to answer. It would help me a lot. Thank you for your time.


----------



## kuan (Jun 11, 2001)

I'm moving this to the Late Night Cafe. Note the redirect, but feel free to help out if you can.

@srix55 Every restaurant is different, but in general writing the order manually and walking over to a station and entering it is pretty standard. I would suggest physically going to a restaurant and observing.


----------



## dillbert (Jul 2, 2008)

the coding is easy.

knowing _what_ to code, not so easy.

there's a new sheriff in town - a tablet like gadget.  waitstaff enters at the table, the 'lectronics do the rest.

no handwritten nothing.  screens and screams.

and it goes from there to totally manual - table to kitchen and back.

>>writing a software for restaurant management, that compliments the existing ordering system.

there is no compliment.  it is the system or it is not the system.

it sounds a bit like this is a project you've dreamed up / imagined / think is a good idea - but to be brutally honest, you will likely find it all exists in every iteration imaginable.


----------



## srix55 (Feb 5, 2014)

@kuan Thank you for posting my thread. That is exactly what I tried doing in the first place - approaching restaurants to know how they work. But they are not so keen on letting me in on how they operate. Maybe it is because I am an indie developer, not associated with big shot software companies, or maybe they think I am from the competition or maybe I look like a food quality inspector. Don't know. About how they order, I have seen waiters walking over to a station to punch in the order. Wont it be a problem for waiters to do that during rush hour?

@Dillbert >>there's a new sheriff in town - a tablet like gadget.  waitstaff enters at the table, the 'lectronics do the rest.

no handwritten nothing.  screens and screams.

Are you talking about where the waiters punch in the order to the system? So, waiter takes order from customer and goes to a central location where tablet is there, and punches in the order which goes to kitchen displays. Do I understand correctly?

>>there is no compliment.  it is the system or it is not the system.

Actually, I have seen in many restaurants (as a customer), that they don't use tablets for menu. My idea is to display the menu to the customers on a tablet (comes with pretty good advantages, but at a cost). But, I don't want to replace any existing hardwares/softwares of the system used by the restaurant. That is what I meant by saying I need to compliment the existing ordering system.

>>it sounds a bit like this is a project you've dreamed up / imagined / think is a good idea - but to be brutally honest, you will likely find it all exists in every iteration imaginable.

I am half way through and will pretty soon (2-3 months approx) release a test version, provided I integrate seamlessly with existing systems - that is where I am stuck, and need help in understanding.


----------



## dillbert (Jul 2, 2008)

there's four / five basic systems:
(1)  wait staff "memorizes" the order table side, orally relays to the kitchen. works for small, not so good for big.
(2)  wait staff takes/writes the order(s) tableside, then rips out the 'paper ticket' and hands off the paper ticket to the kitchen
(3)  wait staff takes/writes the order(s) tableside, then goes to a 'station' and 'enters' the order(s)
(4)  waitstaff has a wireless device, takes the order(s) table side, hits "Enter" - all done.  no paper except for billing/receipt issues.
and exceptionally more limited use:
(5)  "self-serve" order entry.  pick a table, sit down, customers punches in their own order.  dishes mystically appear from the kitchen delivered by someone they've never seen before.  there is no service / wait staff, only 'delivery staff.'  not suited for much past fast food "no options" other than one-from-Column-A-and-one-from-Column-B.

>>Do I understand correctly?
no.  it is the difference between system 3 and system 4.  
"old style" system 3 used mouse & keyboard, "new style" system 3 is touch screen - and how to enter "special instructions" is a thorny issue there.
system 4 totally bypasses the "go to station and enter order(s)" thing.  instead of writing up a paper ticket / document to use / 're-enter' at a 'station' the information is directly entered real-time at the table.  obviously needs to be a secured wireless network, otherwise the hackers will be ordering up triple thick, ultra rare, stegosauous steaks for table 4 - which is suddenly discovered to be empty.

>>Actually, I have seen in many restaurants (as a customer), that they don't use tablets for menu. My idea is to display the menu to the customers on a tablet (comes with pretty good advantages, but at a cost). But, I don't want to replace any existing hardwares/softwares of the system used by the restaurant. That is what I meant by saying I need to compliment the existing ordering system.
what I read  this is simply moving away from a paper menu to an electronic menu presentation.

for a 20 table establishment, and a $200 electronic menu tablet, that's $4000 in capital investment, or more - one 'tablet' per table or per customer?
vs. $0.03-0.04 per laser printed daily menu.  do the math, four cents per paper menu vs $200 per tablet per customer - takes 5000 customers to pay off.  presuming no tablets break or get stolen.

it is simply not possible to go any further than 'electronic menu' vs 'paper menu' without replacing/expanding hardware/software already in use.

and in fact, the most rudimentary "menu tablet" will required daily / hourly / on-change 'up-dating' to avoid the customer seeing / being offered / ordering something that is out-of-stock.  none of that hardware/software will currently exist.  nor will any 'procedures' exist for 'management' to keep the 'updating routine' up-to-date.

I'm sure I don't understand your efforts; especially as you expect to release a test version shortly.  
virtually nothing electronic  - without change to existing hardware/software - will function in any fashion in a paper menu oriented eatery which writes paper tickets that are relayed, on paper or electronically, to the kitchen. 

if the eatery has electronic communications/tickets to the kitchen, any 'supplemental' system - other than an electronically presented menu - will require an interface to the existing electronic system - that interface does not exist in the existing system and will require a custom interface in your software to work, and you'll need a lot of proprietary information from "the other system" to construct such an interface, along with quite likely major software modifications to 'the other software' and some kind of hardware integration to go to an open wireless from a closed user environment.

I wish you good luck with the project.


----------



## srix55 (Feb 5, 2014)

@Dillbert That was super informative.

>> there's four / five basic systems:
I cannot target the 4th and 5th type systems. I am hoping for the first 3 types.

>> (3)  wait staff takes/writes the order(s) tableside, then goes to a 'station' and 'enters' the order(s)
My idea is to have a tablet right next to the station, such that, when the customer orders on the menu-tablet, the order beeps in the tablet (that is right next to the station) where the order can be copied and punched into the station. But would be a problem if there are multiple stations. I have never come across multiple stations in restaurants, even though I believe it is theoretically possible to have multiple stations. Is it practical for restaurants to use multiple stations?

Another solution to eliminate copying the order to the station is to have my printer in the kitchen, such that a ticket is generated with a buzz, immediately after the order is placed in the menu-tablet by the customer. But, I think (correct me if I am wrong) many useful reports are generated by the existing system based on what time the customer places the order and similar information. Since my order never gets entered into the existing system (entered only to generate a bill), those reports would not be accurate. If you were to weigh the option of having my printer (extra hardware, more efficient - no time wasted in copying, but inaccurate customer behaviour reports) over order copying to existing system (less efficient, accurate behavior reports), which one would make more sense?

>> for a 20 table establishment, and a $200 electronic menu tablet, that's $4000 in capital investment, or more - one 'tablet' per table or per customer?
For a 20 table establishment, the capital can go up to $8000. I am planning on renting out my system (tablets/printer/wireless routers etc) to the restaurants, and the rent would be something like 2-3$ off every bill - havent worked out the exact number I would need, with a 1-3 year contract to reduce the rent off every bill. Definitely more expensive than paper based menus, but comes with extra benefits like social media marketing, accurate ordered food feedback & customer loyalty programs.

>> and in fact, the most rudimentary "menu tablet" will require daily / hourly / on-change 'up-dating' to avoid the customer seeing / being offered / ordering something that is out-of-stock.
That is true. I still have not figured out a way to do that.

>> that interface does not exist in the existing system and will require a custom interface in your software to work, and you'll need a lot of proprietary information from "the other system" to construct such an interface, along with quite likely major software modifications to 'the other software'
In fact, thats the biggest challenge I am facing.

>> I wish you good luck with the project.
Thank you. And, thank you for patiently clarifying my doubts.


----------



## dillbert (Jul 2, 2008)

everything you're talking about is long established technology - marketed, sold, supported by small to large companies.

see:

https://www.aldelo.com

http://www.rmpos.com

http://restaurantpos.com

for starters, Goggle 'restaurant pos' for the rest - there's hundreds.


----------



## brandon odell (Aug 19, 2012)

Ditto that. Sounds like you are trying to reinvent the wheel, and without any experience. Not trying to be rude, but why would someone with no experience in restaurants or with restaurant POS think they are qualified to write a restaurant POS program? There are countless companies who already do all of what you propose. There are even tablet and online ordering systems that give the software away for free if you use their credit card processor.

No offense, but I think you should look for another project. This doesn't sound like a very fruitful endeavor. Especially since you don't know enough about the industry to realize what you are wanting to do has already been done, a lot.


----------



## srix55 (Feb 5, 2014)

@Brandon ODell My idea is not to become another POS system per se. I was aiming for something like what these guys are doing - Elacarte and Ziosk. They have a few flaws to which I have effective solutions (in terms of software & user experience designs). The idea is to provide for the best dining experience (doing everything that a menu tablet can possibly do like how elacarte & ziosk are doing), without encroaching upon what existing POS systems provide, and at dirt cheap prices (compared to them of course). For example, say a restaurant is using Micros / Aldelo POS system under a contract of say 2-3 years. If he wishes to provide a touch dining experience to his diners, he really does not have any choice other than to go to his POS provider, who are too damn expensive. If he wants to have the features provided by another POS system (that provides a much better tablet based customer-end solution than Micros/Aldelo and say at a cheaper price), those guys straight away tell him to change his POS to theirs. There aren't many companies like Elacarte & Ziosk, who are not POS providers, but compliment existing POS system of the restaurant.


----------

