Use Cases

• Customer check-in (for both regular and anonymous customers)
  • Customer identifies self (name or nickname) or presents barcoded ID card
  • Attendant enters ID info into system; list of possible matches displayed, along with account status and balances. This "search" feature allows wildcards
  • Attendant selects the name/account they want and presses "Select" -or- enters new name/account info and presses "Create"
  • Attendant adds money to account if needed
  • Attendant selects desk assignment

• Customer check-out
  • Attendant selects desk assigned to customer, selects "Check Out"
  • System displays time remaining on customer's account
• Customer check-in or check-out override (for NCI or NCO)
• Customer change desk
  • Attendant selects desk assigned to customer, drags over new desk
• Customer checked-in makes payment
• Customer not checked-in makes payment
  • Attendant goes through select process, but instead of clicking "Check In", clicks "Add Time" instead
• Display customer history
  • Attendant goes through select process, clicks on "Show History"
• Create new customer record
• Reserve a game station (or cancel a reservation)

Hog/ShowGames Integration

• Hog/ShowGames integration is optional--the database should be useful (although not fully functional) even if Hog and ShowGames are not deployed

• A background process (or cron process) can watch ShowGames v2 idle status of each machine;
• if it appears that a machine with a customer assigned is idle for more than a set amount of time, flag the attendant
• if it appears a machine with no customer assigned is NOT idle, flag the attendant
• Which games the customer is playing should be recorded; either by ShowGames2 itself (by looking at Customer Database data as it does its scan) or by the background process, which uses ShowGames2's data.
• Maybe cause desktop to be locked out somehow until customer is assigned to that computer?

Other notes

• Customers must be able to view their account balance and history on web

• Be able to correlate against cash register: track amounts paid during the day, and what promotional prices were used
• Customer database is shared with PHP-Nuke user database
• Customers accessing via web authenticate with PHP-Nuke
• Customers who haven't signed up on web must still be in database, but in a way that won't interfere with PHP-Nuke operation
• Database must allow us to track
  • revenue by game
  • revenue by customer
  • customer behavior
• Database must be able to hold geographical data on each customer for feeding to GIS applications
• Must be able to handle a variety of different types of promotion:
  • Customer free time
  • Staff free time
  • Discount coupons
  • Club membership
  • Frequent-player
  • Quantity discount
  • Group discount
  • All excess time banked versus members only versus none
• Must be able to handle common styles of operation:
  • Prepay
  • Postpay
  • Membership
  • Ticket-based
  • Account holds time versus account holds money
  • Vary pricing by time of day, day of week, whether day is in table (holiday)
• Adaptable to different national currencies
• Customers must be able to share accounts if they want--several names on a single account--but if they do, the database should track which specific individual on the account uses time on any given occasion
• Customers should be able to make reservations charged to time in their account from the web interface
• Compatible with managing multiple stores with single set of roll-up reports
• Since Cust. Database is tracking how much time people have and what seat they are in, it can provide warnings/reminders to the attendant, and, if enabled, can play audio reminders for customers, too.

Database structure

• PHP-Nuke has nickname, password, reg date: we don't add any fields to Nuke, only use what's there. Also, we do NOT use the name field in Nuke (because we want to keep first/last name separate). If a deployment isn't using PHP-Nuke, they can just create their own DB here to substitute.
• user_id
• name
• username
• user_email
• user_regdate
• user_password

• Users:
  • Customer ID
  • Last Name
  • First Name
  • Account ID
  • Photo ID
  • Grade Time Balance
• Accounts:
  • Account ID
  • Time Balance
  • Account Notes
• Transactions:
  • Transaction ID
  • Date/Time
  • User ID
  • Account ID
  • Transaction Type (Buy, Use, Transfer, etc.)
• Groups (for tracking customer affiliation groups):
  • Group ID
  • Group Name
• Photos:
  • Photo ID (because we might want to use generic photos for multiple customers)
  • Photo