Odoo SLa support

Version: 20230224

Our Service Level Agreement (SLA) is open for all to see, just like the code powering Odoo.

We optimize them based on feedback from new and existing clients. In this way, everyone benefits from improvements to our services.

SLA Procedure

EXPLORATION

EXPLORATORY PHASE

If you are not already a client of 360 ERP, we will analyze your environment for configuration and customization.

We use the KISS principle for all our ERP projects, which we define as “Keep It Simple Standard.”

Existing clients skip this phase.

TRANSFER

MIGRATION AND TRANSFER

If necessary, we will conduct a migration project together to bring your environment up to the 360 standard.

We offer the full-force methodology for suitable projects: in one week, we migrate the Odoo environment with a dedicated team from the client and 360 ERP.

Existing clients skip this phase.

START OF SLA

START OF SLA

360 ERP creates a help desk team and the customer receives their own 360 e-mail address that can be used to create tickets.

Together with the customer, key users are defined who receive a portal account at 360 ERP.

From this moment on, we guarantee your Odoo environment and its level of quality.

REPORTING

REPORTING AND CONSULTATION

Discuss and evaluate services and any fair-use policies once a quarter.

Privacy Provision

We strive to resolve all support incidents within 24 business hours. The table below lists our response and resolution times. The times specified are only the hours incurred by our own team. If an outside party is required to resolve the disruption or to answer questions, the time it takes for the outside party to respond and/or take action will be added to the turnaround time below. If we take longer than the stated time to provide a resolution, the ticket reporter will be notified. A ticket will be closed once the issue is resolved, in some cases only after your confirmation. If we do not receive a confirmation, the ticket will be automatically closed and the reporter will receive a notification.

Support Types

APPLICATION SUPPORT

With application support, we guarantee to resolve bugs or occasional incidents that lead to disruptions in your Odoo environment.

If any bugs occur in the standard version of Odoo, we will act as liaison with Odoo S.A. for further handling.

MIGRATION SUPPORT

Every two years, we will migrate your environment to the latest version of Odoo for a fixed price. As a true migration specialist, this is a unique service provided by 360 ERP.

FUNCTIONAL SUPPORT

Functional support includes all questions you and your key users have related to the use of your existing setup and configurations. This SLA also covers minor adjustments to your configuration required to better connect with your daily work process.

If you do not enter into an SLA for functional support, all queries will be charged based on the subsequent calculation of the actual hours incurred according to the then-current hourly rate of consultancy or architecture.

Developing, modifying, setting up or configuring new processes or Odoo modules is normally beyond the scope of this SLA. We will estimate all requests for new functionality (RFC) in advance and implement the requests only after receiving approval.

Support approach

SYSTEM REQUIREMENTS

To carry out our SLA support properly, we need a computable Odoo environment over which we have control. If that is the case, you can count on all common bugs and functional issues being covered under the SLA.

Sometimes another party or employee makes changes to your infrastructure, modules or configuration without consulting 360 ERP. If bugs or other problems arise as a result, our troubleshooting work will not covered by the SLA and will be charged on an after-the-fact basis.

AVAILABILITy

Our support is available during weekdays from 08:30 to 17:00, excluding national holidays* and occasional team days. We will notify you of these days in advance.

* New Year’s Day, Good Friday, Easter Sunday and Easter Monday, King's Day, Liberation Day, Ascension Day, Whit Sunday and Whit Monday and Christmas and Boxing Day.

WORKING METHOD

We always carry out updates, patches and changes in accordance with the Develop, Test, Acceptance and Production (DTAP) procedure. Modifications will first be tested on your Acceptance environment and only released to your Production environment after approval.

Non-critical updates will be scheduled in consultation with you so that you do not suffer unexpected downtime.

TICKET RECEIVED

You will receive a confirmation that the ticket was successfully received. In addition, the ticket will be visible in your portal.

TICKET ASSESSED

Our team will determines whether your ticket will be treated as application or functional support, or if it is new or changed functionality ( Request For Change).

TICKET RESOLVED

Working with the reporter, we resolve the ticket within response and resolution times. In doing so, we try to share as much knowledge as possible, for example, using video recordings.

EVALUATION

Every quarter, we evaluate the service on the tickets handled.

RESPONSE AND RESOLUTION TIME

Indicator	Description and measurement method	Target time	Ticket requirement
Response time	Arrival of incident at help desk until reporting back to key user.	4 hours
Handling time of high priority notifications	Time from feedback from support that the notification conforms to the SLA agreement.	Leads to immediate action	High priority are incidents for which critical functionality is unavailable and no workaround can be used.
Handling time of medium priority notifications	Time from feedback from support that the notification conforms to the SLA agreement.	By the end of the next business day	Medium priority are incidents for which functionality is unavailable or working incorrectly.
Handling time of low priority notifications	Time from feedback that the notification conforms to the SLA agreement.	At the end of the working day plus three working days

