This Service Level Agreement ("SLA") describes the availability and support Initek Consulting, Inc. ("we," "us," or "our") provides for Fleet Integrations, how we measure them, and how we keep Customers informed when something goes wrong. It uses the terms "Customer," "Authorized User," "Customer Data," "Order," "Services," and "Third-Party Services" as defined in our Terms and Conditions.
How available is the platform? We target 99.9% uptime each calendar month for the web application and API, which is about 43 minutes of downtime a month. See section 2.
When can I get help? Every day of the year, 7 a.m. to 5 p.m. Pacific. We respond to a major issue within 1 hour and to everything else within 24 hours. See sections 5 and 6.
How will I hear about an outage? By email to your account administrators and a banner in the web application, with updates until it is fixed. See section 7.
Are these guarantees? They are targets we run the platform to, not warranties, and they do not come with service credits unless an Order says so. See section 1.
1. What this SLA covers
In Short: The web application and API, for every Customer with a paid subscription. The figures are targets, and an Order can add to them.
Services covered. The Fleet Integrations web application at web.fleet-integrations.com, including sign-in, and the API that the web application, our mobile apps, and Customers' integrations use.
Who it applies to. Every Customer with a paid subscription in good standing. It does not apply to free trials, demonstration accounts, test or development environments, or features we label beta or preview.
Targets, not warranties. We monitor the Services against the uptime and response targets below and report on them. Missing a target is not a breach of our Terms and does not entitle a Customer to service credits or refunds. Section 16 of our Terms and Conditions still applies.
Orders. A Customer that needs different service levels or remedies can agree them with us in an Order. Where an Order conflicts with this SLA, the Order controls.
2. Uptime target
In Short: 99.9% each calendar month, which is about 43 minutes of downtime.
Target
Measured over
Downtime it allows
99.9% uptime
Each calendar month
About 43 minutes in a 30-day month
Downtime. A minute counts as downtime when Authorized Users cannot load or sign in to the web application, or when more than 5% of requests to the API fail with a server error or get no response.
Calculation. Monthly uptime is the minutes in the month, less downtime minutes, divided by the minutes in the month. Downtime caused by the events in section 3 and planned maintenance under section 4 is left out.
Measurement. We measure uptime with our own monitoring of the web application and API. On request, we will tell a Customer the uptime we measured for a past month.
3. What is not counted as downtime
In Short: Problems outside our platform, and announced maintenance, do not count. We still help with them.
Third-Party Services. Outages, delays, usage limits, or changes in systems the Customer connects or that deliver its data. Examples are booking and dispatch systems such as TBN, Coach Manager, and Moovs, and telematics providers such as Samsara and Motive. While a connected system is unavailable, syncing with it pauses and resumes when it is back.
Messages after hand-off. Delivery of text messages and emails after we hand them to the mobile carrier or email provider.
AI features. Fleet Assistant and AI-written summaries when OpenAI is unavailable.
The Customer's own systems and setup. Its networks, devices, and browsers; credentials for connected systems that have expired or been revoked; and problems caused by the Customer's configuration or by use that breaks section 10 of our Terms and Conditions.
Events beyond our reasonable control, as described in section 22 of our Terms and Conditions.
Planned maintenance announced as described in section 4.
A single feature that stops working while the rest of the Services respond, or data from a connected system that is processed late, is a support issue under section 6, not downtime. A feature that fails for many users with no workaround is a major issue.
4. Planned maintenance
In Short: Most updates cause no interruption. When we need to take the Services offline, we give at least 48 hours' notice.
Routine updates. We release updates regularly, normally without interrupting the Services and without notice.
Planned maintenance. If planned work will make the Services or a feature unavailable, we tell account administrators at least 48 hours ahead, by email or in the Services, with the expected start time and length. Where we can, we schedule it for times of low use and avoid holiday travel peaks. Planned maintenance announced this way is not counted as downtime.
Emergency maintenance. To fix a security vulnerability or prevent an outage, we may need to act with less notice. We give as much notice as we can, and downtime from emergency maintenance counts toward uptime.
5. Support hours and how to reach us
In Short: Every day, 7 a.m. to 5 p.m. Pacific, by support ticket or email.
Support hours. Every day of the year, including weekends and holidays, from 7:00 a.m. to 5:00 p.m. Pacific Time (10:00 a.m. to 8:00 p.m. Eastern).
Support tickets. Open a support ticket from the Help Center in the web application. For a major issue, choose the type "Major Bug / System Issue."
Email. Write to support@fleet-integrations.com, which opens a support ticket automatically. For a major issue, start the subject with "Major issue."
Outside support hours. Tickets and emails are received at any time and answered when support hours resume.
A report is resolved fastest when it names the company, the users, vehicles, or bookings affected, what happened and when, and includes any error message or screenshot.
6. Response times
In Short: 1 hour for a major issue and 24 hours for everything else.
Priority
Examples
First response
Updates
Major issue
The Services are down or users cannot sign in. Bookings, trips, or alerts have stopped processing for the Customer. A core feature is not working for many users and there is no workaround.
Within 1 hour, during support hours
At least every 2 hours during support hours, until the Services are restored or a workaround is in place
Everything else
A problem affecting one user, or with a workaround. Incorrect data on a report. Questions, configuration changes, and enhancement or feature requests.
Within 24 hours
As work progresses
How the clock runs. The 1-hour target counts support hours only. For example, a major issue reported at 6 p.m. Pacific is answered by 8 a.m. Pacific the next morning. The 24-hour target counts all hours.
What a response is. A person has reviewed the report and replied with what we found or what happens next. An automatic acknowledgment does not count.
Priority. We confirm the priority when we review a report, using the definitions above. If we change the priority the reporter chose, we say so.
Resolution. We do not commit to a resolution time, because many fixes depend on the Customer or a Third-Party Service. We keep working on a major issue until the Services are restored or a workaround is in place.
Feature requests. We respond to them within 24 hours. Building one is our decision, or custom development billed as quoted under section 2 of our Terms and Conditions.
7. Outages and incident communication
In Short: We email account administrators, show a banner in the web application, keep both updated, and explain what happened.
Notice. When we confirm an outage or a major issue affecting several Customers, we notify the account administrators of each affected Customer by email, and with a banner in the web application when it is available. We do this within 1 hour of confirming the issue during support hours.
Updates. We send updates as the incident progresses, and a notice when service is restored.
Incident summary. After a major incident, on request, we provide a written summary within 5 business days. It covers what happened, its impact, the cause, and what we are changing to prevent it happening again.
Affected data. If an incident affected Customer Data, for example syncs that were missed or duplicated, we tell the Customer what was affected and whether it was restored or reprocessed.
Security incidents. Unauthorized access to Customer Data is handled as described in section 13 of our Terms and Conditions.
8. Backup and recovery
In Short: User accounts, company settings, vehicle records, and payroll and billing notes can be recovered within 24 hours, losing at most the last 24 hours. Trip data is rebuilt from the Customer's connected systems.
The Services run in Amazon Web Services in the United States (Oregon region), on services that keep data in several separate data centers within that region. Backup copies of user accounts and company settings are also kept in the Ohio region. Backups are described in section 3 of our Data Retention Policy.
Information
Recovery point
Recovery time
User accounts, company settings, vehicle records and vehicle history, and payroll and billing notes
24 hours
24 hours
Bookings, trips, and trip results
Re-synced from the Customer's connected systems, as far back as those systems keep the data, on a best-effort basis
Recovery point is the most recent data that could be lost, measured back from the incident. Recovery time is how long it takes to restore the data once we begin recovery.
Scope. These targets cover loss or corruption of data within our AWS region. They do not cover an outage of the entire AWS region, which is an event beyond our reasonable control. We do not set recovery targets for other records.
Restores. We restore from backup to recover from an incident. We do not restore individual records a Customer has deleted.
9. Customer responsibilities
To get the most from this SLA, the Customer should:
keep its account administrator and billing contact details current, so incident and maintenance notices reach the right people;
keep the credentials it gives us for connected systems valid, and tell us before changing or revoking them;
report issues through the channels in section 5, with the details listed there; and
keep its own copies of records it is required to keep, as section 7 of our Data Retention Policy explains.
10. Changes to this SLA
We review this SLA at least once a year. The "Last updated" date at the top shows the current version. We will notify Customers by email or in the Services at least 30 days before a change that lowers a target in this SLA. Changes to service levels in a signed Order require a written amendment signed by both parties.
Questions can be sent to support@initekconsulting.com or to Initek Consulting, Inc., 10272 Aviary Dr, San Diego, CA 92131, United States.
Fleet Integrations