Service Level Agreement (SLA)

This Service Level Agreement forms part of the Terms of Service (/terms/) and describes the commitments of AIGiner S.L. regarding the availability of the Shara service, incident handling and support. Service status can be checked at https://status.aiginer.com.

1. Why this document carries no availability percentage

Shara is in a pre-general-availability phase. There is not yet a history of availability measured over real production use, and without that history any percentage we published would be a number written down, not a commitment we could defend to the Customer.

We have chosen not to publish one. Once we have at least six months of continuous measurement over production customers, this document will be updated with per-plan availability commitments and their associated credit regime, following the review procedure in section 8. The Customer will be notified with the notice period set out there.

On the status page, so that nobody reads it as something it is not: the percentages https://status.aiginer.com shows next to each component are the tool’s default value in the absence of manually declared incidents, not the result of a probe measuring availability. They are neither an audited metric nor any kind of commitment. The only automatic probe that exists today checks the service from a single location, hosted moreover on the very infrastructure it watches, which makes it useful as an alert to us and insufficient as evidence to a customer.

In the meantime, what follows is what we do commit to, and what you can hold us to.

2. Current commitments

These commitments are the same for every plan. Where something applies only to some, it is said expressly.

• Continuous monitoring of the service through an automatic probe, and publication of each component’s status at https://status.aiginer.com. The second probe, external to our infrastructure, is pending deployment; until then the measurement is not offered as evidence of availability.
• Communication of any incident affecting the availability of the service: on the status page while it lasts, and, where relevant, by email to the administrator account.
• Handling of incidents in order of severity, always prioritising loss or exposure of data above anything else.
• A written explanation, at the Customer’s request, of what happened in any incident that affected them: what failed, for how long, and what has been done so it does not happen again.
• Advance notice of scheduled maintenance in accordance with section 4.

3. Support

Shara support is provided directly by the AIGiner S.L. team. There is no call centre and no outsourced first line: whoever reads your incident is whoever builds the product.

• Channel: email to support@aiginer.com, and the support channel inside the application itself.
• On Max, Max ×5, Max ×20 and Concerto Local there is also telephone support, during the same business hours, on the number AIGiner provides in writing when you sign up.
• Hours: business days, Monday to Friday, 9:00–18:00, Spanish peninsular time (CET/CEST).
• Paid plans have priority in the queue over evaluation and pilot accounts.
• First-response time, counted in business hours and business days (Monday to Friday, 9:00–18:00, mainland Spain time), by incident severity (section 3.1) and plan. Critical: 4 business hours on First and Pro, 2 on Max, Max ×5, Max ×20 and Concerto Local. High: 8 and 4 business hours. Medium: 3 and 2 business days. Low: 5 and 3 business days.
• This is a response time, not a resolution time: within it, a member of the team will have read and classified the incident and replied with what they have understood, what is being done and when you will hear from us again. Resolution time depends on where the cause lies, sometimes in third-party systems, and is not committed.
• Missing the first-response time does not give rise to automatic credits or financial compensation.
• Incidents involving data loss or a security breach take priority over all others and are handled as soon as we know of them; outside support hours, as far as we are available. Breach notice to the Customer follows the DPA (48 hours).
• In Concerto Local, diagnosis may require access to the Customer’s installation or that they send us their logs. That access is authorised by the Customer, with whatever scope they decide; while it is not provided, resolution time does not run against us.

3.1 How we classify severity

• Critical: the service is unreachable, there is material data loss, or there is an active security breach.
• High: significant degradation, a core feature not responding, or agents failing systematically.
• Medium: a non-critical feature misbehaving, or a secondary integration down.
• Low: a usage question, an improvement suggestion, documentation, or a cosmetic matter.

4. Scheduled maintenance

The usual maintenance windows are the last Sunday of each month, from 02:00 to 06:00 UTC. They are published in advance at https://status.aiginer.com and, where relevant, by email to the administrator account.

• Critical security updates may be applied on reduced notice of 24 hours, with notification to the Customer.
• If a window clashes with a critical operation of the Customer’s (a tax filing deadline, a major event), they may ask for it to be postponed and an alternative will be agreed wherever technically feasible.

5. If the service is unavailable

As there is no numeric availability commitment, there is no automatic credit scale either. What applies instead is the following, which is simpler and depends on no interpretation. It applies to paid plans served from our infrastructure — First, Pro, Max, Max ×5 and Max ×20 — and not to evaluation or pilot accounts, which pay no fee to refund, nor to Concerto Local, which is governed by section 7:

• If the service is unavailable for reasons attributable to AIGiner S.L. for more than four consecutive hours in a calendar month, the Customer may request a refund of the proportional part of the monthly fee corresponding to the unavailable time.
• The request goes to support@aiginer.com within thirty calendar days of the end of the affected month, stating the periods observed.
• The refund is applied as a discount on the next invoice or, if the contract has ended, by bank transfer.
• This refund does not limit any of the rights the Customer has under the Terms of Service or under applicable law.

6. What is out of scope

The following are not considered unavailability attributable to AIGiner S.L. and therefore do not give rise to the refund in section 5:

• Scheduled maintenance notified under section 4, and critical security updates on reduced notice.
• Acts of God and force majeure: natural disaster, armed conflict, health emergency or a decision of a public authority.
• Denial-of-service attacks that cannot reasonably be mitigated, duly evidenced.
• A failure of a sub-processor (/es/subprocessors/ (in Spanish)) reflected on its own status page. We will work to minimise the impact, but the incident does not generate a refund.
• Acts or omissions of the Customer or its users: misconfiguration, use contrary to the acceptable use policy, or integration with unsupported systems.
• Unavailability of the Customer’s connectivity or internal network, of the machines where they have installed the desktop application or an agent, or of the third-party tools they have connected them to.
• Suspension of the service for non-payment or on legal request.
• Features expressly identified as beta or in testing.

7. Concerto Local

Concerto Local is installed on the Customer’s infrastructure. Its availability therefore depends on that infrastructure and not on ours, so sections 5 and 6 do not apply to it as regards service availability.

The support commitments in section 3 do apply, on the same terms as for every other plan, both for the installed component and for the cloud orchestration allowance the plan includes.

One component does depend on us: the licensing service that periodically validates the installation. If that validation is unreachable for reasons attributable to AIGiner S.L., the installation keeps working for the grace period set out in the Terms (/terms/, section 2.2), and we undertake to restore it within that period.

8. Review of this agreement

This document will be updated once we have the historical measurement that allows numeric availability commitments to be published, and it may also be updated to improve the Customer’s guarantees or to reflect how the product evolves.

Any change that is material and reasonably adverse to the Customer will be notified at least thirty days in advance by email to the administrator account.