Page Comparison

Setup Checklist

...

POS Tasks

• POS Task that must be completed first

Infrastructure Tasks

• Infrastructure Task that must be completed first. Remove section if not required

Commerce Tasks

• AW Commerce task that must be completed first

Settings, Language Strings and/or HTML Widgets for this Feature

...

Settings

• AW Commerce Settings that must first be completed

Language Strings

• AW Commerce Language Strings that must first be completed

HTML Widgets

• AW Commerce HTML Widgets that must first be completed

Detailed Setup Guide

1. Step 1 Header

2. Step 2 Header

1. Step 1 Header

• First bullet should provide navigation instructions i.e. Catalog >Attributes >Product attributes

  1. Sub-bullet for step 1. Every step and click should be detailed so that someone could follow with little prior experience.

     1. Sub-bullet for step a. Include screenshots of the step and use skitch to mark up screenshots. It can be downloaded here: https://www.techspot.com/downloads/5705-skitch.html

Expand
title Example of content within a section
From the Aspenware Commerce Plugins>Age Range page in Admin, click View Add Range Types in the upper right corner. Click Add Age Range Type. Enter a name and description for the age range type. To set the date used to compare the customer’s age to the required age range, select: Calculate from Trip Start (this age range type is likely already configured), or  Calculate from Today’s Date (age range based on purchase date), or Specify the Calculation Start Date; the customer’s age on this date will be used to determine if they are eligible for the product based on the age ranges Click Add. Age Range Types can be edited and inactivated, but they cannot be hard deleted without contacting Aspenware.  Age Range types that are set to Calculate from Trip Start or Today’s Date will never need to be edited, unless you would like to edit the name. Age Range Types that are calculated from a fixed date however, will need to be edited each year to adjust for the current year. Image Removed   Hint: Age Range Types should also be adjusted year over year. If age ranges are calculated based on Trip Start, then they will not need to be updated. Once completed for all required age range types move on to create Age Range.

2. Step 2 Header

• First bullet should provide navigation instructions i.e. Catalog >Attributes >Product attributes

  1. Sub-bullet for step 1

     1. Sub-bullet for step a

...

DELETE CONTENT AFTER THIS LINE

go to the Glossary page and add the key terms Excerpt Include that you added for your configuration guide.

How-to Guide of this page can be found here: [Internal] Configuration page Setup Guide

...

Determine Arrival Strategy

Work with your Aspenware Representative to determine how Arrival will best be structured to meet the needs of your resort. Consider the following components.

Locations Overview

