Skip to content
Guester
ENTR
Book a demo
Legal documents

Support and Service Level Agreement (SLA)

Support scope, service-level measurement, incident priorities, maintenance boundaries and escalation.

Version 3.2Document date:

This document defines standard support, incident management, maintenance and service-level arrangements for Guester modules enabled in your account under the Terms of Service. Support includes assessing use questions, investigating software faults, explaining appropriate fixes or workarounds and coordinating supported integration issues. These process obligations also apply during the free Founding Hotel period.

Custom development, out-of-scope installation, management of hotel local networks or hardware, extensive data cleansing and on-site training are excluded unless separately and expressly accepted. Standard support and ordinary pilot fault investigation do not generate additional charges without prior acceptance. The DPA takes precedence for personal data incidents; a separately accepted account service-level summary takes precedence over this document only for the support and measurement matters it expressly addresses.

Requests may be submitted through the support channel made available in the panel or info@theartifics.com. Standard support is provided Monday–Friday, 09:00–17:00 Turkey time (Europe/Istanbul, UTC+3). P1 critical-incident support, incident assessment and necessary escalation are available 24 hours a day, seven days a week, including weekends. Ordinary non-P1 requests are handled under the standard support calendar. Any separately accepted additional channel or different account support arrangement is shown in the account or order summary; the Customer need not fill in fields in this agreement.

The support hours and 24/7 P1 support above are the standard service arrangements under this document. Until a numerical service level has been separately accepted, the recording, prioritisation, communication, maintenance, investigation and escalation duties below apply; no uptime percentage, first response or permanent resolution within a fixed number of minutes or hours, or disaster-recovery deadline is promised. Round-the-clock critical-incident support does not guarantee resolution of every critical incident within a fixed time. Any numerical commitment must disclose the measured function, clock rules, target, exclusions and any remedy together. Undisclosed working hours or targets may not later be used as grounds for rejecting a request.

An accepted service-level target may not be reduced to the Customer's detriment by a unilateral account-setting change. Material changes follow the notice and express-acceptance process in the Terms of Service. A free pilot does not automatically reduce accepted support scope or data-security duties.

A report should identify the property, affected function, event time, error message, business impact and, where possible, an example cleared of personal data. The Customer supplies an available authorised contact. The Provider handles the request in a traceable record linking receipt time, priority, affected service, investigation steps and material Customer communications. Duplicate records for the same incident may be linked without losing new information.

Passwords, full API keys, complete payment-card details and unnecessary guest/personnel lists should not be included in support messages. A secure sharing method is explained where a sensitive example is necessary. Investigation access is limited by purpose, role and necessity; a support request does not authorise permanent access to all hotel data. Only necessary additional information is requested; sharing with third parties remains subject to the DPA and data minimisation.

P1 — Critical: Unauthorised or cross-hotel data access, an external action for the wrong property, continuing data loss or widespread unavailability of the core service. The immediate focus is containing risk, stopping affected sending, preserving records and restoring safe service. DPA notification procedures also apply if personal data is breached.

P2 — High: Unavailability of an important module or serious operational disruption without a continuing P1 risk. Impact is assessed, any available workaround is explained and the remediation/escalation plan is shared.

P3 — Normal: A limited functional issue or fault with a usable workaround. Investigation, workaround and the appropriate fix plan are recorded. P4 — Information/improvement: A use question, visual/text correction or development suggestion. It is answered or considered through the relevant product process; implementation of every suggestion is not promised.

Priority is determined from actual business impact and security risk together. It is reassessed if impact changes; any downgrade rationale is explained to the Customer. The Customer may challenge the assessment or report increased impact in the same record. Ticket classification does not justify delaying a confirmed breach or incorrect external action as an ordinary fault.

A first substantive response follows human assessment and explains the incident record, priority, known impact and next step. An automatic receipt email is not a first substantive response. A workaround is an alternative that reduces impact; restoration returns the affected function to safe use. Permanent resolution addresses the verified cause. These stages are recorded separately and completion of one does not imply completion of the others.

Where a response time has been separately accepted, its clock starts when the request reaches the support channel, using a 24/7 calendar for P1 and the standard support calendar for other requests; for an incident identified through the Provider's own checks, the applicable SLA defines the relevant monitoring record. Waiting for genuinely necessary Customer information or action may pause only the stage actually blocked by that dependency. The required action and pause start/end are recorded; other available responses continue. Routing a request between internal teams or selected infrastructure suppliers does not by itself restart the clock.

Where the technical cause is not yet known, an unverified resolution date is not presented as a firm commitment. A first-response deadline is not a permanent-resolution deadline. Changes to a remedy or estimated timing are explained together with their reason, remaining impact and next communication step.

P1 critical incidents are assessed under the 24/7 support arrangements and escalated to the necessary technical or operational lead; assessment is not deferred until weekday working hours begin. On becoming aware of the risk, the Provider contains it within its control, preserves necessary records and informs the authorised Customer contact. The initial communication states known impact, measures taken and the next update plan, distinguishing unverified information. Further notice is given when impact, scope or resolution status materially changes. Any separately accepted update interval applies.

