This application provides for multi-course centralized TeeTime management -- including provisions for taking TeeTime Reservations (for the general Public, Members, Groups, and Blocks), Guarantees-Deposits, Confirmations, TeeSheet preparation, Check-In, Cancellations, integration with Retail Point-of-Sale, and various statistical Reports.
This module has primary interactions with Abacus 21's Client-Member Management, Group-Event Management, and Retail Point-of-Sale Systems.
This Section will focus on the workings & interaction of TeeTimes & Point-of-Sale.
The TeeTimes vs. POS subsystems are intended to do two different (but potentially-intertwined) things – and the distinction between them needs to be made clear.
Furthermore, each of these respective Systems is configurable -- in an attempt to provide each Client-site flexibility on how it “operates” for them by appropriately adjusting the setups that control the “flow & behavior” of the System(s) and how they work together.
TeeTimes – The primary purpose TeeTimes is the ‘Reservations Booking’ preamble to Golfing.
This includes determining (for the nature of the Customer, Course, Season, Date, Type-of-Day, Time-of-Day, and 18-Hole vs. 9-Hole), the TeeTime availabilities (recognizing appropriate restriction and double-booking controls).
It is important also to note that the TeeTime System can determine the pertinent Green Fees and perhaps Cart Fees for each of the Players – including also (via options) maybe pre-arrangements for Club-rental, Shoe-rental, Range-Balls, Lesson-fees (and perhaps Lesson Appointments), etc.
The TeeTimes System also allows for free-form Comments regarding the FourSome itself – and/or allows for Comments for each of the respective individual Players in the FourSome (which can actually be up to a SixSome – without having to ‘squeeze’).
The above is aside from the ‘Group’ & other ‘Blocking’ and Reservation Moving & Copying & Audit-Trail functions of TeeTimes.
Since the TeeTime is “connected” to the Abacus 21 Client file (which can include Prospects, Members, and Others [which implies Guests and Guests-of-Members]) – the TeeTime System can do lookups to any of this – and check (in particular for this discussion) Names, Relationships, Membership Types, Player Classes (which influence Rates & Restrictions), pertinent Comments, pertinent Statuses (A/R-related and general), etc.
Player-Classes control the Availabilities, Restrictions, and Rates
Guest-of-Member Controls are available
The other type of ‘Customer’ that the TeeTime System can recognize is a ‘Transient’ – namely someone for whom you merely record the ‘Name’ of the Player with respect to the TeeTime (and consequently TeeTime History) – but without retaining tons of information for that ‘person’ that is available if you had declared the person to be in the ‘Client’ file itself.
Note that since TeeTimes has the ability to determine each of the respective Player’s appropriate Fees for GreenFees (18-Hole vs. 9-Hole), Cart Fees (and perhaps Club-rental, Shoe-Rental, Range-Balls, Lesson-Fees) it can pre-know all of this… and automatically transfer it to Point-of-Sale… eliminating the need for the POS Clerk to deal with it… while still allowing additional POS-related Items to be added to any Players automatically-generated (from TeeTimes) Ticket.
The TeeTime Reservation System currently has three general formats than can be adopted for the default-style of TeeTime Booking:
Reservation (Detail) Mode – oriented more toward see a panorama of the TeeTime (with less detail per Player ‘naturally’ shown). From this Mode, you can easily toggle to Player-Detail-Mode when you are within a Reservation.
Player (Detail) Mode – oriented more toward revealing more information about each of the respective Players in the TeeTime. From this Mode, you can easily toggle to Reservation-Detail-Mode when you are within a Reservation.
Wizard Mode – a configurable set of Screen prompts that lead a TeeTime Reservationist thru (automatic) determination of Player Class, Source, Group information on a new TeeTime – prior to going into Reservation-Detail-Mode or Player-Detail-Mode.
The principal Statuses (and hence functions) within a TeeTime (per Player-Slot within the TeeTime) Reservation are:
Booked
Checked-In (optional)
Paid (Sent-to-POS; the POS Ticket’s exact status is indeterminable at this point)
Cancelled
No-Show
Note that these Statuses are per-Player within the TeeTime.
When a TeeTime Reservation is called up (within TeeTimes) and is ‘Paid’ (actually, Transferred-to-POS), the declaration of who-is-paying-for-whom is made on a per-Player basis… and any combination of Players (Player’s Fees) within the TeeTime can be ‘grouped together’ and directed to a particular (intended) Player responsibility when Sent-to-POS for settlement.
Player’s Fee Settlement responsibilities can be Sent-to-POS individually (to be paid by each respective Player), all in one bunch (all to be paid by one Player), or in ‘grouped’ (for example, Player-1 intends to pay for himself and Player-2, Player-3 intends to pay for himself and Player-4).
Each ‘grouping’ of settlement Transferred-to-POS creates an individual POS Ticket (with the designated Player as ‘intending to pay’ noted in the Header of the POS Ticket) – and immediately can launch Point-of-Sale.
The resultant POS Ticket(s) are created with an ‘Open’ status, noting the respective designated (intended) paying Player in the Header, each of the TeeTimes included in the settlement are displayed on the Ticket as Line-Items (inclusive of the Player-Names of those respective Player-Slots), the appropriately determined Green Fees – plus any force-fed (from TeeTimes) Cart Fees… and perhaps Club-rentals, Shoe-rentals, Range-balls, Lessons.
Since each such Ticket is ‘Open’ additional Items (Merchandise, Services, or other GreenFees or Cart etc.) fees can be added to the POS Ticket.
If multiple Tickets are created simultaneously from TeeTimes… POS will present the first Ticket (in ‘Open’ and editable condition)… and once that Ticket is consummated-or-exited within POS, cycles onto the next queued up Ticket…. Etc.
As with all POS Tickets, the initial (and perhaps only) Tenderment can default to the default Tenderment implied by the Customer noted in the Header of the POS Ticket – facilitating the 'Quick Pay’ option.
As with any POS Ticket, any of these TeeTimes-generated POS Tickets can have Header elements adjusted, can have other POS Items added, can accommodate other allowed POS Item-Price-Markdown-Discount adjustments, and can have any revised Tenderment Settlement (including split-Tenders, split-Tickets, Credit Book, Gift Certificates/Cards, etc) that are normally set up to function within POS. (The Clerk may also choose to leave any of these Tickets ‘open’.)
When the one (or all) of the Tickets are “dealt with” by the Clerk, the System will automatically bridge back to TeeTimes (to the exact Course-Date-TeeTime that spawned POS -– indicating the relevant ‘Paid’ Statuses of each of the Player-Slots of the TeeTime.
Point-of-Sale – The primary purpose of Point-of-Sale is the “transacting” of the ‘Sale’ of things in the ProShop (inclusive of any GreenFees or Cart Fees etc. that emanated directly from the TeeTimes Reservation System or are associated with TeeTimes)… and, of course, consummating the Sale with pertinent Settlement Tenderment Payment(s).
The general functionality, features, and configuration alternatives of Point-of-Sale itself will not be discussed here…. but from an interaction with TeeTimes perspective, the following points need to be emphasized.
The is a distinct difference between TeeTime information and POS information:
TeeTimes is focused on Reservation-Information. TeeTimes are ‘notational’ and have no Sales or Accounting effects.
Point-of-Sale is focused on Sales of Items-Services-etc. and the Tenderment thereof. POS Transactions are ‘official’ and do have Sales and Accounting effects.
The inference if this is that:
Statistics about ‘Who’ played (actually: made TeeTime Reservations) on ‘What Course’ at ‘What TeeTime’ with ‘What Other Players’ can be found in the TeeTimes Reservations segment of the Database… and not in the POS segment of the Database.
Statistics about ‘Who’ ultimately bought what ‘When’… and ultimately ‘Who Paid’ can be found in the Point-of-Sale segment of the Database… and not in the TeeTimes segment of the Database.
Furthermore, it is important to note that in a realistic scenario the following corollaries may be evident:
Not everyone who plays a Round of Golf will necessarily have a TeeTime Reservation.
Not everyone who plays a Round of Golf will necessarily have a corresponding Transaction that goes through Point-of-Sale.
Not every TeeTime Player-Slot Reservation has a corresponding Point-of-Sale Settlement – and vice-versa.
Whoever might have ‘intended’ to pay (from TeeTimes) may not actually pay when things go to Point-of-Sale – and/or Tickets might ultimately be split or split-tendered.
Transferring a TeeTime to Point-of-Sale (in whole or part) does not mean that the POS Ticket gets ‘instantly’ paid.
In order words, TeeTime Reservations are inherently ‘different’ from POS Transactions – and therefore Reservation statistics are different from Sales statistics… despite the general utopian-presumption that they “should be the same”.
TeeTimes can be used to “force-feed” Point-of-Sale… with the per Player-Slot Player-Name, Course-Date-TeeTime, Green Fee, Cart Fee – and perhaps other ancillary Fees as mentioned above – eliminating the need for the POS Clerk to figure out and enter any of this at POS time.
Note that POS can accommodate Package-Items – in which the Component Items of the Package-Item can include a GreenFee-related Item Code (Priced or Non-Priced) packaged with an appropriate Cart Fee related Item Code.
It is generally not a good idea to ‘skip Point-of-Sale’ for those Members who do not have to pay Green Fees or Cart Fees as an entitlement of their Membership.
Rather, these “included for free” Green-Fees or Cart-Fees should be run-through POS at either zero-price or 100%-Discount…. so as to properly record the Quantity (and Accounting) effect.
Otherwise, these Member-related zero-Price Rounds will NOT appear in the Sales Analysis (and distort your Rounds statistics… creating even more mis-match between TeeTimes Rounds statistics and POS Rounds statistics).
In the context of Package-Items, a ‘free’ Green-Fee can be coupled with a ‘priced’ Cart Fee… and thus that care of both matters in one-fell-swoop…. and that Package-Item can be also set up to be pre-attached to particular Types of Clients and automatically adopted within TeeTimes… and automatically slipped over to POS – all without any extra Operator intervention.
Each of these Systems (TeeTimes vs. Point-of-Sale) has its own respective standard Reports.
The POS-originated Sales Reports, for instance, react to the normal POS-Sales Reporting parameters such as Date Ranges, Distribution Code breakdowns, Sales Category breakdowns, and Item-Code differentiation.
As such, from a POS perspective, the System Administrator needs to be judicious in the creation distinct-enough G/L-Accounts, Distribution-Codes, Sales-Categories, and Item Codes to achieve the desired reporting (and Accounting) detailing-and-aggregation.
Likewise, from the TeeTimes perspective, the System Administrator needs to set up appropriately-differentiated Courses, Seasons, Types-of-Day, Times-of-Day, Player Classes, etc. to properly-adequately differentiate how TeeTimes will be ‘price’ and ‘function’… along with accommodating the resultant statistics that it can generate – and, most importantly, since every TeeTime ultimately gets linked to one-or-more POS Items, that sufficient distinction for the Items linked to POS is established (see above related points).
In addition to the normal reporting, since the entire Database is fully-ODBC-compliant, you can ‘get at’ any of the data with a variety of (optional) Ad-Hoc Reporting Tools… for example:
Data Extracts & Queries via MicroSoft’s Excel™.
Inquiries & Reports via MicroSoft’s Access™.
Utilization of Abacus 21’s Report Builder Module (extra option)
Utilization of one or more of Abacus 21’s Data Analyzer DataCubes (extra option) that are designed to allow you to “Slice-n-Dice and Export” your Data --such as, in relation to this discussion:
Client-Sales DataCube (for POS Live-History Data Analysis)
TeeTimes DataCube (for TeeTime Reservations Data Analysis)
Any other 3rd-Party ODBC-compliant Tool – such as, for instance, Crystal Reports.
Contact Abacus 21 Sales for further information on the Abacus 21 products.
See Abacus 21’s On-Line Help for Data Extractions or Crystal Reports for examples of how to access your System Data via these methodologies.
There are, in general, three-four Junctures if you are utilizing full TeeTimes integrated with Point-of-Sale:
Book the Reservation (presumed to have been done in advance of the actual TeeTime Date-Time).
Check-In of a Player (or Players) within TeeTimes – this is a totally optional step.
Pay (Transfer-to-POS) – Select One, Several, or All Players in a TeeTime at a time to be sent to POS.
Point-of-Sale – To possibly add Items (to the GreenFees & Cart Fees already transferred to POS), to possibly split Tender, and to Settle.
Let’s examine the steps involved in each – assuming a Foursome.
It is assumed that the TeeTimes Program is already started… and it has been configured to automatically launch Point-of-Sale.
Book the Reservation –
Navigate to the Course (if you have only one Course, this step is eliminated).
Navigate to the Date & TeeTime desired: Mandatory
Double-click the TeeTime or right-click the TeeTime (and select ‘Book TeeTime’). Mandatory
Specify Player-1 (by any of several methods listed below): Mandatory
Enter their Client ID.
Standard-Client Search - Hit Magnifying Glass to invoke... which allows you type in, for instance, a portion of the Client’s Last Name (and tries to find a ‘match’ by default… which is the fastest search mechanism since it does not have to retrieve the entire Client Database). Other filters are available if pertinent.
Invoke the Walk-In Client Search (and Creation) – which is triggered by an Administrator-defined Client-ID.
Typing in a portion of the Client’s Last-Name will perform a dynamic ‘match’ attempt (encompasses, in general, a search of all Prospects, Members, and Other [Guests] who are in the Client file).
If the Client is found (displayed) select that person… and the rest of the Walk-In Client Screen is filled in…. and accept the choice.
If this is a new Walk-In, complete the mandatory (as defined by the Administrator) portions of the Walk-In Customer Screen.
Utilize a Client ID Card – swiped or scanned as appropriate (if available)
Complete Player-1’s Information – as Administrator-configured to be Required, Available (Optional), or Disabled (entry skipped)
If the ‘Required’ fields and ‘Optional’ fields are set “lean”, then you’re done with Player-1.
Player-Class is an essential field -- as it governs Rates, Restrictions, etc.
Most of the time Player-Class has already been associated with the Client or is Defaulted – and requires no additional effort.
If, however, the Player-Class is not filled-in or defaulted, you will have to select an appropriate Player-Class.
See the Golf Course Setup Screen below for examples of some of the configuration variable settings:
Enter Player-2, Player-3, and Player-4 (and sometimes Player-5 and Player-6) in the same manner. Optional, but typically done.
If Players 2-3-4 Names are unknown (at the time of the Reservation Booking)… and are being Booked under the auspices of Player-1, hit the ‘Reserve Next Slot’ button (three times… or whatever is appropriate).
Note: If explicit Players are not identified eventually within the TeeTime, the various related Systems (TeeTimes, POS, and Sales Analysis) will of course not be able to differentiate information to specific Clients-Players.
'Book' the TeeTime - If no other information entry or adjustments are necessary, ‘Book’ the TeeTime by hitting the ‘Book’ button…. and you are returned to the TeeTime Booking Screen.
Adjustments can be made to any TeeTime after the fact by merely re-calling the TeeTime by hitting its ‘Book’ button.
If, however, the Player-Class is not filled-in or defaulted, you will have to select an appropriate Player-Class.
Previously ‘un-named’ Players can also be filled in at a later time.
For Group Bookings, initially-unknown Player Names can be filled in later once known.
See the sample Screen below for a simple TeeTime… with one ‘known’ Player who is Booking a TeeTime for himself and three other (as yet unspecified) of his Buddies.
Check-In – Optional
This step totally optional – dependent on how the ProShop chooses to run its operation.
If you are going to utilize Check-In, all you have to do is:
Navigate to the TeeTime and re-call it. (You can also use the Player Search to find a TeeTime associated with a particular TeeTime.)
Check-In ALL Players or any respective Player(s) by hitting the appropriate Check-In Button(s).
If you now know the previously un-named Player, they can be entered or looked up as normal – with their Player-Classes adjusted appropriately.
The Screen below shows the Player-2-3-4 Names filled in… and both Mr. & Mrs. Johnson checked-in… with their two Guests not yet present:
Paid (Transfer to Point-of-Sale) – Optional
To go into Payment mode, recall the TeeTime and hit the ‘Payment’ button.
The Payment Screen allows you to select which Player-Slots you want to settle (Transfer to Point-of-Sale)… and which particular Player(s) are (intending) to ‘pick up the tab for’ which other Players within the TeeTime.
Below is the initial Payment Screen:
Mr. Johnson has already checked in… and want to pay for himself and Mrs. Johnson (Cecilia):
Change the Paid-By-Player to 1 for Player-1 and Player-2:
Hit the ‘Transfer to Point-of-Sale’ button to bridge these selected Player-Slots over to POS:
Note the Course, TeeTime, TeeTime Player-Slot, and Player Name References on the Line-Items.
Then, for example’s sake, add another POS Item (Spaulding Balls) to the Ticket:
Close out the Ticket… in this case via 'Quick-Pay' to Member Account Charge.
Since there was only one POS Ticket (for both Player-1 and Player-2) automatically created by TeeTimes and we have we ‘handled it’, the System automatically returns to the TeeTime Booking Screen:
Note that Player-1 and Player-2 are ‘green’ – indicating ‘Paid’. Players-3-4 are still ‘red’ (Booked but not Checked-In nor Paid).
Recalling the TeeTime now shows that Player-1 and Player-2 are Paid (see right-hand side):
Hit the ‘Check-In’ Remaining Players to Check-In Players-3-4. Optional
Notice that Player-3 and Player-4 are now checked in (right-side).
If we were to go back to the TeeTime Booking Screen, we would see:
Notice that Player-3 and Player-4 are in ‘orange’ (Checked-In).
The TeeTime Reservation Screen confirms this… and also is ready for the Operator to send the remaining two Players (3 & 4) to POS:
Hit the ‘Payment’ Button:
We’ll now have both Player-3 and Player-4 separately pay for themselves.
Hit the ‘Players Pay for Themselves’ button:
Since the ‘Paid By Player’ fields are different for Player-3 (3) and Player-4 (4), this will generate two separate POS Tickets when transferred over to POS.
So, hitting the ‘Transfer to Point-of-Sale’ button get us Player-3’s Ticket:
As a side concept, notice that the Price of the GreenFee is $42.00 and yet the Total of the Ticket is $38.79 – which is because this Customer gets an automatic Discount… which can be revealed by hitting the ‘Totals’ button:
Now we settle the Ticket to Cash:
This completes Player-3’s Ticket.
But now, since Player-4’s Ticket was also generated, the System next shows us Player-4’s Ticket:
We hit the ‘Payment’ button and then select Tender Type: Personal Check
Complete the Payment sequence as appropriate:
Since both TeeTime-spawned Tickets (for Player-3 and Player-4) have now been handled, the System returns to the TeeTime Booking Screen…. where we can now notice that all four Players in the TeeTime are ‘green’ (Paid):
Likewise, recalling the TeeTime in Reservation-Detail Mode shows also that all four Players are ‘Paid’… and even gives the POS Ticket No’s (and POS Clerk, Date, and Time):
Reporting –
You might want to see Who is playing and how much they are Paying and if they are doing 9-Holes or 18-Holes. This can be done with the PLU-SKU Item Sales Report.
The Names and TeeTimes are in the Item Descriptions. The Amounts are displayed.
If you use different Item Codes for 9-Holes vs. 18-Holes, they would be separately visible as well. The Report can be printed to the Screen to be used as an Inquiry.
Note: the example below uses a different TeeTime Date sampling.
Note that the TeeTimes Data Analyzer DataCube would give an even more flexible means of viewing TeeTime Activity.
TeeTime Client Search -
The TeeTime Client Search defaults to ‘Match-With’ for a specific reason: “Start-With” with an ‘A’ entered basically would return the entire Client file of names… and would impact performance for this Workstation and others.
Alternatively, you could use the Walk-In Client Routine’s “Search” in place of the normal Search… which is incremental by Last-Name (as described above). Below is and example of how Client-ID “2” has been set up to be a Walk-In Guest: Notice the Client-Style in the lower-left of the Info Tab:
Also notice how the Player-Class can be set to default to something appropriate (on the Personal Tab):