Locations are used to determine which activities guests will be completing. All Arrival implementations must include ONE default location, which is the Location used when navigating directly to your Arrival URL (ex. http://arrival.yourresort.com/home ). Other (non-default) Locations are accessed by navigating to directories within your Resort’s Arrival URL (ex. http://arrival.yourresort.com/mss-youth ).

When configuring a location, there are two inherent flows that will be configured at the Location level, transaction and location-driven options.

• Transaction-Driven Configuration - Using the transaction-based configuration, you can proactively reach out to guests with upcoming itineraries, prompting them to check-in in advance with tasks they are missing. Guests will complete tasks specific to what they have ordered through purchases made through your Aspenware Commerce store, the call center, your lodging eCommerce, etc. For example, a family that pre-purchased Season Passes online would be emailed a link to Arrival prior to their trip. They can sign in, and upon entering Arrival, their orders are recognized and they are prompted with relevant tasks.

• Location-Driven Configuration - The second configuration option is to catch guests who are purchasing onsite or who didn’t complete the required information prior to arrival, prompting them to fill in the required profiles and waivers onsite and on their personal devices. Different Locations can have different configurations and tasks depending on the activities offered at that location, (e.g., ski school, rental shop, etc.). For this flow, resorts can post QR codes around the resort linking to the location’s Arrival link. All guests who pull up these Arrival Location links on their devices will fill out the information that is specific to the Location where the guest is physically located. While some steps may be skipped if a guest has a completed profile or waiver on their account, the steps delivered to the guests through these location-driven flows are not catered to steps for orders on their profile, but rather steps required for that Location.

Prior to Arrival setup, determine how the resort will be using Locations. Some questions to answer include:

• How many Locations will you have? Remember a Location doesn’t have to be a physical location - for example your transaction-driven flows could all be linked to a “purchases” location.

• Which Locations will be transaction vs location-driven?

• For location-driven setup, determine which steps will be offered and which steps will be required.

• Which guest types will you need to “follow up with” prior to them arriving on site or prior to fulfilling their product? Questions to ponder include:

  1. Do you need photos and or waivers to be updated prior to printing season passes? Use Arrival to capture photos for guests with missing information.

  2. Which of your booking systems can’t capture waivers, child registration, rental profiles, and photo? Consider how Arrival can be set up to capture this data prior to these guests' arrival. (e.g., Lodging guests that need to fill out waivers for their package ski products.)

  3. Are there steps you can remove from online check-out flows in favor of capturing this information in a pre-arrival flow instead? Making checkout faster and easier helps conversion rates.

  4. Do you want guests to “review” data they entered prior to their arrival? (e.g., Do they need to confirm their rental profile or child registration profile?)

• How far in advance of the product date do you want to follow up with guests to complete arrival information?

• What will be your default location? Although not required, Aspenware highly recommends your default location be set up with the transaction-driven configuration.

Activities Overview

Once a determination has been made about what the configurations will be and which Locations will be set up for Arrival, map activities to locations. For transaction-driven flows, map most activities to the online location (i.e. POS Transactions Location), but, again, tasks associated with that Activity will only be triggered if the guest has an order that requires those tasks be completed or confirmed and they are missing the information on their profile or a member of their household’s profile.

Tasks Overview

As part of determining Arrival configurations, your Aspenware Representative will work with you to define how the following tasks will be folded into your Arrival Strategy and mapped to your various Locations and Activities.

• Photo Upload

• Child Registration Profile

• Rental Profile

• Waivers

POS Tasks

• Arrival was developed to use standard RTP|One product component configuration to drive the POS transaction flows to determine which tasks a guest needs to complete. Aspenware developed a custom order and transaction query that searches RTP|One for upcoming orders and transactions associated with the guest's RTP|One customer record. Outstanding tasks that still need to be completed will be eligible for completion in Arrival. However, the guest can only complete these tasks if they navigate to an Arrival location that also has the task configured. See Arrival Administration Setup below for detailed steps to configure this in Arrival Admin. Work with your Aspenware representative in order to install these four custom stored procedures in your RTP|One and RTP|OneTEST databases. The following stored procedures must be created in both databases to query orders and transactions and enable Arrival reporting to function:

  1. AW_proc_publicGetArrivalsChildRegistrationValidationByIPCode

  2. AW_proc_publicGetArrivalsImageAndPrintableMediaByIPCode

  3. AW_proc_publicGetArrivalsRentalProfileValidationByIPCode

  4. AW_proc_publicGetCustomerAuthorizationValidationByIPCode

When determining which products will be utilizing Arrival, review your RTP|One waiver and product configuration.

• Ensure your fulfillment business rules align with the state the Arrival API expects orders to be in to drive various behavior.

  1. For orders to be in a state where they can be “checked-in” (i.e. to have guests complete waivers and profiles), they should be open order lines or transaction lines. Posted, canceled, and returned order lines will be omitted.

  2. For orders to be in a state where they can be “picked up” (i.e. a QR code is provided for printing access products), items must be auto-fulfilled or a transaction. Open order lines cannot be printed on either device (Ski Data or Axess PUBs).  

  3. Ensure waivers are added to product components. Record the waiver ID and work with your Aspenware Representative to add it to the planning document.

• Ensure a “Pickup on PUB” rule is created in RTP|One to allow media to print at PUBs. Ensure the “Pickup on PUB” rule is added to PHCs in RTP|One for which media can be printed at the PUB using the QR code presented in Arrival.

• Determine if you will require a photo for printing pass media.

  1. If photo is required before a guest can print their media, ensure pass media components OR product component rules are configured with the required image setting when needed.

  2. If photo is not required before a guest can print their media, then opt to use the rule on the product component rather than pass media rule. To configure this, you can make a product component rule in RTP|One admin where the rule name and keyword is "IMAGEREQUIRED" and add that to components where you want to require a photo when they're sold to the guest. This is used if you want to require a photo on a component that is not a pass media component, while on a pass media component you can just check the "Image Required" box.

• Ensure your product components require a Rental profile when needed. Aspenware requires that RTP|One configuration setup has a product component rule in RTP|One admin where the rule name and keyword is "RENTALPROFILEREQUIRED".

• Ensure your product components require a Child Registration profile when needed. Aspenware requires that RTP|One configuration setup has a product component rule in RTP|One admin where the rule name and keyword is "CHILDREGPROFILEREQUIRED".

Infrastructure Tasks

• Work with your Aspenware Representative to implement Identity and to create the Azure application services required for Arrival.

Detailed Arrival Setup Guide

1. Set Up Task Type

2. Set Up Tasks

1. Set Up Task Type

Arrival comes pre-configured with task types. However, you can determine the validity duration for each of the task types (child registration, rental profile, photo, etc.) You can configure how new (based on UpdateDate in RTP|One) a profile must be in order for Arrival to recognize that the task has already been completed.

• Navigate to Arrival Admin > Task Types.

• Select the task you’d like to update.

• Enter the Effective Days value. For example, if you set “Rental Profile” to 365 days, a guest will not have to complete a rental profile if they already have one that is less than 365 days old. They will be given the option to update their profile, if they wish.

...

2. Set Up Tasks

Start by configuring Tasks which will later be mapped to Activities. Activities will then be mapped to Locations.

• Navigate to the Tasks tab in Arrival Admin.

• To create a new task, do not check any of the existing tasks in the list and configure a new task by adding the following fields in the Add New Task area:

  1. Name:This is the task name that will display to guests on the site.

  2. Minimum Age: Optionally limit guests who should be prompted to complete this task based on their age. This defines the youngest age a guest could be to be prompted to complete this task if configured.

  3. Maximum Age: Optionally limit guests who should be prompted to complete this task based on their age. This defines the oldest age a guest could be to be prompted to complete this task if configured.

  4. Is Optional: Toggle FALSE to make this task required. For example, in an online location using the transaction-driven flow, you may want to set a task to optional since all guests may not be present when the head of household is checking in. For a physical location using the location-driven flow, you may want to set a task to required since all guests will need to complete the task prior to starting their activity.

  5. Task Type: Choose from the four available task types (Waiver, Rental Profile, Photo, Child Registration)

     1. If Task Type= Waiver, enter the following:

        1. POS Waiver ID: Enter the corresponding authorization code from RTP|One.

        2. Select to Consolidate Waiver: If activated, each required waiver will show in a consolidated view, so the logged-in user will be able to sign all waivers for all members in their family that require that specific waiver at one time.  If there are any waivers that are not eligible for consolidation, those waivers will be presented for each member to sign separately.

        3. One Day Waiver: If toggled on, this setting will always use the current date to determine validity. Arrival will check RTP|One for a corresponding authorization record. If one exists, Arrival will check if today’s date falls between the start and end effective dates of the waiver for that customer for that waiver in RTP|One. This setting should be used if the RTP|One product sets RTP waivers to be the product date as the start and end effective dates. This is a way to require a new waiver be signed for each product date. If used, validation date setup should match RTP|One authorization setup for the corresponding waiver.

           1. If outside of the date range, Arrival will determine the guest does not have a valid waiver, and prompt the guest to sign a new waiver.

           2. If inside the date range, Arrival will determine the guest does have a valid waiver, and will not prompt the guest to sign a new waiver.

           3. IMPORTANT: Ensure there is not a mis-match of Validation Date configuration across Arrival and RTP|One Authorization configuration. A mismatch could result in guests being emailed that they have a waiver to complete that they have already signed, or vice versa.

        4. Start Effective Date: This sets the start effective date for the waiver in RTP|One. The date the signed waiver is effective from.

           1. IMPORTANT: Ensure there is not a mismatch of Start Effective Date configuration across Arrival, RTP|One Authorization configuration, and Commerce waiver configuration.

        5. End Effective Date: This sets the end effective date for the waiver in RTP|One. The date the signed waiver is effective until.

           1. IMPORTANT: Ensure there is not a mismatch of End Effective Date configuration across Arrival, RTP|One Authorization configuration, and Commerce waiver configuration.

        6. Validation Date:  This date is used to determine validity.

           1. Arrival will check RTP|One for a corresponding authorization record. If one exists, Arrival will check if the Validation date set in Arrival falls between the start and end effective dates of the waiver for that customer for that waiver in RTP|One.

              1. If outside of the date range, Arrival will determine the guest does not have a valid waiver, and prompt the guest to sign a new waiver.

              2. If inside the date range, Arrival will determine the guest does have a valid waiver, and will not prompt the guest to sign a new waiver.

           2. This field should be left blank if you toggle “Use today as validation date” on. Often resorts will set the validation date as the same as the "end effective date" for season long waivers.

           3. IMPORTANT: Ensure there is not a mis-match of Validation Date configuration across Arrival and RTP|One Authorization configuration. A mismatch could result in guests being emailed that they have a waiver to complete that they have already signed, or vice versa. The arrival export, which determines the list of guests to email that have unsigned waivers to complete keys off the validation date setup on the waiver in RTP|One, while Arrival determines whether a waiver task is needed for a guest once they login to Arrival based on the validation date configured on the waiver task in Arrival.

        7. Signer validation: At least one of the following must be configured, but can more than one or all can be set.

           1. Enable Agree Checkbox: If checked, the guest will need to check to agree to the waiver and will be stored in RTP|One that the guest checked to agree to the waiver.

           2. Enable Text Signature: If checked, the guest will need to type the name of the signed-in user, and it will be stored in RTP|One that the guest typed X name to agree to the waiver.

           3. Enable Wet Signature: If checked, the guest can “ink” their signature, and the image of the signature will be stored in RTP|One. NOTE: This option requires RTP2016 or later.

        8. Custom Comment:This field gives an option to populate the comment box in RTP|One’s Authorization profile. Can be used with tokens {Signer}, {SignedDate}, {BrowserName}, {BrowserVersion} to provide who signed, on what date, with what browser, and what browser version.

        9. For waivers, the exact HTML that a guest sees through Arrival will be saved in the profile text in the authorization record in RTP|One.

        10. Validation and effective dates are only considered and used with location-driven configurations since these flows do not require products sold on guest accounts. For transaction-driven configurations, RTP|One waiver validation will be determined in RTP|One. If RTP|One determines a waiver is required, the Arrival setup must also include the same waiver configured with the corresponding authorization code and dates in order for guests to complete the waiver in Arrival.

• Select UPDATE TASK when complete.

...

...