Skip to main content

FAQ

How can Solvvy be embedded in a native mobile app?​

Solvvy can be easily embedded into a native mobile app using a webview. Some third party tools integrate into native mobile apps using native mobile SDKs (we previously used this approach), but now our approach to embedding Solvvy in native mobile apps is to use a webview. The main benefits to this approach are:

  • Updates and new features for the Solvvy experience are immediately available (whereas updates to native SDKs often lag behind updates for the web experience).
  • Updates and new features for the Solvvy experience do not require a new release of your app.
  • The user experience is completely consistent between mobile and web.

What exactly is a webview?​

A webview is a fully-functional mobile web browser screen that runs in your app. The only difference between a webview and a normal mobile web browser screen is that the user cannot edit the URL. If the webpage that is loaded in the webview is very responsive and mobile-friendly, the experience can appear to be fully native.

What level of engineering effort is required to embed Solvvy in a native mobile app?​

Very little. This document contains all the code necessary to accomplish this, so it's mostly just copy and paste for your engineers.

Which URL should be opened in the webview?​

If you already send users to your web Help Center through a webview, and Solvvy is already installed in your web Help Center (or will be), then you don't need to do anything at all. Anytime users access your web Help Center, whether it be through a desktop web browser, a mobile web browser, or a webview launched from within your mobile app, Solvvy will be there to provide a help them self-serve.

If you want to directly launch Solvvy at any point in your app (without invoking your web Help Center), you still use a webview. To make this possible, we will provide (host) a blank page where Solvvy is installed and configured to auto-launch. Your Solutions or Sales Engineer will provide you with the exact URL once the page is set up and ready for you to use in the webview. This approach feels very native because the Solvvy takes up the entire screen and loads very fast.

What is the hand-off experience like when the user cannot self-serve?​

It depends on what support options you have configured.

Email / Ticket​

If Solvvy is configured to submit tickets through our back-end connection to your CRM (which is usually the case), then the ticket submission screen is part of the Solvvy flow and works great in a webview. It feels like a native experience. There is essentially no difference between mobile and desktop for this support channel.

Live Chat​

In desktop browsers, Solvvy integrates with various live chat providers so that if the user selects this support option, the live chat widget from the chat provider will be launched and the question the user typed into Solvvy will be copied over as the first message in the live chat. However, on mobile, the live chat experience is not ideal in a webview because things like push notifications don’t work as well. For this reason, we recommend using your live chat provider’s mobile SDK to implement the live chat support channel on mobile, and Solvvy will simply close it’s own webview and hand-off control back to your app if the user selects the live chat support option. Useful metadata, such as the question the user asked and any pre-contact form fields they selected, is made available to your app during that hand-off.

Phone​

Similarly, for the phone support option, the Solvvy webview also dismisses itself and hands control back to your app. This enables your app to launch the native phone app (or some other direct audio call experience), which is better than what Solvvy does for the desktop experience, which is just to display the phone number.

What happens when a user clicks on a KB article link on the Solvvy answers screen?​

This is actually one of the main benefits to the webview approach. When a user clicks on a KB article link, it shows that article in the same webview, which is still in your app. The user can use the back button on the webview to go back to the Solvvy modal.

What happens when a user goes back to the app and then wants to come back to Solvvy?​

The state is saved for the pre-defined time period of a Solvvy session, which is currently 1 hour. If they return to the Solvvy flow within that time period, then they see whatever screen they left off at. After that time period, it will start the Solvvy flow over again.

Yes. The best way to do this is to create Help Center content which contains the deep link they should use, along with appropriate context explaining when that link should be used. Then Solvvy will surface that answer with the link when the user asks a relevant question. You can also use a Workflow or Smart Suggestion to surface those links.

If you want to direct users to a web app link when they are using a web browser, and instead direct them to a mobile deep link when they are in your app, then use the instructions in the appropriate section "Intercept URL requests from within a webview" below, depending on your platform. Then just add code to translate specific web URLs into the right deep links.

What browsers or devices does Solvvy support?​

In general, we aim to support browsers that are supported by their respective vendors. IE 11 is the only version supported by Microsoft. Android versions 8+ are supported. Safari 10 is supported by Apple (we also support 9). Chrome does not list any version as supported, but it is aggressively updated on all platforms.

Supported​

  • Chrome on desktop, Android 6+, and iOS
  • Safari 9+ on desktop and iOS
  • Firefox
  • Microsoft Edge
  • Internet Explorer 11

Not Supported​

  • Safari 8 and below
  • Internet Explorer 10 or below
  • Any browser on Android versions below 6 (no longer supported by Google)

What data does Solvvy collect, so we can know what to disclose in the Apple App Store?​

Apple's web page about App Privacy Details explains that some data may not need to be disclosed if it meets the following conditions:

Optional disclosure​

Data types that meet all of the following criteria are optional to disclose:

  • The data is not used for tracking purposes, meaning the data is not linked with Third-Party Data for advertising or advertising measurement purposes, or shared with a data broker. For details, see the Tracking section.
  • The data is not used for Third-Party Advertising, your Advertising or Marketing purposes, or for Other Purposes, as those terms are defined in the Tracking section. Collection of the data occurs only in infrequent cases that are not part of your app’s primary functionality, and which are optional for the user.
  • The data is provided by the user in your app’s interface, it is clear to the user what data is collected, the user’s name or account name is prominently displayed in the submission form alongside the other data elements being submitted, and the user affirmatively chooses to provide the data for collection each time.

If a data type collected by your app meets some, but not all, of the above criteria, it must be disclosed in App Store Connect.

Examples of data that may not need to be disclosed include data collected in optional feedback forms or customer service requests that are unrelated to the primary purpose of the app and meet the other criteria above.

All data that is collected by Solvvy meets all of these conditions and therefore does not need to be disclosed. In fact, data from customer support requests is specifically called out as an example of data that may not need to be disclosed.

However, if for some reason you decide to disclose data collected by Solvvy, here are the details:

Types of data​

Solvvy only collects 2 of the data types spelled out by Apple:

  • User Content > Customer support : Data generated by the user during a customer support request
  • Usage Data > Product Interaction : Taps, clicks, scrolling information

Data use​

Solvvy uses the User Content and Usage Data collected for Analytics : to evaluate user behavior, including to understand the effectiveness of existing product features, plan new features, or measure audience size or characteristics.

Solvvy also uses the User Content collected for App Functionality : to allow the user to self-service their support request or to make contact with a customer support agent.

Data linked to the user​

None of the data that Solvvy collects is linked to a particular user. All Usage Data is anonymized, as is the User Content data Solvvy collects. In order to do this, Solvvy uses state-of-the-art PII redaction software (Google's DLP service) to remove any personal data from customer support requests before storing them in our system.

Tracking​

Solvvy does not use any data collected for tracking or advertising purposes.

Solvvy's Privacy Policy