Meeting Notes 17.9.

1. POS / EPOS – Product and Category Structure

The main focus of the meeting was to review the functionality and logic of the WisePlatform POS solution and compare it with Fulwell’s current till system.

In WisePlatform, it is possible to:

  • create different POS layouts for different tills
  • divide products into categories, such as Food, Drinks, Pro Shop and Golf
  • define which products are visible on each till
  • use colours to make products easier to identify visually
  • create variants for products, each of which can have its own price
  • report sales of individual variants separately.

In Fulwell’s current system, products are organised in a more hierarchical structure. For example:

  • Bar → Draft Beers → Carlsberg → Pint / Half Pint / Shandy
  • Catering → Breakfast → Full English Breakfast → Bread type / Egg type / Extras

From Fulwell’s perspective, this type of structure is particularly important for the staff user experience.

For WisePlatform, this means that variants should either work on two different levels or, for example, draught beers could be defined as one product group, after which the user selects the brand and pint size.

In Fulwell’s current till system, different product options are not necessarily separate products. Instead, they are handled as options / modifiers.

For example:

  • Full English Breakfast → White / Brown bread
  • Full English Breakfast → Fried / Scrambled / Poached egg
  • Burger → Extra cheese / No tomato / No mayonnaise

The goal is to avoid staff having to browse through a very large number of individual products at the till.

Scott presented an example of a system where:

  • Extra is a chargeable additional option
  • Modifier is generally a free option
  • options only become visible after the main product has been selected.

It was agreed that this corresponds well with Fulwell’s current way of working.

Next step

Scott will provide Miikka with a more detailed example / process showing step by step how this works in the current IG system.

Miikka will discuss with the WiseNetwork development team how the current POS development takes this requirement into account and whether the hierarchy of products and options can be developed to better support Fulwell’s use case.


2. POS Staff User Experience

Fulwell emphasised that the most important aspect of the POS is not only the management of products and reporting in the background, but also the user experience for till staff.

Compared with the current system, WisePlatform’s current interface was considered potentially too complex in situations where there are a large number of products and options.

Especially in a busy bar or restaurant, staff should be able to place an order quickly and without the risk of selecting the wrong product.

Scott noted that the POS should provide the user with a clear process that guides them towards selecting the correct product and options.

Next step

Where possible, Fulwell will provide additional material / videos showing how the current till is used, so that WiseNetwork can compare the current user experience with the WisePlatform solution.


3. CRM Integration and Customer Identification

The WisePlatform POS is connected to the CRM.

A customer can be:

  • searched for by name in the CRM
  • identified using the QR code in the WiseGolf mobile application
  • viewed together with their CRM information at the till.

The following information can be viewed in connection with the customer, for example:

  • access / booking rights
  • outstanding invoices
  • orders
  • golf bookings
  • tags
  • roles.

¨In the mobile application, the player can open their personal QR code, which can then be scanned at the till.

A separate scanner can be used to scan the QR code, meaning that staff do not have to search for the customer manually.

The customer’s profile picture can also be displayed together with the CRM information, which may help staff identify the customer.


4. Tee Sheet → POS → Payments

The integration between the tee sheet and POS was reviewed.

If a player makes a booking and selects pay on site as the payment method, the booking appears in the POS as an unpaid booking.

At the till, staff can:

  • search for unpaid bookings for the current day
  • search for bookings based on, for example, tee time
  • view the players and their bookings
  • view products associated with the booking, such as a golf cart
  • change the product being charged if necessary
  • pay for players individually or use the Pay All function.

The price comes from the tee sheet, but the product can be changed at the till, for example when a player is entitled to a discounted green fee.

Examples of products:

  • Junior Green Fee
  • Junior Member Guest
  • Local Residents
  • Members Guest.

Payment methods can include, for example:

  • card
  • cash
  • gift card
  • MobilePay
  • invoice.

Payment methods can also be created and edited in the POS settings. For example, Bank Transfer can be added as a separate payment method.

Amex is a possible payment method, but its implementation depends on the club’s decision and the associated transaction costs.


5. Golf Societies / Events and Group Payments

Fulwell raised a specific requirement regarding payments for golf societies and other group events.

The current process is considered cumbersome because, for example, a society of 20 players requires staff to handle separately:

  • 20 green fee payments
  • meals
  • coffees
  • any other products.

Fulwell’s preferred model would be for the event to already be created in the system, with a payment link being sent to the organiser, for example.

The organiser could then pay for the entire event in one transaction instead of staff having to rebuild the event’s products at the till.

