Submitting a Website-Integration Request

The integrations team needs site access to be able to make changes to the clients site. The best option for gaining access is through a Site Contributor Invite, this allows integrators to become collaborators on the client’s site. A second option is to have the client provide their username and password.

Benefits of using site contributor invites rather than username / password :

• The client doesn’t have to share sensitive information and can control when and how much access they grant.
• Having invites come directly to integrators cuts out middle communication and allows us to check proper access.
• It removes the need for 2 factor authentication, which commonly stalls integrators ability to access sites.

In some cases, shared access is not an option. This can be due to limitations with the client’s CMS or technical difficulties. In these cases, the client is welcome to provide their username and password, although it should be the exception rather than the norm.

Steps on obtaining access through the two methods are listed below.

Site contributor invites

Each Content Management System has a slightly different process for granting shared access. This Helpdoc goes into the details on these processes and can be used to guide the client in ensuring the integrations team gets the correct access.

Sending Site Contributor Invites to FareHarbor

The general process for site contributor invites is as follows:

1. Provide the client the help doc with instructions on how to send a site contributor invite.
2. Using their Content Management System, the client sends a contributor invite to the integrator sitelogin email, sitelogin@fareharbor.com
3. The integrations team accepts the contributor invite and checks that it has the correct permissions.
4. The integrations team adds an entry to Keeper reflection accepted access.
5. Before submitting a request, submitters should ensure that integrators have received access and a Keeper entry has been created. If you are unsure if the client has sent an invite please use the Login Check workflow in #website-integrations.

Username and Password

All logins need to be transferred through Keeper regardless of the method of obtaining access. This ensures that we have are securely handling client’s website information.

If site contributor access has been sent, integrators will create a new Keeper entry.

If the client provides Username and password, you must create a Keeper entry. Please ensure the login is added to the appropriate Shared-Client Passwords folder. To add to a certain folder, you can select the appropriate Shared Client Folder and click the yellow plus button, or you can add the credentials to your vault, then right click → Move to → Select appropriate Shared Client Credential folder.

When creating a keeper entry, please adhere to the following:

• Title: Name of the client

• Login: Username

• Password: Password

• Website Address: Content Management System Login Page. This is where we should go to use the username and password.

If you can’t access your Keeper account or add items to the shared folder, please submit an IT ticket.

Checking that a login works

Before submitting a request, please make sure that the login is checked and is accurate either by you or an integrator. This includes instances using contributor access. We recommend you check this yourself, but because it can be hard to ensure permissions levels are right, it may be helpful to have an integrator check the login.

Options for checking web login:

Test Yourself: Follow the login URL, and enter the username and password to ensure it works. If you can see access to the site editor, it should be good to go, but it’s possible that the permissions could still be inadequate. If you aren’t sure, feel free to move to the following options.

Check the Login Checks AirTable: Found Here. This AirTable base is sent a new entry if the AE marks the login status as “Login not in Keeper”, “Login is in Keeper and needs checked”, or “Client has invited sitelogin@fareharbor.com” in the Dashboard Training Scheduled (for New Client) CA. Integrators check logins marked “Login is in Keeper and needs checked” on a daily basis. If login is inadequate, we will change the status and leave a comment in the client channel. Know that “Login not in Keeper” may be inaccurate if login has been obtained after the training request.

Check the client channel: If we have checked the login and see any issues, we will always tag the AE in the client channel. Checking for this correspondence can tell you if we were able to work out the correct login details.

Ask integrators using the “Login Check” workflow: If you have followed the previous steps and still aren’t sure, please use the #website-integrations workflow “Login Check” after login has been added to Keeper. We will gladly test it out and confirm access is sufficient.

For integrations Zendesk tickets, both the support agent and the integrator will have a copy of the ticket. When a ticket comes in for an integration adjustment, create a brand new ticket. On this new ticket, use the macro “Back End Ticket for Submitting Integration Requests” on an internal note and fill in all of the required information.

Make sure working login is in Keeper and that you include a link to the original ticket. The standard process for integration requests in Zendesk is still to gather username and password, but please feel free to use the site contributor method detailed above in cases of 2FA or other technical issues. If using site contributor method, ensure access has been received and added to Keeper before submitting a request.

Assign this new ticket with only the internal note to the integrations Zendesk group, and move the original ticket to your own pending queue.

After the integrator has completed the request, they will leave a note on the original ticket that it has been completed. They will then move the ticket from your pending queue to your open queue. Once you have received this note, you can follow up with the client and close out the ticket.

If the client responds with additional integration requests, create a new ticket, starting the process over.

If more information is needed by the integrator, they will leave an internal note on their ticket, moving it to pending. They will add a similar comment on your ticket, moving it to open status. You will then follow up with the client, and after getting the needed information, add that information to the integration ticket moving it to the open status.

To submit a request to the Integrations team visit this page and fill out the form. Website login should be in Keeper. If we do not have login, use the site contributor process detailed above before filling out the form. If site contributor access is not possible, request the username and password from the client and add it to Keeper.

For urgent requests, in addition to filling out the form, use the Integration Escalation flow in the Integrations room. This will ensure that the integrations team sees it quickly.

Integration team will ping you in the #integrations room when complete. Visit this page to view the current integrations queue.

To submit a request to the Integrations team visit this page and fill out the form. Website login should be in Keeper, Close, or you may need to request it from the client.

