RTP - Programs - Selling & Config

In order to have your multi-week programs work to the their best in flaik, it's important to follow these steps in RTP for setting up and selling these products.

Sales Process

Overview

• Minimum Requirement: in order for a lesson product to sync from your POS to flaik, the product date must fall between the Season Start Date and Season End Date fields as set in flaik.

• To confirm the season dates used in flaik, go to Settings > General Settings > Season Dates.

• More information about season dates configuration.

• Best Practice: the product date in RTP should be set to match the first program date.

• Whichever date is used, the participants will appear in flaik in Scheduling on that date (if the date is in the season date range from above). Examples:

  • A program starting Jan. 8th is sold for Jan. 1st, all the program participants will appear in Scheduling on Jan. 1st plus all dates added to the flaik task. This will result in a large quantity of participants appearing on a non-lesson day, something to strive to avoid have happen.

  • A program starting Jan. 8th is sold for April of the previous season. As this is outside the season dates set in flaik, these lesson participants won’t sync into flaik.

• As a result, it is best to sell the product in RTP for the program start date.

  • Additionally, as a general best practice it is also best to have the product date match the inventory date.

  • As a result, the RTP product date/inventory date/first lesson program date should all align.

Product Configuration

Inventory Pool

Best Practice: set the inventory pool date for the first day of the program.

• Adding an inventory pool is highly recommended. Not only does it provide the opportunity to cap sales at a certain level to prevent overselling, but it also:

  • Aids with managing staffing and scheduling needs, by preventing more programs to be sold than there are staff available for.

  • Allows for the use of RTP Inventory reports if needed.

  • Allows products to appear in the product menu for ‘today’ but to sell for the first program day (if the client rule ’Inventory Pool and Product Dates Can Differ’ is set to No, and depending on how the pricing seasons are configured) (contact us if you have any questions about this).

Deferral Calendar

Using a deferral calendar allows for the revenue to align with the program days so that wages and revenue can match up.

• We recommend either creating new deferral calendars each year or at the very least alternating deferral calendars so that they’re used every other year (eg creating ‘even’ and ‘odd’ deferral calendar years - eg the ‘even’ deferral calendar could have been used in 23-24 and then reused for 25-26, 27-28, etc, while the ‘odd’ deferral calendar used for 24-25 could be reused for 26-27, etc.)

• The deferral calendar attached to a component shouldn’t be changed once the component has been sold. Therefore, if you’re creating new deferral calendars each year, new ‘revenue’ components should be created annually too. If you’re alternating deferral calendars each year (eg going with even and odd deferral calendars), there should be even and odd revenue components too.

• Essentially - every time there’s a new deferral calendar, there should be a new revenue component

• We recommend against using the same deferral calendar year after year for a few reasons:

  • If next year’s products are being configured while the current year’s program is occurring, changing the dates on the deferral calendar can cause issues. eg configuring next winter’s programs in late March or April while this year still has dates remaining.

  • There have been a variety of issues reported over the years where the deferral calendar dates were adjusted before all products were fulfilled or other random timing events causing issues on the finance side. Although rare, they are problematic enough that it’s worth avoiding them.

Components

As web platforms can struggle with handling an inventory pool for multiple but non-consecutive days (and even RTP can struggle in this regard depending on the duration of the program), it’s best to separate out the revenue and inventory responsibilities into separate components: one component to handle the revenue portion while the other handles the inventory portion.

	Inventory Component	Revenue Component
Units	1	units = the number of program days
Deferral Calendar	no	yes
Report Revenue	no	yes
Inventory Pool	yes	no
Statistic	no	yes
Can be reused each year	yes	depends - see Deferral Calendar section above

Product Header

The most important factor in determining how many product headers from programs will be required is the number of tasks that will be needed in flaik and mapping the RTP products to the flaik tasks.

• Create a unique product header for each unique set of start dates.

  • eg if you have a 6 week program starting in January and another starting in late February, they each need to be separate product headers for mapping purposes.

• Attach the inventory and revenue components from above plus any other components that are needed (eg waiver, lift access, food, etc)

• Price Type:

  • Can use either Season or Date Range, but Season is recommended.

    • Leads to less data entry errors (from typo’ing a date range on one component compared to other components or products)

    • Is easier to update if your resort decides to extend pricing (eg marketing decides to extend early bird pricing for a few extra days)

  • Needs to include the date used in the inventory pool (eg if the program starts Jan. 8th and the inventory pool is also set for Jan. 8th, the pricing season needs to include Jan. 8th)

• Price Date Type

  • Product Date

    • Generally best - better able to handle late sales, fixing sales, etc

    • If there are multiple pricing tiers (eg early bird, regular), this will need to be taken into consideration - there are a few options for how best to handle this.

  • Sale Date

    • Generally not recommended due to challenges it can present.

    • Handles multiple pricing tiers (eg early bird, regular) well, but can be challenging to sell the products after the program starts (eg late registration, moving people from one program to another) or to use earlier pricing tiers after the fact

Ability Levels

Resorts often want to use a different ability level scale for programs, but it's important to remember that the levels need to be able to map to your existing ability level scale in order for Class Management, Report Cards, and other functionality to work.

Additional Information

Check out the main Knowledge Base article on multi-week programs to see more details on what configuration is required in flaik.