Setup Checklist
This section is a comprehensive and high level summary of all tasks and prerequisites required for this feature to function properly. This section is purposed for use after an administrator is familiar with configuring this feature as an “audit” checklist. For detailed set-up instructions, jump down to “Prerequisite Tasks” and “Detailed Setup Guide” and then follow up with this checklist to ensure all steps are completed.
1. General Tasks | |
|---|---|
| PREREQUISITE |
2. POS Tasks | |
| PREREQUISITE |
3. Infrastructure Tasks | |
| PREREQUISITE |
4. Detailed Setup Guide | |
| DETAILED SETUP |
Prerequisite Tasks
This section describes all requirements that must be completed before you can begin setting up this feature. Once these tasks are complete continue to the next section.
General Tasks
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 (e.g. http://arrival.yourresort.com/home ). Other (non-default) Locations are accessed by navigating to directories within your Resort’s Arrival URL (e.g. 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 that has not yet signed waivers 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 expedited 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:
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.
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.)
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.
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, create a single activity configured with many tasks and map it to the online location (i.e. POS Transactions Location). In this flow, 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 determine which tasks a guests needs to complete based on standard RTP|One product component configuration. 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 Detailed 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 Test and Production databases to query orders and transactions and enable Arrival reporting to function:
AW_proc_publicGetArrivalsChildRegistrationValidationByIPCode
AW_proc_publicGetArrivalsImageAndPrintableMediaByIPCode
AW_proc_publicGetArrivalsRentalProfileValidationByIPCode
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.
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.
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).
Ensure waivers are added to product components. Record the waiver ID and work with your Aspenware Representative to add it to the planning document.
IMPORTANT: Waiver dates across Commerce, Arrival, and RTP|One waiver configuration MUST align perfectly to avoid discrepancies around who is in the email export and who has tasks loaded in Arrival. If a guest is emailed that they have tasks to complete, they should also have tasks loaded in Arrival, so this alignment is imperative. The waiver expiration date in Commerce, RTP|One, and Arrival need to match, and then the validation date in Arrival and on RTP|One waiver setup also needs to match.
If they do not match, it could result in people being emailed that they have a waiver to complete in Arrival when it has actually already been completed. For example, if people who bought their season pass online have signed a waiver set to expire 6/15/22 (the expiration date for the season pass waiver in Commerce), but the Arrival report export calls the validation date on the Waiver configuration for to season pass waiver in RTP|One that is set to 10/31/22, everyone who had a waiver signed in the pass purchase flow in Commerce this year valid through 6/15/22 would be returned in the Arrival export showing as needing a signed waiver. Alignment is imperative.
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.
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.
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
The following steps will need to be completed in Arrival Administration. To access Arrival Administration, simply go to <arrival.yourresort.com>/admin. If you do not have Admin access, contact your Aspenware Representative to be setup as an admin
Set Up Task Type
Set Up Tasks
Set Up Activities
Set Up Locations
Update Language Strings
Update Theme
Set Up Admin Users (Optional)
Configure Export List of Eligible Customers for Email (Optional)
Configure Report for Missing Profile (Optional)
Configure API Tab
Ensure Arrival QR Codes Are Aligned With Pick up Box Approach
Configure Collections Tab
Set Up Custom Analytics (Optional)
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, and photo upload) 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.
NOTE: The Effective Days setting for the waiver task type under task types in admin isn’t used and should not be configured. Logic for whether a waiver shows to a guest within Arrival uses effective and expiration dates of Authorization profiles on the guest’s profile and the validation date (more details below on this setting below) to key off whether a waiver is required.
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:
Name: This is the task name that will display to guests on the site.
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.
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.
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.
Task Type: Choose from the four available task types (Waiver, Rental Profile, Photo, Child Registration)
If Task Type= Waiver, enter the following:
POS Waiver ID: Enter the corresponding authorization code from RTP|One.
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.
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.
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.
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.
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.
Start Effective Date: This sets the start effective date for the waiver in RTP|One. The date the signed waiver is effective from.
IMPORTANT: Ensure there is not a mismatch of Start Effective Date configuration across Arrival, RTP|One Authorization configuration, and Commerce waiver configuration.
End Effective Date: This sets the end effective date for the waiver in RTP|One. The date the signed waiver is effective until.
IMPORTANT: Ensure there is not a mismatch of End Effective Date configuration across Arrival, RTP|One Authorization configuration, and Commerce waiver configuration.
Validation Date: This date is used to determine validity.
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.
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.
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.
This field should be left blank if you toggle “One Day Waiver” on. Often resorts will set the validation date as the same as the "end effective date" for season long waivers.
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.
Signer validation: At least one of the following must be configured, but can more than one or all can be set.
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.
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.
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.
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.
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.
Select UPDATE TASK when complete.
3. Set Up Activities
Once Tasks are set up, Activities are used to assign one or more Tasks to an Activity.
Create a New Activity
Navigate to the Activities tab in Arrival Admin.
To create a new activity, do not check any of the existing Activities in the list and configure a new activity by adding the following fields in the Add New Activity area:
Name: The name input here will be displayed to guests so they know which activity they are completing.
Age Min: (Optional) Adding a minimum age restricts which guests can be selected to check in for this specific Activity. If a guest is younger than the specified age, then they cannot be selected on the Activity page and will be unable to complete any Tasks associated with the Activity.
Age Max: (Optional) Adding a maximum age restricts which guests can be selected to check in for this specific Activity. If a guest is older than the specified age, then they cannot be selected on the Activity page and will be unable to complete any Tasks associated with the Activity.
Image Url: The URL for the image that will appear on the Activity page in conjunction with the Activity. Recommended dimensions are at least 1400x900 but must be under 270KB in file size.
Click the ADD ACTIVITY and scroll up to the Activity List to find the newly created Activity to edit/add Tasks.
Add Tasks to a New Activity
Go to the Activities tab in Arrival Admin.
In the Activities List section, click the checkbox next to the desired Activity.
Scroll down to the Link Tasks section.
Choose a Task: Click here and select a Task to add to this Activity.
Click LINK TASK to add the selected task to the Activity.
Multiple tasks can be added via the steps above, or a task can be removed here by clicking the red trash can icon next to the task.
IMPORTANT: If you are creating an activity that will be added to a transaction-based location, ensure that all the tasks you would like to prompt guests to complete in Arrival based on their transactions are added to the Activity. Though there may be many tasks configured within the activity, guests going through the transaction-based flow would only be prompted to fill out specific tasks that they are personally missing based on their orders in RTP|One.
4. Set Up Location(s)
Once you have completed Task and Activity configuration, you are ready to configure Locations.
Go to the Locations tab in Arrival Admin.
To create a new location, do not check any of the existing locations in the list and configure a new location by adding the following fields in the Add New Location area:
Location Name: This name will display to guests on the site. This name will also be included in the directory within the URL. A '-' will substitute any space in the location name. (e.g. If the location name is Ski School the url will be http://arrival.yourresort.com/ski-school )
Description: This is used for internal organization. This description will not display to guests.
Is Enabled: This is equivalent to “publishing” the location. When selected, guests will be able to navigate to the Location URL.
Is Default: When selected, this location will be your default location.
IMPORTANT: Only one Location can be configured as the default Location. This is the location that will be loaded for /home.
Is Edit Profile Location: When this is selected, this Location will be your “Edit Profile” location. This Location is designed to allow guests to update tasks they have already completed. For example, you can configure rental profiles and child registration tasks at this Location to allow guests to update these profiles even after they have valid profiles. Guests will have the option to navigate to this “Edit Profile” Location after completing check-in from a Location using the POS transaction-driven configuration.
NOTE: This configuration is optional for your resort. A max of one Location can be configured as the Edit Profile location. On the POS location URL, the edit profile button will only appear once all “POS” tasks displayed have been completed for all family members.
Use POS Transactions (RTP): When this is selected, this Location will function based on RTP|One orders and transactions, driving tasks off of incomplete steps for orders for the household in RTP|One. If unselected, this Location will follow the location-driven configuration outlined in the Locations Overview section of this document above.
Check in Complete Text: This is the messaging the guest will see once the guest has completed all required steps for this Location.
NOTE: HTML is supported, but should be limited to the standard text where possible (H1, H2, H3, P, UL, LI). While image tags are supported, special precautions should be taken to avoid breaking the responsive nature of the site across devices.
Default Activity: The default activity is the activity used to create check-in tasks for this particular Location. For a POS transaction location, only tasks that are added to this default activity will be presented to the user, even if RTP|One is indicating that additional info is required. For example: If RTP|One is indicating that the guest requires waiver #999 but that waiver is not created as a task and assigned to the default activity, the user will not be asked to sign the waiver in Arrival.
POS Transaction (transaction-driven) Location: Only the default activity is used for check-in at this time. In a future version, additional linked activities can be used to generate tasks and the order of assigned activities does not matter. Regardless, one must be selected as default for Arrival to function properly.
Non-POS (location-driven) Location: Only the default activity is used for check-in at this time. All other linked activities are ignored. In the future, all Locations will offer guests the ability to check in for one or more activities.
Assign Activities: The default activity must also be assigned to the Location.
Select your Location and in the column on the right, select the drop-down under Link Activities.
Select the Activity to assign to the Location.
Click LINK ACTIVITY.
Future versions of Arrival will support multiple Activities per location.
Once complete, select UPDATE LOCATION.
Once a Location is added, select the checkbox next to the desired Location to view and/or edit the Location.
5. Update Language Strings
All sitewide language strings are configured under the Language Settings tab. Language settings are grouped by page they display on.
Application Header: This text displays after login on the left side of the page on desktop screens and as the footer on mobile devices.
Home Page: This is the page that will display upon login. Enter desired text.
Rental Profile Page: If a guest needs to fill out a rental profile, this information helps them identify their ability level.
Welcome Page: This is the page that displays before you log in. Enter desired text.
Check In: This is the page that displays after guests complete tasks. Enter desired text.
Pass Checker: The page that displays if a guest selects Pass Checker to identify whether or not their media is valid for particular dates. For more information on Pass Checker, see https://hub.aspenware.net/main/Configuration:-Pass-Checker.1502838928.html
BLE Connect: This is only used for resorts that have BLE scanning activated at their resort.
6. Update Theme
All sitewide theme settings are configured under the Theme Settings tab.
General
Logo URL: Add a URL to the image you’d like to display on the welcome screen. Typically this is an image of your resort’s logo. Image recommendation is 256 pixels wide. The height can vary based on the standard proportion of your logo. SVG file types are preferred, but PNG works as well.
Welcome Page Logo Width: This is used to adjust the size of your logo image.
Favicon Image URL: Add URL to the Favicon logo you would like to use.
Background Image: Add a URL to the image you’d like to display as your background image. Image recommendation is 1920x1080 pixels and 270 KB.
Overlay Welcome Background with dark gradient: This allows a gradient overlay on the background. Choose between dark, light, or none.
Show Application Title as Image: Select this to display an image as your application title. If this is deselected, the Title language string under Application Header will display.
Application Title Image URL: Add a URL to the image you’d like to display as your application title. This will only display if the Show Application Title as Image setting is selected. Can be used if your resort has a branding image for Arrival.
Welcome page Arrival Title Width: This is used to adjust the size of your Title image.
Fonts
Primary Font Color: Update the color of the font that is used on the site.
Primary Font Weight: Update the weight of the font used on the site.
Buttons
Primary Button Background color: Update the color used on primary buttons.
Primary Button Text Color: Update the color of the primary button text.
Secondary Button Background color: Update color used on secondary buttons.
Secondary Button Text Color: Update the color of the secondary button text.
Footer
Background Color: Update the background color of the footer. Can be entered using RGB, HSL, or HEX values.
Footer Background Image: Add a URL to the image you’d like to display in the footer.
Background Opacity: Change the opacity of the footer gradient overlay.
Border Color: Update the color of the border used in the footer.
Text Color: Update the color of the font used in the footer.
Media Card
Sidebar: If a guest is on desktop view, the sidebar appears and can be configured with a background image or just a color.
Background Color: If using an image do not set a color.
Background URL: This is the background image on the application sidebar.
Background Opacity: If using a Background image, set the opacity on the application sidebar so that text can appear as legible.
7. Set Up Admin Users (Optional)
Arrival gives you the option to grant individual email accounts Admin rights, or an entire email domain. The email used to sign in by the user will determine whether they have admin rights or not.
To add a single email, enter the full email address of the desired user under Add New Email on the left side of the page.
To add an entire domain, enter the desired domain (everything after “@” in the email address) under Add New Domain on the right side of the page.
8. Update Arrival Settings
Go to the General Tab to set up Arrival site-wide settings. The following can be edited:
Display External Order ID as QR Code: This is used to display a QR code to the guest on the home page of any POS transaction location.
Deselecting this will set the RTP|One IP code as the QR code.
Selecting this will set the QR code on the arrival screen to the External Order ID. Presently this is required for resorts using SkiData.
NOTE: Guests who did not purchase through the online sales channel will not have a QR code to display as one does not exist.
Google analytics tag id: Input your GTM code here to track Arrival actions via GA. The ID must start with "GTM". While this GTM ID does need to be updated, you will also need to configure your Google Tag Manager environment to match the documented guidelines for how to set up tags, triggers, and variables to actually track data. https://hub.aspenware.net/main/Google-Analytics-for-Identity.2046918847.html
Resort codes: Optional. This can be entered to filter Arrival’s order/transaction search in RTP|One. This can be useful if RTP|One is shared amongst several resorts or if there is a need to filter out specific orders/transactions. The Value input is the RTP|One’s Business Unit (resort) settings.
Resort group codes: Optional for the same uses as resort codes. The Value input is RTP|One's Business Group.
Sales locations ids: Optional for the same uses as resort codes. The Value input is RTP|One's Location ID.
Pass Check POS Location Id: Refer to the https://hub.aspenware.net/main/Configuration:-Pass-Checker.1502838928.html for details on configuring Pass Checker in Arrival. This setting serves as a default lift or access point that passes will be validated against in the instance that additional “accesslocations” are not defined within the “Collections” admin area.
8. Configure Export List of Eligible Customers for Email (Optional)
Arrival offers the ability to generate a list of customers that are eligible to check-in on Arrival. This is designed to be able to be generated once daily at a planned time and can be used to generate email lists for external email and CRM systems to send notifications to guests, either via manual list uploads or through our API integration if your CRM supports the Arrival API integration.
NOTE: Aspenware will not be providing the capability to actually send these emails.
Generally, the overnight export will use the same logic as the Order and Transaction API described in the POS Tasks section above. If the guest has tasks to complete in Arrival, they will appear on this list. The API will provide a file of all the guests who have items to check-in and/or media to print. This file will be generated on a schedule overnight so as to reduce processing overhead when the API itself is called.
The core API parameters will be Days Before and Days After and an array of sale location codes (no IPCodes).
If the Days After is set to 5, meaning that guests should be checked in for products with a start date (product) up to 5 days in the future, this means they will appear on the export 5 days prior to their start date.
If a guest does not complete their arrival tasks 5 days prior to the start date, they will also appear on the export 4 days prior, 3 days prior, etc. until their tasks are completed. It will be up to the CRM/Email system to prevent sending emails to the same guest too often.
IMPORTANT: A guest with a non-date based product will be returned in the export if RTP|One needs that task completed and the Arrival POS Location has a matching task.
Because the list is pre-processed, any changes in the list that happen after it is generated will not be accounted for throughout the day. For example, if the file is generated at 5am and emails are sent out at 5:30am, it is possible that a guest’s tasks to complete or media to pick up may have changed either due to them completing those tasks or something changing in RTP|One like a transaction being returned.
9. Configure Reporting Tab (Optional)
The Reporting tab is used to export a csv or json file that generates guest information from RTP|One to be used for emailing guests with missing profile information needed prior to their activity start.
The data for this report is downloaded from RTP|One once daily at 5:00AM resort’s local time but the Aspenware Team can update this defaulted time upon request. You can see on the Reporting tab the last time the report was run.
Once downloaded the list can be used with your CRM to decide how and when to contact guests via email distribution. Continue reading below for details on what the configuration in the Reporting tab achieves. You’ll also find examples with descriptions of what is included in the standard report and details report.
Location: This dropdown displays all of your active POS Locations in Arrival. You can only select one Location at a time and when you download a report only guests with both an outstanding task in RTP|One and with a matching task assigned to this location will be included in the report.
Begin Date: Defines the starting date the report will generate information based on the start date of an order/transaction in RTP|One. A max of 5 months in the past can be selected.
End Date: Defines the ending date the report will generate information based on the start date of an order/transaction in RTP|One. Any date in the future can be selected.
NOTE: A guest with a non-date-based product will be returned here if RTP|One requires that task for completion and the Arrival POS Location has a matching task.
Include Printable media:
Selecting this will have the report include information for guests that have a printable media product purchased and has not yet been printed in RTP|One. Once logged in to Arrival, guests will see a QR code on their account that can be scanned at PUBs for printing.
Deselecting this will omit guests who only have outstanding printable media and will only generate information on guests who have outstanding tasks based on the POS Location and date range selected.
Includes Details: Deselecting this will generate a Standard Report and selecting this will generate a Detailed Report.
Standard Report: Attached below is an example of Arrival’s standard report with descriptions of the data each column is generating. It is recommended to use this report as the distribution list to send to customers. Displays the head of household’s contact details if the head of household or anyone in the household in RTP|One requires a task to be completed with a matching task at this Arrival Location.
Details Report: Attached below is an example of Arrival’s Details Report with descriptions of the data each column is generating. It is recommended to use this report for data validation and not as a distribution list to send to guests. Displays the head of household’s contact details AND the household participant’s details if the head of household or household in RTP|One requires a task to be completed with a matching task at this Arrival Location.
CSV Export: Selecting this will generate the report in CSV formatting. Deselecting this will generate the report in json formatting.
Test Customer Activities: This is primarily used as a validation tool, inputting a guest’s IP code from RTP|One will return information on their outstanding tasks in json formatting.
IMPORTANT: A guest with a non-date-based product will be returned in the export if RTP|One needs that task completed and the Arrival POS Location has a matching task).
10. Configure API Tab
Arrival’s API tab is used to export guest information from RTP|One to your CRM tool and the API is available to any CRM that develops the capability to call the data. Your CRM does not need to log in to Arrival as guest information is secured through an API key that can be provided to them. Once the CRM has access to the API, the CRM can configure specific parameters they call on; simply put: the CRM is able to import the guest information for the exact guests that should be emailed for Arrival tasks IF they have this specified. If they do not have anything specified when they make the API call, they receive Arrival’s default parameters; default parameters are set on Arrival’s API screen and described in this article section below.
NOTE: The data available through the API is obtained through the same method as the Reporting tab. It is downloaded from RTP|One once daily at 5:00AM resort’s local time but the Apenware Team can update this defaulted time upon request. Once downloaded, the list can be used with your CRM to decide how and when to contact guests via email distribution.
API Access Keys: In order for a CRM to obtain guest information, you must provide them with an API key from this list. Copy and paste existing API keys to share with your CRM(s). If you click the red trash can icon, this will delete an existing API and would break any established connections your CRM has through that key.
Create API Token: This generates a unique API key to call the data Arrival has obtained from RTP|One. You can create multiple API keys if you need to share with multiple systems and want to keep the keys unique. To create an API Key:
Click CREATE API TOKEN.
Input a Token Nickname: ie: {CRM Name}
Click CREATE TOKEN.
API Default Settings: This is the defaulted information a CRM will obtain when they call the API IF the CRM has not specified specific parameters. The two sections here function the same as the Reporting Tab’s “Begin Date” and “End Date”.
Days Before Current Day: Defines the starting date the report will generate information based on the start date (product date) of an order/transaction in RTP|One. A max of 5 months in the past can be selected.
Days After Current Day: Defines the ending date the report will generate information based on the start date (product) of an order/transaction in RTP|One. Any date in the future can be selected.
IMPORTANT: A guest with a non-date-based product will be returned in the results if RTP|One needs that task completed and the Arrival POS Location has a matching task.
After you have updated these two fields click UPDATE DEFAULT SETTINGS and if your CRM has not specified these parameters, the next time they call on Arrival’s API they will receive guest information based on this date range.
Available API Endpoints & Documentation: This section describes information on how to call the API and the parameters that can be specified.
11. Ensure Arrival QR Codes Are Aligned With Pick up Box Approach
QR codes will be displayed in Arrival for guests to use to pick up media at either an Axess PUB or Skidata Skiosk. Printing media requires that line items are auto-fulfilled. Open Order lines cannot be printed on either device.
Axess PUB Approach:
Arrival will display a QR Code of each family member’s IPCodes, which will be able to be scanned at the PUB for pass media pickup. Only family members with pass media to pickup will be displayed in Arrival.
QR Codes will only display if:
Pass Media is in an RTP|One Sales Transaction (either directly or as part of auto-fulfilled order line);
The media Product Header in RTP|One has “Pickup on PUB” rule added;
Pass Media is not returned;
Guest has an image - only if it is required by the Pass Media;
Guest has completed all required waivers associated to the transaction line; and
Pass Media has not already been printed.
Skidata Skiosk Approach:
Arrival will display QR Codes of RTP|One External Order IDs that are associated with family members who have media to pick up. (Skiosk does not support IPCodes or any other RTP|One values.)
This will print any media in the order (even if for members outside of the family).
QRCodes will only display if:
Pass Media is in an RTP|One Sales Transaction (must be fulfilled or auto-fulfilled from an Order with an External Order ID);
Product Header in RTP|One has “Pickup on Skiosk” rule added;
Pass Media is not returned;
Guest has an image - only if it is required by the Pass Media;
Guest has completed all required waivers associated to the transaction line; and
Pass Media has not already been printed.
12. Configure Collections Tab
This is leveraged with the Arrival Pass Checker Functionality and is fully detailed in the Pass Checker Configuration guide.
13. Set Up Custom Analytics (Optional)
A series of customer events are triggered when a guest takes an action. Each action is registered as single arrival_event and split out according to the task performed. This enables a record of each action taken by a user allowing the resort to collect and analyze information. Custom events show resorts exactly how many times an event was performed on the application providing powerful data that can be leveraged to best serve your customers and improve the user experience. Data can be seen via Google Analytics (legacy or the latest version 4). See a list of custom events and a snapshot of an example Google Analytics dashboard below. For more information visit the
Custom Events
add family member
sign waiver
child registration
rental profile
add photo
check-in complete (includes every step taken and when a guest has arrived at check-in complete page)
edit profile (independent of purchases)
Like this page? Click the like button below. Don't like this page and/or want to give feedback about this page, leave a comment below and Aspenware will address to improve this article.