It was noted that this is partly a separate issue from the current POS functionality and requires further investigation.

Next step

The matter will be kept as a separate development area and revisited later in connection with events / Event Management.


6. Check-in and No-shows

The tee sheet check-in functionality was reviewed.

In WisePlatform, a player can check in:

  • at the club

  • in the mobile application

  • automatically when making a payment.

If a player checks in in advance but has not yet paid, the tee sheet will still show the booking as unpaid, but an icon indicating the check-in will be displayed.

At Fulwell, the check-in process is not currently carried out consistently, as players do not necessarily visit the Pro Shop to check in before their round.

WisePlatform can nevertheless be used to monitor, through reporting, players who make a large number of tee time bookings but do not check themselves in.

This makes it possible to monitor no-show behaviour and gives the club an opportunity to address situations where, for example, a player repeatedly books tee times but does not confirm them.


7. Tee Time Locking During the Booking Process

The meeting included a detailed discussion of what happens when several players attempt to book the same tee time simultaneously.

Fulwell considers it important that a tee time should become visible to other users as unavailable as quickly as possible during the booking process, so that users do not spend time attempting to book a time that has already been taken.

One option discussed was for the tee time to be displayed as:

Booking in progress

when another user is currently booking it.

At present, WisePlatform’s functionality does not fully correspond to the model preferred by Fulwell, and Miikka noted that the matter requires technical investigation.

The issue is particularly relevant when new tee times are released and a large number of players attempt to book the same time simultaneously.

Next steps

Miikka will investigate:

  • how the tee time is currently locked during the booking process
  • what happens when a user exits the booking process
  • how long the booking remains locked
  • whether the locking period can be configured on a club-by-club basis
  • how simultaneous booking attempts are handled.

In the current checkout process, 20 minutes are available for payment, but it has not yet been confirmed whether this period can be configured on a club-by-club basis.


8. Anonymous Players

The meeting also covered so-called anonymous bookings.

Fulwell currently has processes where a player can initially reserve a place and add playing partners later.

According to Scott, this is partly related to the club’s own operating culture. For example, a player may reserve several places and then try to find playing partners afterwards.

However, Fulwell wants to monitor this type of activity and ensure that one player cannot reserve an unnecessarily large number of tee times at the expense of other players.

This is also related to no-show and booking history.


9. Need for Test Data

Fulwell highlighted an important requirement: the demo and test environment should contain significantly more data.

At present, it is possible to establish that features work, but practical testing and reviewing reports is difficult because the system does not contain enough real-world-like data.

For example, a report showing:

How many times has Scott Patience played on Mondays after 2 pm?

is difficult to evaluate without sufficient test data.

Proposal

Miikka could create test users in the system and add:

  • memberships
  • bookings
  • payments
  • product purchases
  • invoices
  • other activities.

Reports could then be used with realistic data rather than simply demonstrating that a particular report "can be created".

This was considered an important next step for properly testing the system.


10. Next Meetings and Event Management Demo

The next meeting is intended to continue with a particular focus on:

  • events / Event Management
  • Tournament functionality
  • potentially a demonstration of scorecards
  • reviewing features that were left unfinished during previous demos.

Miikka mentioned that he already has visual demos of the tournament and scorecard functionalities in the WiseGolf mobile application.


11. October Workshop at Fulwell

The possibility of Miikka visiting Fulwell for a longer workshop was discussed.

12 October 2026 (Monday) was agreed as the preliminary workshop date.

Tuesday, 13 October, is a possible alternative / additional day if required.

The objectives of the workshop would be to:

  • go through the system in a practical way
  • test processes from Fulwell’s perspective
  • review open questions
  • discuss the system with staff
  • plan the implementation and operating processes.

Murray has audit-related tasks during the same week, so the exact schedule for his participation will be confirmed later.

Fulwell has provisionally reserved a room for the workshop.

Scott and Miikka will plan the detailed content and schedule later.


Summary

The key finding from the meeting was that the basic logic of WisePlatform’s POS supports the products, variants and payment methods required by Fulwell, but the current user interface structure does not yet fully correspond to the way Fulwell’s current till system handles product options.

In particular, further investigation is required regarding the modifier / option structure, the staff user experience and multi-level navigation between products and options.

For the tee sheet, the main areas requiring further investigation are handling simultaneous bookings, tee time locking, booking timeout and monitoring no-shows.

In addition, the test environment needs more data so that Fulwell can evaluate reporting and the practical operation of the system using realistic examples.

In the next meetings, the focus will gradually move beyond POS towards Event Management, tournaments and practical system testing.