An Interesting Programming Problem

An Interesting Programming Problem

Chairs in resturants. Simple right? The client currently donsn't have an online booking system for their restaurant.

Start with the object we're told.

Objective(s)

  • Reduce time spent dealing with bookings
    • Emails, back & forth between customers (how many peple/what time) multiple emails!
  • A solution "ASAP" (within 3 months, 6 months would be too long)
  • Nothing that takes commission, or sends customers annoying notifications/offers
  • Can be used on tablets

Hang on a sec! We don't need to do everything we discussed in the meeting to begin solving the objective! Let's start small.

Complexities

Resutrants have tables. It gets interesting the more questions you ask!

These came up in the meeting:

  • Some tables are high-seated with bar-stool-like tables (possibly not suitable for older people, or those with back problems)
  • Other tables are 'standard' tables with back rests, seating between 2-6 people
  • Tables can be combined to create larger tables, or split to make smaller tables
    • There is not simple notion of a 'fixed' table...meaning:
  • Additional (in this case) small tables can brought from upstairs to add capacity e.g. turn a table seating two people into a table seating four people
  • Time, guests are limited to a 2 hours seating.
  • Churn cannot cope with more than 10 customers every 30 minutes , so need to balance double booking vs predicing when capacity might become available
  • Not all tables are avalable all the time, e.g. a quardand off table or simply chooing to not use certain 'table' in one instance (again, thre's no such thing as a single 'table')

Let's get coding. No! Rearch first! Research: Table booking in busy environments.

Proposal

Working ad-hoc creating a working system as soon as possible. Learning from that, improving as we go.

Client: "That's great but sounds like it could go on forever!

Supplier: "We can capp it at £x amount and guarantee you get a working system by end of three months.

Problem: But we (supplier) don't know what a working system equates to. How well definded is the working system? How will we know the client is happy at 3 months end?

Solution: Probably happy when it significanty meets the objective! So there's probably an element of performance which needs to be put into the agreement. e.g. "Significantly reduces time spent dealing with bookings.

Because it can't be we guentee that feature x,y,z at this early stage will be made because the client nor supplier knows if those features are even needed/useful in reality before we try them!

Capped costs: £4,000
Capped time line: 3 months

Required Infomration to make a booking

  • Name
  • Telephone
  • Email (not required)
  • Is this a special occasion (not required)
    • If yes, who/what
    • If birthday, tell us name of the birthday boy/girl (nobody likes singing happy birthday not knowing which name to sing!)
  • Customer loyalty (internally)
    • Keep note of customer loyalty so it can be appreciated

The Unknowns

There are many many of these!

Collect recurring payments with Subscribie - Try Now