Proximi.io Service Level Agreement

Updated September 2022.

1. Positioning accuracy

Positioning accuracy aimed for in the positioning area is within 1-5 meters of real-life position.

Limitations:
Positioning area	Is the indoor area defined by the Customer and/or Reseller, where the end mobile application users will be positioned. Positioning will only work in the agreed area.
Positioning delay	Positioning data available in the mobile application or via a webhook may be updated with up to 5 seconds delay.
Room-level detection	The area may also include meeting rooms, staircases, and other areas where room-level detection is sufficient. By default, room-level detection will be applied to any separate room area that is less than 10m x 10m in size.
Special difficulty areas	The buildings may include areas that are especially difficult to cover with the aforementioned accuracy (for example due to large metal elements). The aforementioned accuracy is aimed to be reached in at least 95% of the positioning area.
Malfunctioning positioning infrastructure	Proximi.io is not responsible for inaccuracies in received positioning data due to malfunctioning or missing hardware. Proximi.io is not responsible for positioning accuracy in installations that are not carried out by Proximi.io team or a third party commissioned by Proximi.io; or are utilizing beacons that are not provided by Proximi.io.
Inaccurate floor plans	Proximi.io is not responsible for inaccuracies in positioning caused by errors or omissions in floor plans.

 

2. Device Limitations

 

Limitations:
Online requirement	An end user device used in positioning needs to have online connection in order to be positioned through the solution.
End user settings	In order to be positioned, the end user must have positioning and Bluetooth enabled on their mobile device. If the mobile application includes a capability for an end user to manually pause and resume positioning, the end user must have positioning enabled in the application.
Device limitations	A mobile device must fill the following requirements to be used in positioning: Android: minimum Bluetooth 4.0, newest or second-newest operating system version available iOS: minimum Bluetooth 4.0, newest or second-newest operating system version available The devices must have functioning sensors (Bluetooth, compass, accelerometer, GPS etc.). The device must have Bluetooth and Location enabled (called either Location or GPS on the device, depending on model). The mobile application using the positioning must be allowed to use location information. A mobile device used in positioning cannot be simultaneously acting as a Wi-Fi hotspot. In some device models having Wi-Fi enabled while using the device in positioning may also give weaker reliability in position updates. A device cannot be paired with a Bluetooth device (e.g. wireless headphones or a smart watch) when used in positioning. In mobile phones with dual sim capability, an on-going phone call may affect the phone’s ability to receive BLE signal. Positioning performance may also be affected in situations when end user device is low on battery. Proximi.io is not in charge of individual phones or phone models’ incompatibility with the positioning functionality.
Background operation and whitelisting	Some devices may have battery optimization features that are attempting to close all running applications in the device or to limit their cloud connection capability. In those devices the mobile application must be added to the list of permitted applications in order to keep running in the background (“whitelist”). Proximi.io will deliver instructions for how to carry this out with a few of the most popular phone models.   Some phone models or operations system versions (for example OnePlus and Honor devices) may have bugs or features that close all mobile applications regardless of the system settings. These devices will be attempted to wake up through all means permitted by the operating system as often as possible and feasible. For these devices is it not possible to guarantee 95% operation for the positioning. In order to improve background operation with the aforementioned phone models, Proximi.io may recommend the use of invisible data notifications or other means. In order to improve the situation, it is good practice to encourage End Users to open the application once per day.
Browser requirements	Web product will work on the newest and second-newest version of the following browsers: Firefox, Safari, Chrome, Edge Proximi.io management portal is optimized to work on the newest and second newest version of Chrome and Safari.

 

3. Other delays and limitations