The Customer may challenge priority, delay or closure in the same support record or through info@theartifics.com. The Provider escalates to the appropriate technical or operational lead rather than merely repeating the original reviewer's response. For third-party incidents, the parties responsible for each action are identified.

Closure explains the known cause, affected function, temporary/permanent remedy and any remaining risk or Customer action. If the issue continues, the Customer may add this to the same record and request renewed review. Prompt personal-data-breach notification and assistance duties are not deferred by the support calendar, ticket priority or closure status.

The core Guester service comprises access to the authenticated panel within the accepted scope together with the Guester API and data services it requires. Availability of the marketing website does not prove that the core service works; a running infrastructure server likewise does not prove that authorised hotel users can complete core workflows. Incident records identify affected modules separately.

When an availability commitment is separately accepted, its summary identifies the measurement period and affected account/functions. Verified periods when in-scope core functions cannot be used in proper, authorised use are recorded as downtime. Outage start, restoration time and the grounds for any excluded interval are retained. Monthly availability percentage is calculated by subtracting counted downtime minutes from total in-scope measurement minutes, dividing by those total minutes and multiplying by one hundred. Excluded intervals are treated only as defined by the previously accepted SLA.

AI response quality, freshness of an OTA's source data and the time for an action sent to Channex to take effect on an external channel are different from core panel availability. Related record, connection and data-integrity issues are investigated separately. A module outage is not arbitrarily reclassified as a full-service outage, nor a full-service outage as a minor module issue. The Customer may provide its own timestamp/error records; the Provider shares the relevant measurement summary and explains any disagreement.

Planned maintenance expected to cause material interruption is announced to the authorised Customer contact or account notification channel before work starts. The notice identifies affected functions, maintenance purpose, planned start and end, expected impact and any workaround. Any separately accepted advance-notice period, maintenance window or maximum maintenance downtime for the period applies. Planning reasonably considers the hotel's busy operational periods.

Maintenance does not authorise an open-ended outage. If the announced window is expected to be exceeded, the reason, remaining impact and revised communication/work plan are provided. The Provider reduces risk through appropriate testing, safe rollback and change records; where rollback is unsuitable, the reason and alternative measures are assessed.

Calling an outage maintenance does not automatically exclude it from SLA measurement. Planned maintenance may be excluded only where the accepted service-level summary defines a limited exclusion and its conditions are met. No general unlimited maintenance exclusion applies to unannounced work or time beyond the notified window.

An active security risk, loss of data integrity or risk of actions for the wrong property may require necessary and proportionate intervention without waiting for advance notice. This does not permit ordinary development to be labelled emergency maintenance. The cause, affected scope, measures and follow-up plan are explained as soon as reasonably possible; sensitive security details need not be publicly disclosed.

A suspended external action or connection is re-enabled only after risk assessment and appropriate checks. The Provider preserves incident and decision records; the Customer applies the necessary security steps explained for its own accounts or connections. The measurement effect of emergency work remains subject to accepted SLA rules; an emergency label does not erase all downtime records.

Guester is the Customer's first support contact for Channex, PMS, OTA, AI and email issues. The Provider remains responsible for its own connection, mapping, authorisation, error handling and management of its selected infrastructure. An outage of a selected private-cloud, data-centre or other downstream supplier does not remove all responsibility merely because it originates with a third party; applicable measurement boundaries and contractual provisions are assessed.

Hotel local internet or hardware, unsupported modifications, invalid credentials or a quota/access restriction controlled directly by an external platform may affect the relevant target only to the extent they actually cause the incident. Grounds and affected intervals are recorded. These exclusions do not conceal the Provider's faulty integration, impact worsened by its negligence or a known risk it was responsible for managing.

Receipt of an API request is not equivalent to successful application on an external channel. Channel acceptance, mapping and result confirmation are assessed for the relevant action; human checks or alternatives are explained where needed. Lack of full control over a third party's permanent-resolution time does not justify stopping coordination, status communication or available protective measures.

A Customer who believes a target was missed may submit the incident record, affected service and relevant interval through support. The Provider assesses its records together with Customer evidence and explains excluded intervals and its conclusion. If information is missing, the necessary information is identified. Acceptance or rejection of a missed target is not based solely on an unrecorded oral decision.

A service credit arises only if an amount/calculation, claim process and application method have been expressly accepted in the account or order summary. A later paid subscription does not create a retroactive debt or offset for the free period. A credit based on collected service fees may be zero during a free pilot; this does not remove remediation, DPA assistance, applicable contractual termination rights or legally protected rights. A pilot extension may be agreed separately through a recorded acceptance by both parties.

This document does not make service credit the exclusive remedy in every situation. Applicable liability caps, compensation and termination are governed by the Terms of Service; personal data duties are governed by the DPA. Intentional misconduct, gross negligence and legally non-excludable liability remain protected.

When the program or subscription ends, support provides assistance required by the DPA for contractual retrieval and secure exit. New development or ongoing operational support does not begin automatically. Continuing confidentiality, incident notification, legal retention and data-protection duties are unaffected by service termination.

This document has no separate signature or completion fields; the version made available at acceptance is included in the service bundle. Version: 3.2. Updated: 13 October 2026. Updating this page does not automatically amend an earlier acceptance; material changes follow the acceptance process in the Terms of Service.

All legal documents Back to document top