Service Level Agreement (SLA)

This Service Level Agreement forms part of the Terms of Service (/terminos) 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 by email to the administrator account when the interruption exceeds one hour.
• 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 [email protected], and the support channel inside the application itself.
• Hours: business days, Monday to Friday, Spanish peninsular time (CET/CEST).
• Paid plans have priority in the queue over evaluation and pilot accounts.
• We do not publish a first-response time, for the same reason as in section 1: we do not yet have a history that would let us commit to one and meet it. It will be published once we do.
• Incidents involving data loss or a security breach are handled immediately on detection or on receipt of the report, regardless of plan and of business 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 at least seven days in advance at https://status.aiginer.com and by email to the administrator account.

• Critical security updates may be applied on reduced notice of 24 hours, with immediate 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 [email protected] 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 (/sub-encargados) 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 (/terminos, 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.