Limitations:
Map view opening	The time the application takes to display a map view and the user’s current position after opening the application after the application has been closed may take up to 10 seconds
Navigation route	The calculation for the distance or optimal route to a destination may take up to 10 seconds.
Floor changes	When moving from one floor to another (either in free positioning or navigation mode), it may take up to 10 seconds for the user position to switch to the correct floor.
Other delays	Upon clicking any icon on the mobile application (etc. POI, level change) the reaction time of this may take up to 2-3 seconds. Any other interaction with the map, e.g. map panning may have up to 2-3 second delays.
Accessible routing	Fully accessible wayfinding setup requires extra care and time and will be charged separately. By default, accessible routing will only refer to best effort for guiding users to paths suitable to them.
Compass	Some devices or device models do not include a real compass sensor, or the compass is not working as intended. Even if deliveries include some functionality relating to the use of compass, such as showing the direction the user is facing to, the correct functionality of such features cannot be guaranteed. The use of compass is always best-effort.
Geofence detection	Geofence detection is based on how much background operation time the application gets on the device. This is controlled by the operating system. Geofence detection happens with certainty only if the application is in foreground mode, and the geofence diameter is minimum 10 meters in the positioning area. No guarantees are given for geofencing functionality in the background mode. Geofence enter detection may take up to 5 seconds on the device. If reaction to geofence detection is done through a cloud integration, it must be noted that the cloud connectivity may also take some time. Proximi.io gives no promises for the reactivity on any cloud integrations. Geofence exit events are triggered as best-effort. Dwell time calculation reliability cannot be guaranteed due to background operation limitations.

Sections 1,2 and 3 may be updated from time to time as new operating system versions, devices or legislation changes may bring new limitations or capabilities for the Proximi.io Software.

 

4. Planned maintenance

From time to time, Proximi.io may undertake planned maintenance activities, which may limit Proximi.io Software and Integrated Product functionality. At the time of signing this Agreement, Proximi.io has a regular time window reserved for maintenance activities every Wednesday at 10pm – midnight Helsinki time (Eastern European Time / Eastern European Summer Time). Most scheduled maintenance causes minimal interruptions to Proximi.io service availability or performance.

If required, Proximi.io reserves the right to undertake urgent maintenance activities also at other times, in order to fix critical issues and preserve software availability. If possible, Proximi.io will attempt to inform the Reseller or Customer about these maintenance activities beforehand.

If Reseller or Customer undertakes any planned maintenance or other operations, which may affect Proximi.io server load or other operations, when possible, Reseller informs Proximi.io by email 10 days before the scheduled operation.

 

5. Service commitment

Subject to this Agreement, Proximi.io’s service commitment covers providing access to the Proximi.io APIs. Proximi.io will use commercially reasonable efforts to make Proximi.io APIs available with a Monthly Uptime Percentage (defined below) of at least 99.0%, in each case during any monthly billing cycle (the “Service Commitment”).

For the purposes of this section, “Monthly Uptime Percentage” is calculated by subtracting from 100% the percentage of minutes during the month in which a Proximi.io API was in a state of “Unavailable.” Monthly Uptime Percentage measurements exclude downtime resulting directly or indirectly from any reason falling under the Proximi.io Service Exclusions (defined in section 8 of this appendix).

“Unavailable” and “Unavailability” refers to situations when Proximi.io API returns no response, when accessed either through a mobile SDK or through a direct API request. A “Service Credit” is a monetary credit, calculated as set forth below, that we may credit back to an eligible account.

Service Credits are calculated as a percentage of the total charges paid by the Reseller or Customer (excluding one-time payments such as setup charges) for a Proximi.io instance for the month in which the Unavailability occurred in accordance with the schedule below.

Monthly Uptime Percentage	Refund
99.0% – 97.0%	10%
97.0% – 70%	30%
Less than 70%	100%

 

Proximi.io will apply any Service Credits only against future Proximi.io payments otherwise due from the Reseller or Customer. Service Credits will not entitle the Reseller or Customer to any refund or other payment from Proximi.io. Service Credits may not be transferred or applied to any other account. The Reseller or Customer’s sole and exclusive remedy for any unavailability, non-performance, or other failure by Proximi.io to provide Proximi.io Software is the receipt of a Service Credit (if eligible) in accordance with the terms of this Service Commitment.

To receive a Service Credit, the Reseller or Customer must submit a claim by sending an email to support@proximi.io. To be eligible, the credit request must be received by Proximi.io within 30 days of the incident and must include:

• the words “SLA Credit Request” in the subject line;
• the dates and times of each Unavailability incident that the Reseller or Customer is claiming;
• the affected Proximi.io account information; and
• the Reseller or Customer’s request logs that document the errors and corroborate the Reseller or Customer’s claimed outage (any confidential or sensitive information in these logs should be removed or replaced with asterisks).

 