It is common for our team to need more information to resolve a ticket. We will then always try to contact the ticket reporter, initially by e-mail and, for urgent tickets, by phone. If the key user is unavailable, the response time will be extended until contact is established. If we have been unable to contact a key user after seven days, we will close the ticket and notify the reporter by e-mail. In the absence of one of the key users, we will assume that the duties and authority can be assumed by one of the other key users.

FAIR-USE POLICY

We offer our SLA so you can be assured of our availability, excellent support and clear agreements about our support. Actual support needs will vary based on the month, depending on the dynamics of your environment and the number of support questions your key users have. For this reason, we have a fair use policy for our functional SLA: if for a period of three consecutive months we require more or fewer hours of support than what we have agreed to in the SLA, we will reassess the service and make new arrangements with you, depending on the cause of the differences. To do so, we will adjust the SLA both up and down.

REPORTING AND CONSULTATION

Each quarter, we evaluate support with you based on an SLA report. This will include at least one or more of your key users and a representative of the 360 team. During this consultation, we will discuss at least the following points:

Evaluation of the past period based on analyses.
Incident analysis and problem analysis.
Advice/comments following the analyses.
Operational issues (areas for improvement).
Future expectations.
Fair use policy.

HOSTING AND BACKUP

By default, 360 ERP only offers hosting through Odoo.sh . With this form of hosting, you are assured of stability, high availability and automated backups. More information about Odoo.sh's backup policy can be found here: https://www.odoo.com/security .
In the case of on-premise hosting (at your own location), you are responsible for an adequate backup policy and monitoring the environment in such a way that a backup can be restored at all times after any restore of the server and/or Odoo application.

MIGRATION SERVICE

Optionally, 360 ERP enables you to opt for a migration SLA: for a fixed fee, we migrate your environment to the latest version of Odoo every two years. In this way, you benefit from the latest functionality and optimization and your environment stays up-to-date without unexpected costs. Our migration service includes the following components:

TECHNICAL MIGRATION

MIGRATION DATABASE

Migration of the database using Odoo migration scripts and our own 360 cleaning and optimization script.

CODE MIGRATION

Code migration of your customizations to the new version.

EXTERNAL CODE MIGRATION

Code migration of external (community) modules that are no longer available for the new version.*

* For migration of unavailable community modules, we apply a maximum of four hours of labor per module. If a module is not available for the new Odoo version, we will consult with you to see if we can apply a suitable functional alternative or other module.

STANDARDIZATION

FUNCTIONAL ANALYSIS

Functional analysis of modules and customization to standardize as much as possible.

Standardization

Standardization customization and external modules.

NEW FUNCTIONALITIES

Functional analysis and advice on newly available functionalities.

The migration service is void if you do not have the appropriate Odoo Enterprise licenses. Requests for functional or technical modifications (RFC) and adding new components to Odoo is outside the scope of the migration service and will be charged based on subsequent calculation.

The fixed price we agree with you to perform our migration SLA is based on a snapshot of your Odoo setup and its reasonably expected growth. We assess primarily on complexity, customization and the amount of data in your system. If you requested many or complex RFCs (additional customization), the system has grown explosively or additional Odoo apps have been implemented between the start of the SLA agreement and the migration after two years, migrating these components will be charged based on subsequent calculation. You can request a re-evaluation and increase of the migration SLA at any time to avoid unexpected costs.

OTHER CONDITIONS

If (external) parties other than 360 ERP make changes in or to the environment(s) we support, we can no longer guarantee their operation. In that case, the validity of the SLA agreed with you will expire.
Support requests arising from modifications of, or functionality developed by, third parties are outside the scope of this SLA.
We treat requests for changes or modifications to the software as an RFC (request for change) and therefore these requests are outside the scope of the SLA.
Upon termination of the SLA agreement, 360 ERP will transfer the source code including history to another party to be designated by you.
In the event of a negative evaluation of the SLA service, we put in writing what arrangements for improvement we make and within what time frame they must be achieved. The client has the right to terminate the SLA prematurely, at the end of the first year from the effective date, in case of two negative evaluations. An evaluation must be reported to 360 ERP in writing within seven days of the initial joint evaluation. Upon termination of the SLA after the end of the first year (after the effective date), a refund of one-half (50%) of the migration service will be made.
If you as the client feel dissatisfied with the handling of an incident, you can request an escalation. An escalation will always initially be handled by a 360 ERP (senior) partner. If your escalation is still not resolved to your satisfaction it will be taken up by the Managing Partner.