Integration team will ping you in the #checks_dash when complete. Visit this page to view the current integrations queue.

After submitting a request, put a note in Close so anyone viewing the lead knows its been sent to the integration team. (This process will be automated in the future.)

(/submit/integration-consultation-request-form/)

The integrations team is available to help with a range of technical issues including website audits, technical explanations or website troubleshooting.

If you would like to request an of these services from the integration, please fill out the form above. For an explanation of the services provided please read this help document.

When additional information is required

If the Integration Team requires more information, they will ping you about the integration and mark the request as “DNF” removing the request from the main queue. The request will be reinstated once you provide the missing information.

Below are the different integration options and the proper terminology to use in an integration request. Please be as specific as possible in your request to help the integrators and make sure the client has the smoothest transition possible onto FareHarbor.

I want to see…

Below are a list of different options for integrating our software onto a client’s website. Click here to see an interactive demo of these options.

…a button going to a calendar (Item Calendar)

This is the “item calendar” view and is the default view for an integration. The no-frills booking process is great for product pages where the customer can see all the details of an activity before they click on a booking element.

…a button going to item with the small calendar and description. (Item description)

This item view is called the “Item Description” page. Typically, this is the best view for any links or flows which are found outside of the product specific page and will be used as default view for homepage buttons, buttons in the header, fixed buttons, etc. The customer most likely to book is a well informed customer. The item description page provides the customer which an opportunity to read about critical activity information such as pricing, duration, and itenerary.

If you’re sending codes to a client and you would like to make sure the codes go to this item view, be sure to check the “Include item description and images” box in the options panel of the book buttons and embeds section.

…a button going to a grid of items. (Booking flow)

This integration view is called a “booking flow” and is a great way to help customers decide what item they would like to book. Booking flows can have just a few items or many items with multiple steps. It’s always a good idea to make sure the most popular items are front and center in the flow. You can also combine this with the item description view so customers see the description after they select an item.

If there are category pages on a websites that integration to a specific flow, please include the specific flow in your notes so the integration can be dialed as possible.

…a scrolling button in the corner. (Fixed button)

This is called a “fixed button.” Fixed buttons are typically the same for all pages on a website. They’re a great tool to make the sure the customer is never more than a click away from the booking process.

Additionally, the fixed button is mobile responsive and ensures a clear booking process on mobile. If a client would just like the button on their mobile site, but sure to note that in the integration request.

…a large calendar on the site. (Large calendar embed)

This is called a “large calendar embed.” This is a booking widget that can be placed directly onto a client’s web page. This calendar can display one more item’s availabilities. Usually best for companies with an irregular schedule (don’t offer the same activities every day).

You cannot go to the description page after selecting a date on the calendar.

…a small calendar on the site. (Small calendar embed)

This is called a “small calendar embed.” This is a booking widget that can be placed directly onto a client’s web page. This calendar can display one more item’s availabilities. Some website themes are not always compatible with putting a small calendar in the sidebar, but the integrations team will always try to honor the request if possible.

If you’re sending codes to a client, the code is the same for the large and small calendars. The calendar will display as the smaller calendar view as long as the parent container is smaller than ~550px.

…a booking flow on the site. (Item grid embed)

This is called and “Item grid embed” and can be used to put any flow directly on a client’s website. This embed is great for sites without a lot of content or for placing an eye-catching booking section on the homepage. Quality images determine the success of the item grid embed. Great images will help drive conversions for this embed.

Listed below are some requests sent into the integration team that have been categorized by request quality. The most important quality of a good integration request is clarity. All requests should contain enough information that the integration specialist can complete the request without reaching out for clarification. Additionally, please consider how the client’s website will look with the proposed changes. If the request is to add another button to a header without any space or to remove the only button on the homepage, try to walk through other possible options with the client.

Great Requests

• Has the URL for each page to integrate onto.
• Has each button for each page listed with the link generated in the Book Buttons and Embeds page of the FareHarbor dashboard.

These requests have no ambiguity about them. Its explicitly clear what the integration specialist will do on this website without any room for confusion. A request with this level of detail is most useful when the FareHarbor Dashboard fails to match with the client’s website and it’s difficult to know which item is assigned to each page. The below example is for a company going live on FareHarbor. Requests for live customers rarely require this level of detail unless its a re-integration or new website.

Its also extremely useful to have this level of information for ASN integrations where each button must have a specific ASN, ASN-ref, and price sheet. Often there’s no way for the integration specialist to have this information, so it must be listed out in the integration request.

Good Requests

• Has the URLs of the pages listed that need to be worked on OR
• Has a link going to the flow that needs to be implemented.

Once again, the main goal is to maximize clarity for the integration specialist. Consider the request from the point of the integration specialist. They have no knowledge of this account or what you may have been working on with them, so be sure to clearly outline any confusing parts of your request.

In the example below, the requestor gives information about the pages which will not have FareHarbor. Not every page will have a corresponding FareHarbor item. Often sites contain pages for activities no longer offered. Its always helpful to leave a note about whether the integration specialist will be removing these pages or ignoring them.

Bad Requests

Bad requests either don’t contain enough information to complete the request, are sent through improper formats, or are too confusing to understand. The request below contains little, to no information about what needs to be done on the client’s website.

While this is a convenient, please don’t ping the integration team to complete a request without putting in Close.

This request is way too wordy and confusing. This integration request is to change 2 buttons. All we need for this request is the URL from the page that needs the button and the link for the button.