If the Monthly Uptime Percentage of such request is confirmed by Proximi.io and is less than the Service Commitment, then Proximi.io will issue the Service Credit to the Reseller or Customer within 30 days of receiving the claim. The Reseller or Customer’s failure to provide the request and other information as required above will disqualify the Reseller or Customer from receiving a Service Credit.

 

6. Support Commitment

Proximi.io support covers solving problems relating to bugs or access issues in the Proximi.io SDKs, APIs, and web portal (“Support Commitment”). Support will be provided by default as email, unless separate mode of communication is separately agreed for that support inquiry.

All email inquiries will be answered within the reaction times defined below. Business days are defined as between Monday – Friday Finnish office hours (9am – 5pm, GMT+2; Daylight Saving Time GMT+3), excluding Finnish public holidays. The following days constitutes the full list of Finnish holidays: New Year’s Day (1.1.), Good Friday (varies), Easter Monday (varies), May Day (1.5.), Ascension Day (varies), Midsummer’s Eve (varies), Independence Day (6.12), Christmas (24.-26.12).

The support will be provided in English. Due to the wide diversity of inquiries the Reseller or Customer may have, and the methods required to resolve and response to them, inquiry response time IS NOT defined as the time between the receipt of the inquiry and problem resolution. The inquiry response time is determined as the time within which Proximi.io shall react to support requests and based on their criticality, determine the potential next steps to take in order to determine the extent of the problem or to solve the issue.  After receiving a report of fault, Proximi.io shall use a reasonable method to provide the Reseller or Customer with a progress update.

Should any on-site visits be required, those will be separately agreed on, and travel expenses and man-hours spent on-site will be charged separately.

 

7. Priority classifications

Priority of a certain incident is set based on the time sequence in which an incident needs to be resolved, based on impact.

 

Priority	Definition
P1. High	Severe incident which causes significant disruption to one or more of use cases.  Example: server issues resulting in no routes being found.
P2. Medium	Disturbing incident which causes disadvantage for the use of the system. Examples: slowness in solution performance, integration issues causing new data not being synched correctly, one or multiple use cases not performing correctly causing disturbance to multiple phone models or a large number of end users.
P3. Low	Disturbing incident which causes disadvantage for the use of the system. Examples: Logging in to the web portal for maintenance not working, one or multiple use cases not performing correctly causing disturbance to a single phone model or a small number of end users.

 

Defined targets for incident handling are:

Priority classification	Reaction time	Resolution time communication
High	Same business day	Priority 1 issues will be always immediately reported to tier 3 support. Solved within SLA limits (99,0% uptime)
Medium	2nd business day	Fixed within office hours. Due to the complexity of the issues included in this category, not specific resolution times can be given. SDK/app-level fixes always require an update to the mobile application, which extends the timeline of fixing the performance to End Users.
Low	best effort	Apart from logging in issues, best effort. If the workload of fixing a minor issue is disproportionate, some issues may not be fixed altogether.

 

8. Proximi.io Service and Support Exclusions

The service commitment and support commitment do not apply to any unavailability, suspension or termination of Proximi.io API access or support, or any other Proximi.io performance issues:

• use of the Proximi.io Software in any other context than what is described in this Agreement and the Delivery Order Forms;
• unforeseen merger of the Integrated Product with any other product;
• caused by factors outside of our reasonable control, including, without limitation, any Force Majeure event or Internet access or related problems beyond the point in the network where Proximi.io or its direct subcontractors maintain access and control over the Proximi.io API;
• that result from any actions or inactions of the Reseller or the Customer or any third party (other than Proximi.io’s direct hosting subcontractor);
• that result from the Reseller or the Customer’s equipment, hardware devices, software or other technology and/or third-party equipment, hardware devices, software or other technology;
• that result from errors or omissions in the material received from the Reseller or the Customer
• that result from any scheduled maintenance; or
• arising from the suspension and termination of the Reseller or the Customer’s right to use the API in connection with any breach by a party of the Agreement or otherwise in accordance with the Agreement.
• random, operational, or intermittent conditions which are recoverable by the Reseller or the Customer or which are not reproducible by the Reseller or the Customer.
• result of the Reseller or the Customer’s failure to comply with the terms and conditions of this Agreement;