Rate loading Process

1. Each hotel with a consortia rate must complete the RFP through the BTP tool.

2. This triggers the BTP team to send our GDS rate load form.

3. Once the hotel loads the rates, the BTP team will test.

   1. BTP only audits monthly, for urgent testing Stacie will create Jira ticket for Ops team to test the consortia rate.

      1. If we test and it fails, inform BTP of failure

   2. When tested unsuccessfully, the BTP team will follow up with the hotel.

      1. Stacie will monitor the BTP monthly audit report of all rate loads that are not successful and will follow up with her hotel contacts.

4. All successfully tested rates will automatically be visible for booking through the GDS as well as online booking tools for clients.

**(TP+ only) GDS and OBT have already been Pre-loaded with "Andavo" rate code that we use for all our consortia rates

Not going to store these contracts in AirPortal, goal is to get a "consortia" client in Andavo where we could load all the consortia contracts into.

1. Each hotel with a negotiated rate must complete the RFP through the BTP tool.

2. That will automatically trigger the BTP team to send their GDS rate load form.

3. Once the hotel loads the rates, the BTP team will test.

   1. When tested unsuccessfully, the BTP team will follow up with the hotel.

      1. Stacie will monitor the BTP monthly audit report of all rate loads that are not successful and will follow up with her hotel contacts.

      2. Stacie will notify the Account Management team and/or client of unsuccessful rate loads.

4. Stacie updates the client’s vendor hotel contracts in AirPortal immediately once the contract is agreed upon (before the rate has been validated in BTP) for each completed RFP.

5. When saved in AirPortal a Jira ticket is created for Operations & then to pass onto Online Support to load the new contracts into the GDS and OBT.

6. All successfully tested rates will then be visible for booking through the GDS as well as online booking tools for clients.

 **In andavo we could key off "BTP" flag in the client to know to delay the Jira ticket creation a week after contract is created?

1. The Account Executive team will send each client our newly updated GDS rate loading instructions which include a link to a required form.

2. The clients will send "rate loading instructions" to the hotels they have contracts with.

3. Hotels will then need to load the rates in the GDS

4. Hotel needs to then fill out the SmartSheet form found in the GDS rate loading instructions.

5. Smartsheet emails the Account Executive with all the information from the smartsheet form.

6. Account Executive will communicate with client informing we received the new contract and confirming whether or not it should be "Most preferred"

7. Account Executive adds the contract to airportal which creates the Jira ticket

8. The GDS team will test the rates according to the details provided on the ticket.

9. The Account Executive team will receive updates as they are tested.

   1. When tested unsuccessfully, the ticket will then be assigned to the Account Management team.

      1. They will connect with the client and provide them the unsuccessful rate load testing details and request they be notified when redone.

      2. The Account Management Team will update the ticket notifying the GDS team when it’s time to re-test the rates.

10. When tested successfully they will load the rates into the GDS and pass the ticket onto Online Support

11. Online Support will add the new contract into the OBT.

*For clients with 3rd party Contract negotiation tools, or other contracts, the AE can still get those contracts from those clients and add them into airportal the same way they always have.