Online take away ordering - what is backend?

daymobrew

An existing client has told me that he is opening a take away and wants to have online ordering.
I think that he is comfortable with having a broadband connected PC in the take away.

What are good ways to deal with orders?
Should I use emails or would it be better to have a custom db?
If using a db, what is the basic db structure to allow for menu changes (adding/removing items)?

NeverSayDie

"I think that he is comfortable with having a broadband connected PC in the take away."

Well, he'd want to be, because short of using text messages or a Blackberry or some such, he's not really going to have any choice

Straight up emails from the customers are certainly the easiest technical solution - just need a PC with GMail up or a Blackberry or something. Not great from the customers' point of view though - they'd presumably have to compose an email to your client listing what they want, which is going to raise the barrier considerably in terms of convenience vs picking items off a menu screen or some such. It's also not a great solution on the client's end - things like organising and processing incoming orders, marking off fulfilled ones, keeping track of older orders, security, and any kind of automated reporting, searching or filtering are all going to be pretty tricky to do in any useful way. Even if you go with a semi-automated option, where the customer picks items from a menu and they're automatically stuck into an email, you still have problems on the other end re processing them.

Some kind of proper web UI and backend is the way to go. The main challenge here is getting a suitable workflow and UI to match your client's operations - you need to track the status of orders through the process, from placement to preparation to delivery and payment, that kind of thing. The right people need to access the right information at each stage of the process (and preferably only the right information).

On a technical level, this is a relatively straightforward database and UI setup job, the main tricky part is in getting a good design going that will a) enable your client's customers to come up with and place their orders as smoothly as possible and b) enable your client to fulfil those orders with the smoothest workflow possible. Then there's support stuff like the ability to update menus, reports and metrics to find out what's selling, that kind of stuff.

Re DB structure, not sure what you mean exactly, but I guess if you want to add and remove menu items, you just insert and delete rows from a menu items table.

Tbh, it sounds like you're a bit out of your depth on this one, best put your client in touch with a web developer of some sort to build this system, or look into existing off-the-shelf options, of which I'm sure there are lots. Plenty of takeaways use automated online ordering setups these days, no doubt there's folks providing the software for them.

daymobrew

NeverSayDie wrote: »

Straight up emails from the customers are certainly the easiest technical solution - just need a PC with GMail up or a Blackberry or something. Not great from the customers' point of view though - they'd presumably have to compose an email to your client listing what they want, which is going to raise the barrier considerably in terms of convenience vs picking items off a menu screen or some such.

Sorry I didn't elaborate on the email option - I meant selecting items on screen and the backend fires of an email.

NeverSayDie wrote: »

Even if you go with a semi-automated option, where the customer picks items from a menu and they're automatically stuck into an email, you still have problems on the other end re processing them.

Agreed - it was the management of orders that I was concerned with.

NeverSayDie wrote: »

Re DB structure, not sure what you mean exactly, but I guess if you want to add and remove menu items, you just insert and delete rows from a menu items table.

For the menu it is straightforward with a row for each item on the menu. For a submitted order, it might be easiest to have one row per order and a big vartext element which will contain the order details (basically the text of the order) but that's not the perfect solution.

NeverSayDie wrote: »

Tbh, it sounds like you're a bit out of your depth on this one, best put your client in touch with a web developer of some sort to build this system, or look into existing off-the-shelf options, of which I'm sure there are lots. Plenty of takeaways use automated online ordering setups these days, no doubt there's folks providing the software for them.

I've found a few on sourceforge that might be foundations: menube, Chinese Restaurant Online, TakeoutDelivery, Grill-M.

seamus

Although emails are the preferred choice for small setups, they can and do get lost and are difficult to keep track of. If you have a control panel in the backend, you can show a list of outstanding orders which can be printed out and ticked off as they're sent out.

If it's a delivery, you could even set it up so that the customer gets sent a "It's on the way" email when the order is handed over to the delivery guy.

The key to any online ordering system, regardless of whether or not payments are taken, is reliability. If the placed orders aren't looked after promptly and predictably, your customers will stop using it.

This is all academic though really. As usual, someone has done this before, and better than you can do on a reasonable budget:
http://www.just-eat.ie/contact

