Of all the tasks related to your POS system programming, none is more important than the maintenance and programming of your menu.

Whether you will be doing the programming or you’ll be delegating that to your POS provider, there is no substitute for the information you gather to inform important decisions about your menu construction.

The first step is the obvious one: collect the names and prices of all your menu items in an organized fashion. Something as simple as an Excel spreadsheet, outlining the items and the associated prices, can be an invaluable tool during this phase. Eventually we will add more information to the spreadsheet (or however you wish to organize your data), but we’ll leave it at name and price for now. In organizing this information, we’ll also want to take into account whether any of these items are time-sensitive. For example, we may be serving brunch on Sundays which involves a set of menu items not normally served on the regular menu. Again, make note of these differences. Along with the names of the items themselves, we also want to record any standardized abbreviation of menu items used to take orders. This may be the shorthand that your staff uses to pass information succinctly to the kitchen, or it may simply be the abbreviation you want to use on your kitchen printouts, but let’s capture that information now. If you are not using a standardized abbreviation for your system, well… no time like the present! As mentioned in previous articles, your POS system does not take kindly to the use of vague, non-specific information. If this is the first time you are incorporating a POS system into your business, you may find that the programming forces you to make some decisions previously left unanswered. Don’t look at this as a burdensome task, but, rather, as an excuse to apply some strict organization to an area of your business that was left hazy in the past!

Now that we have our basic menu information, let’s talk modifiers. Within our POSitouch programming (as always, our point-of-reference for these examples, but the overarching process still applies, no matter the POS system), we will include a few universal modifiers to be included with almost any item. We will create an option we typically call See Server and another called Memo, which brings up a keypad allowing us to type in special instructions. Between these two options, we can generally handle most customer requests. But these generic modifiers are just the tip of the iceberg. We want to create a list, much like the list of menu items, of the modifiers we will be using. We may even want to add these as subgroups under the relevant menu items. For example, we may have a list of modifiers that include meat temperatures (rare, medium rare, medium, etc., al.) kept on a separate sheet, or we may include these modifiers directly beneath the 6 OZ Sirloin we’ll be selling. Either way, we want to make clear which are items and which are modifiers, and the association between the two. Modifiers can represent a sort of rabbit-hole of programming where we begin thinking of every conceivable option that may be added to or left off an item. We advise that you use only the most likely modifiers for a particular item and leave the seldom-used options for the Memo key. You will also need to organize these modifiers into two further subgroups which we refer to as Must Selects and May Selects. The difference between the two is simply this: which items are required for preparation by the kitchen and which are simply possibly inclusions or exclusions? For example, temperature on a steak would fall under the category of Must Selects, because, without that information, the kitchen will have no way to determine how the customer wants their steak prepared, while adding sautéed mushrooms may be an option, but is by no means required on every order, hence a May Select.

Now that we have our items and modifiers, we will want to define where these items will be printing. In some cases, you may want your dining room terminals to print bar drinks at the bar, but not necessarily if the items are ordered by the bartender. Likewise, we may have a salad option under our entrees, but we may not want that salad to print to the kitchen because a server will prepare the salad, and why waste all that paper printing something the kitchen does not need? Consider who needs to see the item to prepare it and avoid overcrowding printers and staff with needless information.

Lastly, we want to account for any price differences based on time of day. The most common usage of alternate pricing is for restaurants or bars which offer a “Happy Hour,” where drink prices and food may be discounted. We will want to make a note of which items will be discounted, the new price and the times where the alternate pricing will apply. You may also run “Daily Specials,” where the same menu screen may change daily based on predetermined menus. Be sure you address any of these unique situations with your POS dealer to determine the best manner to handle your specific requirements.

We have now gathered our menu items, their prices, their modifiers, and their print destinations. Now that we’ve collected all this information, you’re ready to program your menu! If your POS supplier will be doing the programming, they will still require this information to complete the programming in an expedient and effective way. Remember, no one knows your menu better than you, so take the time to organize this wealth of knowledge into a logical form for your programmers’ use.