If he gets his takeaway listed here, the whole rigamarole of setting up a website is taken care of and he gets exposure to a lot more people than he might have previously. It means that obviously you don't get the same money as if you started from scratch, but your client will be happy, which means more work for you.

NeverSayDie

daymobrew wrote: »

For the menu it is straightforward with a row for each item on the menu. For a submitted order, it might be easiest to have one row per order and a big vartext element which will contain the order details (basically the text of the order) but that's not the perfect solution.

I'd strongly advise against that - those "packed string" approaches to database design almost always cause grief sooner or later. Having your data stuffed into a string in a single column makes it very difficult to search it, sort it, manipulate it, or any of the other things we use databases for.

I'd take a google around for something called "relational database design", that's how you design normal databases for these things. It's a bit of an acquired skill, but once you get your head around the general principles, you'll get the idea.

In the case above, a better approach would (at a basic level) involve having a MenuItems table and an Orders table (which also links to things like the customer and the delivery address). You then have an OrderMenuItems table which represents the relationship between the menu items and the orders. You just need to think about it in terms of the "relationships" between the "entities" in your model - in this case, an order consists of a list of menu items (amongst other things).

Eoin

I know it doesn't seem to be that popular here, but off the top of my head, I can't think why OSCommerce wouldn't do the trick for this?

daymobrew

eoin wrote: »

I know it doesn't seem to be that popular here, but off the top of my head, I can't think why OSCommerce wouldn't do the trick for this?

I recently saw a Dublin sandwich shop using OSC for their online ordering.

seamus wrote: »

As usual, someone has done this before, and better than you can do on a reasonable budget:
http://www.just-eat.ie/contact

If he gets his takeaway listed here, the whole rigamarole of setting up a website is taken care of and he gets exposure to a lot more people than he might have previously. It means that obviously you don't get the same money as if you started from scratch, but your client will be happy, which means more work for you.

I think Just-Eat contacted me after I launched the client's restaurant site. I declined because the restaurant's take away volume didn't justify it. I agree that this is probably bang on for the new take away. Thanks.

techguy

eoin wrote: »

I know it doesn't seem to be that popular here, but off the top of my head, I can't think why OSCommerce wouldn't do the trick for this?

+1 But I would suggest CubeCart.

I'd say it would be perfect.. The backend will let you manage the menu (categories/products), customers, orders, pricing etc.

The only catch here is that when an order is placed you will have to check for it or else get an e-mail notification.

To simplify this you could make a desktop program that would talk directly to the DB. This would display current orders,order status etc.. If this isn't your thing I would be willing to help you with it.

I would strongly advise against going down the e-mail from the customer side. At the bare minimum you should have an order form on a website that just e-mails the order to the restraunt.

daymobrew

techguy wrote: »

I would strongly advise against going down the e-mail from the customer side. At the bare minimum you should have an order form on a website that just e-mails the order to the restraunt.

I would never have even considered this as an option. NeverSayDie mentioned it because I didn't give enough info in my original post.

OSC shows the orders in the admin area, in addition to sending an email. The order page could be set to refresh regularly.

Having said all this, I've got to ask the client how many people are actually going to order online. The client needs to research this. It's not something I've ever done, even for establishments that offer the service.

techguy

daymobrew wrote: »

OSC shows the orders in the admin area, in addition to sending an email. The order page could be set to refresh regularly.

I suppose that would work depending on the frequency of orders. It could be a little awkward working with the OSC backend from the browser when in a busy restraunt.

I'm just thinking about what i've seen in restraunts before.

seamus

The oscommerce route would work, but I'd go with Zen Cart instead of oscommerce. OSC v3 has been "coming" for about 5 years now and doesn't seem to be getting any closer, whereas ZC is far easier to manage and customise, while still using the basic OSC architecture.

You might need a slight customisation for food orders - people will often like to make changes to specific items, so a "Special Instructions" box for every product would be advisable, instead of the "Special instructions" box at the end.

jimmytwomey

Sorry I have come to this late but you shopuld look at CaptivaSoftware.ie. They are an Irish company that provide integrated online orders via there web site EatCity.ie:)

Civilian_Target

We implemented a simple version of this that sent the orders by SMS.
It's a simple system that every pizzaman can understand, and there's no polling involved. It was all J2EE so we literally just installed an EAR and pushed a JMS message at it!