Terms and Conditions

The Processor provides Scisso, an appointment coordination and SMS notification platform, to the Controller. The Processor processes personal data on behalf of the Controller for the duration of the Controller's use of the Service. Upon termination, data is handled in accordance with Section 6.10 below.

The Processor processes personal data for the following purposes, solely on the Controller's documented instructions:

• Storing and managing client records (names, contact details, appointment history)
• Sending SMS notifications (confirmations, reminders, rescheduling notices, cancellation notices) via third-party SMS gateway providers or via the Controller's on-premises Android relay device, in the order the Controller configures
• Synchronising appointments with Google Calendar when enabled by the Controller
• Matching Google Calendar events to existing client records using email addresses, calendar colour codes, event title keywords, or client names and telephone numbers written in the event
• Sending promotional SMS messages to clients who have provided explicit opt-in consent via the booking form or other mechanisms configured by the Controller
• Producing business statistics and lists for the Controller's staff, including lists of named clients (for example clients overdue for a visit)
• Handling data subject requests about the Controller's client data that data subjects submit to the Processor directly: confirming that the requester controls the telephone number or email address given, identifying the Controller's client records that match it, and delivering the request to the Controller through the Service, as described in Section 6.5(e)
• Facilitating online payment collection during booking by creating and managing payment objects (customers, payment and setup intents, invoices, refunds and credit notes) on the Controller's connected Stripe account, storing encrypted client billing details on the client record, and processing refunds and cancellations per the Controller's configured refund policy
• Sending email notifications to clients (booking received, confirmations, reminders, changes, cancellations, declined requests, replies to change requests, refunds) and one-time codes
• Running the Controller's online booking page, client waitlist, and the pages where a client manages a booking or updates their details, including recognising a returning client on a device the client chose to be remembered on
• Notifying the Controller's staff in the app and by push notification, email or SMS

• Client names (first name, last name) and form of address
• Client phone numbers (encrypted at rest using AES-256-GCM)
• Client email addresses (encrypted at rest using AES-256-GCM)
• Client date of birth (encrypted at rest using AES-256-GCM), when collected by the Controller
• Client language preference
• Staff comments on clients and on appointments, encrypted at rest (AES-256-GCM). Free text written by the Controller's staff; it may contain personal data. They are included in data exports and permanently deleted upon client erasure.
• Appointment dates, times, services, prices and status, who booked or cancelled them, and their change history; clients' change requests and waitlist entries
• SMS and email notification metadata (type, status, timestamp, delivery report). SMS content and recipient phone number are deleted immediately after sending.
• Client billing address (street, city, county/state, postal code, country), encrypted at rest using AES-256-GCM, when collected during online booking with payment
• Client company details (company name, tax identification number, trade register number), encrypted at rest using AES-256-GCM, when the client identifies as a company during payment booking
• Phone and email verification timestamps, recording when a client verified ownership via OTP during booking
• Stripe customer identifiers on the Controller's connected Stripe account, stored with the appointments paid online
• Payment metadata on appointments: payment status, payment amount, Stripe reference identifiers (opaque IDs, not card details) and the token behind the client's manage link
• Notes a client writes when booking online, joining a waitlist or asking to change an appointment. Stored as written (not encrypted) and shown to the Controller's staff.
• Titles and descriptions of events read from the Controller's Google Calendar, and client names and telephone numbers read from them. Titles are stored as written; telephone numbers read from them are encrypted at rest.
• Contact details a client types while booking that differ from the client's record, kept with the booking until staff resolve them.
• Opt-out and suppression lists: for SMS the telephone number, encrypted at rest; for email a keyed hash of the address, never the address itself.
• Records of consent and of the terms a client accepted: what was accepted or agreed to, its version and wording, when, and through which page; and every withdrawal.
• Data about the Controller's staff, entered by the Controller or by the staff members themselves: names, nickname, title, short biography, photo, date of birth (for age verification), sign-in email address, telephone number, connected Google account address and calendar, working hours and days off, device push tokens, sign-in sessions and AI assistant connections, and their own consents.
• A hashed token identifying a device on which the client chose to be recognised when booking.

• Clients of the Controller's business who have appointments or are registered in the system
• Individuals whose contact details are entered by the Controller's staff for appointment management purposes
• The Controller's staff (owners, receptionists and other members), for the data in Section 6.3, item 20
• People a client books an appointment for, whose name the booking carries

The Service is not designed to process special categories of personal data within the meaning of Article 9 GDPR, in particular data concerning health. The Controller shall not record such data in free-text fields, comments, booking notes or calendar event titles, and is responsible for having a lawful basis under Article 9(2) GDPR for any such data it nonetheless records.

In accordance with Article 28(3) GDPR, the Processor shall:

• (a) Process only on documented instructions. The Processor shall process personal data only on the Controller's documented instructions, including with regard to transfers of personal data to a third country, unless required to do so by EU or Member State law to which the Processor is subject. In such a case, the Processor shall inform the Controller of that legal requirement before processing, unless the law prohibits such notification on important grounds of public interest. If the Processor considers that an instruction infringes GDPR or other applicable data protection law, the Processor shall promptly inform the Controller and may suspend the relevant processing until the Controller confirms or modifies the instruction.
• (b) Ensure confidentiality. The Processor shall ensure that all persons authorised to process personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.
• (c) Implement security measures. The Processor shall implement all measures required pursuant to Article 32 GDPR (security of processing), as described in Section 6.7 below.
• (d) Respect sub-processor conditions. The Processor shall not engage another processor without the Controller's prior general written authorisation. The conditions for engaging sub-processors are set out in Section 6.6 below.
• (e) Assist with data subject rights. The Processor shall, taking into account the nature of the processing and insofar as this is possible, assist the Controller by appropriate technical and organisational measures in fulfilling its obligation to respond to requests to exercise data subject rights under Chapter III GDPR. The Service provides built-in tools for access, export (portability), rectification, restriction and erasure. Where a data subject submits a request to the Processor directly, the Controller instructs the Processor to: (i) confirm, by a one-time code sent to the telephone number or email address the requester gives, that the requester controls it, which confirms control of that contact detail and not the requester's identity; (ii) search the Controller's client records, excluding erased records, for that telephone number (compared in international format) or email address (compared without regard to letter case) and, where a record matches, deliver the request to the Controller without undue delay through the data request list in the Service, linked to the matching record and showing the date of receipt and the date a response is due; (iii) remind the Controller before that date, and notify the Controller's account owner by email if the request is not marked as answered by then; and (iv) acknowledge receipt to the requester without identifying the Controller or any other business. The Processor shall not respond to the substance of the request on the Controller's behalf, and shall not erase, restrict or alter the Controller's client records in response to it. The Processor shall not disclose to the Controller whether the requester is a client of any other business, nor disclose to any other business that the requester is a client of the Controller. If the Controller has not marked the request as answered by the date a response is due, and a matching record was created, verified or booked within the two years before the request, the Controller authorises the Processor to give the requester the Controller's business name and contact details, so that the requester can follow up with the Controller or complain to a supervisory authority. The Processor handles the request record itself, and any part of a request that concerns personal data it processes as a controller in its own right, as a controller, as described in the Privacy Policy. Each delivery, reminder and closure is recorded in the Service's audit log without personal data.
• (f) Assist with compliance obligations. The Processor shall assist the Controller in ensuring compliance with Articles 32 to 36 GDPR (security of processing, notification of a personal data breach, communication to data subjects, data protection impact assessment, and prior consultation), taking into account the nature of processing and the information available to the Processor.
• (g) Delete or return data. At the choice of the Controller, the Processor shall delete or return all personal data after the end of the provision of services, and delete existing copies unless EU or Member State law requires continued storage. See Section 6.10.
• (h) Demonstrate compliance. The Processor shall make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Article 28 GDPR and allow for and contribute to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller. See Section 6.9.

The Controller grants the Processor general written authorisation to engage sub-processors for the purposes described in this DPA. The Processor currently uses the following sub-processors:

KodeKind also uses the following providers for its own relationship with the Controller, or as an independent controller, and not to process the Controller's client data on its behalf:

When the Controller's Android relay device is used, SMS messages are delivered via the device's native SMS system and no third-party gateway processes the recipient's phone number or message content. Because the relay application is not the device's default messaging app, Android keeps a copy of each sent message in the device's message history, and replies from clients are kept by its messaging app, until someone deletes them on the device, which is under the Controller's control. When a third-party SMS gateway (SMSAdvert) is used, the recipient's phone number and message content are transmitted to the gateway, which processes them to deliver the message and report its delivery, and keeps them only as long as its data processing agreement allows. The Controller can configure which providers are active and their priority order.

The Processor shall inform the Controller of any intended addition or replacement of a sub-processor, or of a new use of an existing one, at least 30 days in advance, by email and on the list of legal documents and sub-processors at https://scisso.app/en/legal/. The Controller may object on reasonable data protection grounds within that period. If the parties cannot resolve the objection, the Controller may terminate the Service with effect before the change and receives a pro-rata refund of fees paid for the period after termination (see also Section 15). Where a sub-processor must be replaced urgently for security or continuity, the notice may be shorter, and the Processor shall give it as soon as possible.

Where the Processor engages a sub-processor, the same data protection obligations as set out in this DPA shall be imposed on the sub-processor by way of a contract, in particular providing sufficient guarantees to implement appropriate technical and organisational measures. The Processor remains fully liable to the Controller for the performance of the sub-processor's obligations.

The Processor implements the following measures pursuant to Article 32 GDPR to ensure a level of security appropriate to the risk:

• Encryption at rest. Client phone numbers, email addresses, dates of birth, and billing details (address, company name, tax ID) are encrypted using AES-256-GCM with unique random initialisation vectors per record. Staff comments are encrypted using the same method. SMS job phone numbers and message bodies are similarly encrypted. Google OAuth refresh tokens are encrypted at rest. Encryption keys are stored outside the database.
• Encryption in transit. All data is transmitted over HTTPS/TLS between browser and server. Traffic is routed through Cloudflare, which terminates TLS at its edge (Section 6.6). The connection between server and Android relay device uses an encrypted WebSocket (WSS) connection.
• Access control. Role-based access control restricts data visibility. By default, employees see in full only the clients they work with; a search finds other clients of the business with their contact details masked, and an owner may let employees see colleagues' clients and bookings. Employee management and answering data subject requests delivered under Section 6.5(e) are restricted to owners; receptionists can erase or export an individual client.
• Authentication. Passwords are hashed using bcrypt (12 rounds). Each sign-in starts a session that ends after about 7 days without use and at most 30 days after sign-in, carried in httpOnly, Secure, SameSite cookies; signing out ends it. The read-only token used by the home-screen widget of the mobile app belongs to the session of the phone it is on: it ends when someone signs out on that phone, at the latest 30 days after that sign-in, and when the password or two-step settings change. Two-factor authentication (TOTP) is available for all users. TOTP secrets and backup codes are encrypted at rest using AES-256-GCM. Changing a password or two-step settings ends every other session. Android relay devices authenticate via API keys stored as bcrypt hashes on the server.
• Data minimisation. SMS message content and recipient phone numbers are deleted immediately after the message is sent, or after all retry attempts are exhausted, and are never retained while awaiting a delivery report. When a third-party SMS gateway is used, only the recipient phone number, the message body and a delivery-report address carrying a message reference are shared with the gateway. No client profile data or organisation metadata is transmitted. Personal data is automatically redacted from application logs. Audit logs contain only event types, record identifiers, coarse context (for example a country code) and timestamps.
• Infrastructure security. All servers are hosted within the European Union. Database access is restricted to the application server. Rate limiting is applied to all public-facing endpoints to prevent abuse.
• Resilience and recovery. Database backups are made daily, encrypted, kept within the European Union, and deleted after 30 days. Erasures of client records and of accounts, and opt-outs, are also recorded outside the database, so that restoring a backup does not undo them. The SMS delivery system retries automatically with exponential backoff (up to 10 attempts). A daily cleanup job removes any sensitive data that was not cleared in real time.
• Audit trail. Changes to personal data, exports, erasures, grants of access, and any access through a link or token outside a signed-in session are recorded in an append-only audit log that contains identifiers and coarse context only (for example a country code). Routine reading within the signed-in Service is not logged.

The Processor shall notify the Controller without undue delay and, where feasible, within 48 hours after becoming aware of a personal data breach affecting the Controller's data. "Becoming aware" means the point at which the Processor has a reasonable degree of certainty that a security incident has resulted in personal data being compromised, not mere suspicion. Information may be provided in phases as it becomes available. The notification shall include, to the extent available:

• A description of the nature of the breach, including the categories and approximate number of data subjects and personal data records concerned
• The name and contact details of the point of contact from whom more information can be obtained
• A description of the likely consequences of the breach
• A description of the measures taken or proposed to address the breach, including measures to mitigate its possible adverse effects

The Processor shall cooperate with the Controller and take reasonable steps to assist in the investigation, mitigation, and remediation of any data breach. The Processor shall document all personal data breaches, including the facts, effects, and remedial actions taken. Notification of a breach is not an acknowledgement of fault or liability.

Audits under Article 28(3)(h) GDPR take place as follows:

• (a) The Processor shall make available on request, free of charge, the information necessary to demonstrate compliance with Article 28 GDPR, including a description of its security measures, the sub-processor list, and a completed security questionnaire.
• (b) Where that information is reasonably insufficient, the Controller may audit, itself or through an independent auditor bound by confidentiality who is not a competitor of the Processor. The Processor may object to an auditor only on those grounds, and the Controller then appoints another. Audits take place no more than once in any 12 months, on 30 days' written notice, during business hours, and remotely unless an on-site inspection is reasonably necessary.
• (c) The 12-month limit and the notice period do not apply where a supervisory authority requires the audit, after a personal data breach affecting the Controller's data, or where the Controller has reasonable indications of non-compliance.
• (d) Each party bears its own costs. The Controller reimburses the Processor's reasonable, documented costs of an on-site audit beyond one business day, estimated in advance, except where the audit falls under (c) or reveals a material breach by the Processor.
• (e) The Controller may contest the scope, method and results of an audit, and the Processor shall remedy identified non-compliance without undue delay. Information obtained in an audit is confidential.

What happens to the Controller's data when the Service ends:

• (a) If the subscription or the free trial ends without the Controller closing the account (cancelled, unpaid after the payment retries in Section 7.4, or a free trial that ended without a payment method), the account becomes read-only: the Controller can still sign in, see and export its data, and answer data subject requests, but no messages are sent and nothing new is booked. About six months after the subscription or the free trial ended, the account is closed as in (b). The Controller's owner is told by email at least 14 days before.
• (b) When the account is closed, by the Controller or under (a), the Controller's personal data is erased from the Service at once, except the record in (c). The Controller should export what it needs before closing it (Section 17A). Backups are encrypted and deleted after 30 days; data in them is not restored to the Service, and if a backup ever has to be restored, erasures made since are re-applied before the Service resumes.
• (c) What KodeKind keeps after closure, as an independent controller and for one purpose only, to establish, exercise or defend legal claims (Article 6(1)(f) and Article 17(3)(e) GDPR): for each appointment, its date and time, service, price, payment status, amounts and the payment provider's references; the payment ledger; the internal identifiers that link them; the record of the Terms the Controller accepted; and the Controller's own billing details. No names, telephone numbers, email addresses, notes or comments are kept. This record is accessible only to KodeKind's administrator. Four years after the subscription or the free trial ended, or later only while a claim is pending, KodeKind deletes from it the payment provider's references, the record of acceptance and the Controller's billing details. What remains after that (appointment dates, services, prices, amounts and statuses, and the payment ledger's amounts, linked only by internal identifiers) contains no names, contact details, notes, comments or payment references. The invoices KodeKind issued to the Controller are kept in KodeKind's invoicing system for as long as accounting law requires. The Service's audit log, which records who did what and when by internal identifiers only, never names, contact details or message content, is kept after closure as KodeKind's security and accountability record.
• (d) Written confirmation of erasure is given on request.

The Controller warrants and undertakes that:

• It has a valid lawful basis under GDPR Article 6 for all personal data provided to the Processor for processing
• It has informed its clients, by appropriate means, that their data will be processed through the Service for appointment management and SMS notification purposes
• It will comply with all applicable data protection laws in its capacity as Data Controller, including responding to data subject rights requests within the timeframes required by GDPR
• It will not instruct the Processor to process personal data in a manner that would violate GDPR or any other applicable law
• It will promptly notify the Processor if it becomes aware of any circumstance that may affect the Processor's ability to comply with its obligations under this DPA
• It will respond to each request delivered to it under Section 6.5(e) within one month of the date the Processor received the confirmed request, as shown on the request in the Service. The parties agree that this is the date of receipt for the purposes of Article 12(3) GDPR. The Controller may extend this period only as Article 12(3) allows, and must tell the requester within the first month. Before disclosing, erasing or altering data, it will satisfy itself, to the extent reasonably necessary and proportionate, that the requester is the person the record concerns, because a telephone number or email address may be shared or may have changed hands. It will mark the request as answered in the Service once it has responded.

The Processor stores the Controller's personal data within the European Union. Some sub-processors listed in Section 6.6 process it outside the European Union, as shown there; for each, the Processor ensures appropriate safeguards under Chapter V GDPR, such as an adequacy decision (Article 45 GDPR, including the EU-U.S. Data Privacy Framework) or Standard Contractual Clauses approved by the European Commission (Article 46(2)(c) GDPR).

Each party shall be liable for damages caused by processing that infringes GDPR in accordance with Article 82 GDPR. The Processor shall be liable for damage caused by processing only where it has not complied with obligations of GDPR specifically directed to processors, or where it has acted outside of or contrary to the Controller's lawful instructions.

Where either party has paid full compensation to a data subject under Article 82(4) GDPR, it may claim back from the other party the part of the compensation corresponding to the other party's share of responsibility (Article 82(5) GDPR). Each party's aggregate liability to the other arising out of or in connection with this DPA, including any such recourse claim, is limited to the greater of three times the fees paid by the Controller in the 12 months before the event giving rise to the claim, or EUR 5,000. This limitation does not apply to damage caused intentionally or through gross negligence, to harm to life, physical or mental integrity or health, to processing outside the Controller's documented instructions, or where the law forbids it, and it never limits either party's liability to data subjects under Article 82(1) and (4) GDPR.

Scisso offers an optional feature that helps the Controller identify Google Calendar events that are likely client appointments but were left unclassified (for example, where an employee's freeform event title did not match a configured rule). To do this, the event title, with telephone numbers and email addresses removed, and the Controller's own service-catalogue labels are sent for analysis to an AI sub-processor. The following terms apply to this processing:

• (a) Data sent. Only the event title, with any telephone numbers and email addresses removed, and the Controller's service-catalogue labels with their catalogue identifiers are transmitted. An event title may contain a client's first name written in the employee's shorthand. Client lists, client records, telephone numbers and email addresses are never sent, and events are referred to by short references valid only for the request, not by Scisso record identifiers. The feature extracts a candidate name from the title; matching that name to a client is performed locally by Scisso, not by the sub-processor.
• (b) Purpose and lawful basis. The purpose is limited to classifying the Controller's own calendar events so that genuine appointments are not silently lost. The Controller determines the lawful basis for this processing; KodeKind considers the Controller's legitimate interest under Article 6(1)(f) GDPR (accurate operation of the Controller's own booking records) to be the applicable basis. The Processor performs this processing solely on the Controller's documented instructions and for no other purpose.
• (c) Sub-processor and location. Inference is performed by Scaleway SAS on infrastructure located in France (European Union), using the Mistral Small 3.2 model authored by Mistral AI (a French company). The model author does not receive the data: only Scaleway's European inference infrastructure processes it. No data is transferred outside the European Union for this feature.
• (d) Retention. Titles are processed transiently for inference. The sub-processor stores neither the prompt nor the response. Scisso stores only the resulting suggestion on the event (whether it looks like an appointment, the likely service, the client name read from the title and a reusable keyword) until staff accept or dismiss it or the event changes, plus non-personal telemetry about each call (token counts, cost, status, timestamps) for cost control and reliability.
• (e) No model training. Per the sub-processor's data-processing terms, the data sent is not used to train, retrain, or improve any model, and the content of inputs and outputs is not read, reused, or analysed by the sub-processor.
• (f) Controller control and opt-out. The feature is on unless an owner switches it off. It is governed by its own setting and by the per-organisation AI setting, either of which an owner can switch off at any time in Settings. While the feature is enabled, the Controller authorises the sub-processing described above on the basis of this disclosure; switching either setting off stops all such processing.
• (g) Flow-down and liability. The data protection obligations in this DPA are imposed on the sub-processor by way of its data processing agreement, including the security and confidentiality obligations in Section 6.7. The Processor remains fully liable to the Controller for the sub-processor's performance, as set out in Section 6.6.

This feature is advisory only. It surfaces suggestions for the Controller's staff to review; it never automatically modifies, reclassifies, or sends messages for an appointment. The Controller may disable it at any time without affecting any other part of the Service.

Scisso offers an optional feature that lets the Controller build its service catalogue from photographs or screenshots of an existing price list, instead of typing every entry by hand. Images uploaded by the Controller are sent for analysis to an AI sub-processor, which returns a draft catalogue for the Controller to review. The following terms apply to this processing:

• (a) Data sent. Only the images the Controller chooses to upload. These are expected to contain the Controller's own commercial information: service names, durations and prices. The Controller must not upload images containing client personal data; the feature does not need it and does not extract it. Image metadata, including any location recorded by the camera, is removed before transmission.
• (b) Purpose and lawful basis. The purpose is limited to converting the Controller's own price list into catalogue entries in the Service. The Controller determines the lawful basis for this processing; KodeKind considers the Controller's legitimate interest under Article 6(1)(f) GDPR (setting up and maintaining its own service catalogue) to be the applicable basis. The Processor performs this processing solely on the Controller's documented instructions and for no other purpose.
• (c) Sub-processor and location. Inference is performed by Scaleway SAS on infrastructure located in France (European Union), using the Mistral Small 3.2 model authored by Mistral AI (a French company). The model author does not receive the data. No data is transferred outside the European Union for this feature.
• (d) Retention. Images are processed transiently for inference only. No image is stored by Scisso or by the sub-processor, and no model response is retained beyond the draft catalogue the Controller is actively editing, which exists only until the Controller confirms or discards it. Scisso retains only non-personal telemetry about each call (token counts, cost, status, timestamps) for cost control and reliability.
• (e) No model training. Per the sub-processor's data-processing terms, the data sent is not used to train, retrain, or improve any model, and the content of inputs and outputs is not read, reused, or analysed by the sub-processor.
• (f) Controller control and opt-out. The feature is available unless an owner switches it off. It is governed by its own setting and by the same per-organisation AI setting as Section 6.14, either of which an owner can switch off at any time in Settings. While the feature is enabled, the Controller authorises the sub-processing described above on the basis of this disclosure; switching either setting off stops all such processing.
• (g) Flow-down and liability. The data protection obligations in this DPA are imposed on the sub-processor by way of its data processing agreement, including the security and confidentiality obligations in Section 6.7. The Processor remains fully liable to the Controller for the sub-processor's performance, as set out in Section 6.6.

This feature is advisory only. It produces a draft that the Controller reviews and edits; nothing is added to the catalogue until the Controller confirms it. Existing services, categories and prices are never modified or deleted by an import. The Controller may disable the feature at any time without affecting any other part of the Service.

Scisso offers an optional feature that lets members of the Controller's staff connect an AI assistant (for example Claude or ChatGPT) to the Controller's account and ask it about the business: its schedule, clients, catalogue and figures. When a member does, Scisso discloses limited data from the Controller's account to the provider of that assistant. This feature is separate from the AI features of Sections 6.14 and 6.15, which use a sub-processor of KodeKind in the European Union and are governed by their own settings. Switching off the organisation's AI setting also switches this feature off (see (e)). The following terms apply:

• (a) A recipient chosen by the Controller, not a sub-processor. The assistant's provider is not engaged by KodeKind, is not a sub-processor under Section 6.6, and is not listed there. Scisso discloses data to it only on the Controller's documented instruction, given by enabling this feature, and only as described below. The Controller decides which providers, and which kinds of account (for example business accounts under a data processing agreement rather than personal ones), its members may connect, and is responsible for that choice, for the provider's terms (including where it processes data and whether it uses data to train models), and for ensuring a valid mechanism under Chapter V GDPR for any transfer to a third country that the disclosure involves.
• (b) Purpose and lawful basis. The purpose is limited to letting the Controller's staff consult the Controller's own records through an assistant of the Controller's choosing. The Controller determines the lawful basis; KodeKind considers the Controller's legitimate interest under Article 6(1)(f) GDPR (running its own business) to be the applicable basis.
• (c) What may be disclosed. Only what the connected member could already see in Scisso, further limited to: client first names with the initial of the surname; per client, how many visits and missed visits they had and when their first, last and next visits are, how often they usually come, the service they book most often, whether their record has comments (without their content), and whether they can be sent offers (they agreed to receive offers from the Controller and have a working phone number or email address on file); appointment dates, times, services, prices and status (for example confirmed, pending, missed, booked online, part of a recurring series, and whether comments, a client's note or an open request exist, without their content); waitlist entries (which services a client is waiting for or that they want to move an existing appointment, on which days, and whether they were already offered a time); free time in the schedule, including whether a day is closed or fully booked and who works that day; the working hours behind it, namely the Controller's opening hours and the days it closes or changes them, and each member's working hours, days off (including those marked in a connected calendar) and extra working days, those of colleagues only to members who can see them in Scisso, and never the reason for a closure or a day off; staff nicknames or first names, and per-member business figures to owners; the service catalogue; what the Controller publishes on its booking page in Scisso, while the page is published: its name, tagline and description, phone number, website and address (the business's own, never its legal or billing details), the page's link and languages, its team members' job titles and bios, its service descriptions, and the page's translations of this text and of the service catalogue; the Controller's settings in Scisso, and each member's own settings to that member only, as switches, choices and numbers, never text anyone wrote, except the booking-page text above, and never payment settings; business figures, with revenue only to members whose role may see it; record identifiers used by Scisso; and links back into Scisso. Where two clients in one answer share a name, a masked phone number (last four digits) and a masked email address may be shown to tell them apart.
• (d) What is never disclosed. Full client surnames, full phone numbers, full email addresses, dates of birth, staff comments and notes, notes written by clients, the titles and descriptions of calendar events, the content of messages, payment and billing details, and any link that opens personal data without signing in to Scisso.
• (e) Control. The feature is off until an owner of the Controller enables it in Settings, and an owner can disable it at any time; disabling it stops all disclosure at once. Switching off the per-organisation AI setting of Sections 6.14 and 6.15 also switches this feature off and ends every connection. It is available to owners and receptionists by default; an owner can grant or refuse it individually to any member who is not an owner. Each member connects each assistant separately, after signing in to Scisso, and can disconnect it at any time; an owner can disconnect any member's assistant.
• (f) Records and retention. Scisso records each connection and, for each request that discloses client data, which clients' data was disclosed (never what was asked), for the Controller's accountability and to answer requests under Article 15 GDPR. These records contain identifiers only and are kept with the rest of the audit trail, including after the account is closed, as described in Section 6.10(c). Scisso does not keep what the assistant sends or receives beyond answering the request.
• (g) Erasure. Data already disclosed to an assistant's provider cannot be recalled by Scisso: erasing a client in Scisso stops further disclosure, and the records in (f) identify the recipients so the Controller can meet Articles 17 and 19 GDPR with them.
• (h) Data entered by members. Anything a member types into an assistant is outside Scisso and governed by the Controller's or the member's agreement with that provider.

Where the Controller connects a service under its own account and agreement with that provider, including its Google Calendar and its Stripe account (Stripe Connect), the Controller instructs the Processor to transmit personal data to that service and to receive data from it. That provider is a recipient chosen by the Controller and acts under the Controller's agreement with it; it is not a sub-processor engaged by KodeKind, and KodeKind is not responsible for its processing. The Processor's obligations under this DPA apply to the data until it reaches that service, and to the data the Processor receives back from it.

Scisso offers multiple subscription plans that differ in the number of included employees and in the monthly allowance of messages sent through the Android relay (Section 8.1). All plans include access to every feature. Current plan details and pricing are displayed during sign-up and on the billing page within the application.

• New accounts receive a 30-day free trial with full access to all features.
• You can start the trial with or without a payment method. You will not be charged during the trial.
• Before the trial ends we will email you. If a payment method is on file when the trial ends and you have not cancelled, the subscription converts automatically to the paid plan and that payment method is charged at the price shown during sign-up. If no payment method is on file, SMS sending and online booking stop when the trial ends and the account becomes read-only (Section 6.10(a)). Adding a payment method later starts the paid plan from that day, and the first month is charged at once.
• You may cancel at any time during the trial without being charged.
• By adding a payment method during or after the trial, you expressly consent to automatic conversion to a paid subscription when the trial ends, or immediately if the trial has already ended.

• Subscriptions are billed monthly in advance, on the same day each month, starting on the day the trial ends (or the day a payment method is added, if the trial ended without one).
• Charges are processed automatically via Stripe. Scisso does not store your card details. All payment data is handled directly by Stripe in accordance with PCI DSS standards.
• Adding employees beyond your plan's included amount will result in additional per-employee charges, prorated for the remaining billing period.
• When the free trial ends (Section 7.2), if a payment method is on file and you have not cancelled, the paid subscription starts automatically and that payment method is charged. Without a payment method, the account becomes read-only (Section 6.10(a)) until you add one.
• If you switch on SMS credit auto-reload (Section 7.12), your stored payment method is charged for a credit pack each time your balance falls below the threshold, until you switch it off.
• When a time-limited promotional discount ends, or when you cancel and later subscribe again, the standard price of your plan applies (Section 7.8).
• Fees already charged are not refunded, including for unused time in a billing period and for SMS credits, except where these Terms (for example Sections 7.10, 7.11, 17 and 18) or the law provide otherwise.
• Message costs that the law makes us add are yours, like any other message: the longer messages caused by the opt-out link (Section 8.5.1) and the automatic replies to HELP (Section 8.5.3) are charged as carrier costs on your relay SIM or as SMS credits.

• If a renewal payment fails, the subscription and the account keep working while Stripe retries the payment automatically, and the account owner is told.
• You can update your payment method from the billing page at any time.
• If the payment still fails after the automatic retries end, or a card confirmation your bank requires (for example 3D Secure) is not completed within 15 days, the subscription is cancelled: SMS sending and online booking stop, Google Calendar connections and the Android relay are disconnected, and the account becomes read-only (Section 6.10(a)).
• Your data is not deleted straight away. The account stays read-only, and you can still sign in, export your data and resubscribe, for about six months. After that the account is closed as described in Section 6.10, and we email the owner at least 14 days before. Once an account is closed it cannot be reactivated.

• You may cancel your subscription at any time from the billing page.
• Cancellation takes effect at the end of the current billing period. You will retain full access until then.
• No partial refunds are issued for unused time within a billing period, except as required by applicable law.
• After the billing period ends, SMS sending and online booking stop, Google Calendar connections and the Android relay are disconnected, and the application becomes read-only (Section 6.10). Section 7.4, item 4 then applies.
• If you are entitled to a statutory right of withdrawal under applicable consumer protection law, you may exercise it within 14 days of your initial subscription by contacting us at the email address below. Because the first 30 days are a free trial, nothing is charged in that period, so withdrawing costs nothing.

Subscription fees are non-refundable except where these Terms or applicable law provide otherwise. If you believe you have been charged in error, please tell us at [email protected], ideally within 14 days of the charge, so that we can correct it quickly. This does not limit any right you have under the law.

We may adjust subscription pricing to reflect changes in our operating costs, infrastructure costs, regulatory requirements, or general market conditions. Prices will not increase more than once per 12-month period.

We will notify you by email at least 30 days before any price increase takes effect. The notification will state the new price and the date it takes effect. If you do not agree to the new pricing, you may cancel your subscription before the new price takes effect and will not be charged the increased amount. New pricing applies only from the next billing cycle after the notice period ends.

• Scisso may offer promotional codes that provide a percentage discount on subscription fees. Promotional codes are issued at our sole discretion and may be subject to conditions such as plan restrictions, single-use limits, expiration dates, or maximum redemption caps.
• Promotional discounts apply exclusively to recurring subscription charges: the base plan fee and additional per-employee fees. They do not apply to any pay-per-use fees, usage-based charges, or third-party service costs such as SMS delivery fees.
• Time-limited promotional discounts apply for the stated number of billing periods. Once the promotional period ends, your subscription will automatically renew at the standard rate for your plan. The applicable post-discount price is displayed during sign-up.
• Promotional codes have no cash value, are non-transferable, and cannot be combined with other offers or codes unless explicitly stated.
• We reserve the right to deactivate or revoke any promotional code at any time for any reason, including suspected abuse or fraud. If a code is revoked before its stated promotional period ends, the discount will continue to apply for the remainder of the originally stated duration.
• Promotional discounts do not survive cancellation. If you cancel your subscription and later resubscribe, the standard pricing for your chosen plan will apply unless a new promotional code is used.

To issue invoices, we need your billing details: billing type (company or individual), company name, tax identification number, VAT number (if applicable), and billing address. They may be added after sign-up and are needed before the first charge. This information is stored on your account and shared with Stripe for payment processing and with our invoicing provider (SmartBill, Section 6.6) to issue the invoice. You may update your billing details at any time from the billing page.

The operator is registered for VAT in Romania. All prices displayed during sign-up and within the application are exclusive of VAT and are marked "+ VAT". VAT is calculated when the invoice is issued, based on your billing country, business status and VAT number (if provided), and is shown on the invoice. If you provide a valid EU VAT identification number, it will be verified and recorded on your account. Intra-EU B2B transactions where the customer provides a valid VAT number are subject to the reverse charge mechanism. You are responsible for any local taxes, duties, or levies applicable in your jurisdiction beyond what is collected by us.

Third-party SMS providers (such as SMSAdvert) require prepaid SMS credits. Credits are a prepayment for the SMS delivery service of Scisso, counted in abstract service units; they are not stored monetary value or electronic money. They are redeemable only for SMS delivery through Scisso and cannot be transferred, cashed out, or used for any other purpose.

• Credits are purchased in fixed packs via a one-time Stripe payment, in the currency set out at the start of Section 7. Available pack sizes and prices are displayed on the SMS settings page within the application.
• Credits are non-expiring. Purchased credits remain on your account indefinitely.
• Credits are non-transferable between organisations.
• Each SMS consumes credits based on the destination country and the number of message segments. The applicable credit cost per segment for each country is published within the application and may be updated from time to time (see Section 7.11).
• Credits are deducted at the time a message is routed to a paid provider. If a message permanently fails after all retry attempts, the credits consumed for that message are automatically refunded to your balance.
• If your credit balance is too low for a message, the paid provider is skipped and the next provider in your chain is tried. If none can send it, the message waits for credits or for the relay to come back, or is retried, and is not sent if neither happens before it stops being relevant (for example once the appointment has started) or before the retries run out.

Withdrawal right and waiver. If applicable law treats you as a consumer, you may have the right to withdraw from a credit purchase within 14 days without giving any reason (Directive 2011/83/EU, transposed in Romania by OUG 34/2014). Because credits are added to your account at once, each purchase asks you, in a separate unticked box, to request immediate delivery and to acknowledge that you lose the right of withdrawal once the credits are added. A purchase cannot be made without it. Your consent and its date are recorded with the purchase and printed on its invoice. If the law nonetheless gives you a right of withdrawal for credits you have not used, we refund the unused credits at the price you paid when you withdraw within 14 days of the purchase.

Refund policy. Subject to the paragraph above and to Section 17, SMS credit purchases are non-refundable. This does not affect your rights under applicable law if the SMS delivery service is materially impaired or discontinued and you are unable to use your credits: you are then entitled to a proportionate price reduction or, where the failure is not minor, to end the purchase and receive a refund for unused credits. If you believe you have been charged in error, contact us at [email protected].

VAT treatment. SMS credits are treated as a prepayment for a known service. VAT (where applicable) is charged at the time of purchase and reflected on the invoice.

The number of credits consumed per SMS segment varies by destination country. We may adjust these rates to reflect changes in our upstream provider costs. Rate adjustments are not retroactive and do not affect credits already consumed.

We will notify you by email at least 30 days before any rate increase takes effect. The notification will state the affected countries, the new rates, and the effective date. If you do not agree to the new rates, you may request a refund of your remaining unused credits at the per-credit price you originally paid, provided the request is made before the new rates take effect. After the new rates take effect, remaining credits are consumed at the new rates.

You may optionally enable auto-reload, which automatically purchases a credit pack when your balance drops below a threshold. Auto-reload is disabled by default and requires explicit activation from the SMS settings page.

• The reload threshold is calculated dynamically based on your organisation's country (approximately 10 messages worth of credits).
• When auto-reload is triggered, your stored payment method is charged for the selected credit pack. A Stripe invoice is generated for each auto-reload charge.
• Switching auto-reload on asks you, in the same way as Section 7.10, to request immediate delivery of each automatically reloaded pack and to acknowledge that you lose the right of withdrawal once its credits are added. Auto-reload cannot be switched on without it. Your consent and its date are recorded and printed on the invoice of each pack reloaded after you gave it. Switching auto-reload off withdraws the consent for future packs.
• You may disable auto-reload at any time from the SMS settings page. Disabling auto-reload does not affect credits already purchased.

When you enable online payments via Stripe Connect, payments are processed directly on your connected Stripe account. Scisso does not charge any platform fee or commission on payment transactions. The only fees that apply are Stripe's own processing fees, which are charged by Stripe directly to your connected account according to Stripe's published pricing.

• Online payments support deposits, prepayments, and the client's choice between them, processed through the booking page.
• When a payment is refunded, the client receives the amount refunded under your refund policy. Stripe's processing fee is not deducted from it and is not returned to you by Stripe (this is Stripe's standard policy and is not within our control).
• You may disconnect your Stripe account at any time from the payments settings page. When you disconnect it in Scisso, we automatically try to refund outstanding payments on upcoming appointments as part of the disconnect; check your Stripe account afterwards, since a refund that fails must be completed there. Disconnecting from Stripe's own dashboard instead refunds nothing. Disconnecting disables all payment modes on your services.
• Online payments are available on all subscription plans. No additional monthly fee is charged for the payment feature.
• If we ever introduce a fee on payment transactions, it applies to you only after you accept it expressly in the Service; until then you may keep using online payments without it.

The Android relay uses a device physically located on your premises (the "Relay") to send SMS via your mobile carrier's SIM card. Messages are sent from your own business phone number. Scisso does not charge for messages sent this way up to your plan's monthly relay allowance, shown on the pricing and billing pages (currently 300 messages per employee per billing period on the Startup plan, and unlimited on the other plans). Once the allowance is used up, messages go through the next provider in your chain, a paid provider using SMS credits; if there is none, they are held or not sent until the allowance renews. Relay messages may be spaced a few seconds apart. You are solely responsible for all carrier costs (per-message charges, bundle usage, and any carrier fees).

Relay delivery depends on factors outside our control, including: the device being powered on and connected to the internet, mobile network availability, recipient phone number being active and reachable, SMS not being filtered by the recipient's carrier, and the Android operating system not terminating the relay application due to battery optimisation or system updates.

The Relay is your equipment, on your premises, under your control. Keeping it available is your responsibility, as set out in Section 4. We do not operate the Relay and we do not guarantee any level of Relay availability or uptime. Scisso displays the Relay's connection status in your settings and sends best-effort notifications when the device has appeared offline for an extended period or reports a low battery. Those notifications depend on the device reporting its status and on push delivery reaching you, are provided as a convenience only, are not guaranteed, and do not transfer responsibility for Relay availability to us.

The Relay will be unavailable at times, for reasons including power cuts, loss of internet or mobile coverage, the device being switched off, moved, or taken off the premises, the operating system terminating or updating the relay application, device failure, and carrier issues. A paid provider can be configured as a backup in your chain (Sections 8.2 and 8.3) precisely so that messages continue to be sent while the Relay is offline, subject to your SMS credit balance. Whether to keep a funded backup provider active is your decision. If you operate the Relay as your only provider, or your credit balance is insufficient while the Relay is offline, messages will not be sent, and client replies (such as STOP or HELP) that reach the Relay while it is offline are not received. Section 15 sets out our liability for the Relay being unavailable.

Your mobile plan must permit automated sending. Mobile operators across the EEA commonly limit ordinary mobile subscriptions, consumer and business alike, to personal or manual use, and some define improper use to include any message that is not written and sent by hand. In our review of the standard terms of the main mobile operators in Romania and Italy, every one prohibited or restricted automated sending from ordinary subscriptions, and at least one operator has blocked a business's number for it. You should assume your plan does not permit the Relay unless your operator confirms in writing that it does.

The contract with your mobile operator is yours, not ours. Before enabling the Relay, it is your responsibility to check your operator's terms and, where they require it, to move to a plan or product that permits automated messaging. Operators commonly sell a dedicated bulk-SMS or business-messaging product for exactly this purpose. Before a Relay can be paired, Scisso shows this warning and records that an owner confirmed it, when, and which version of the warning was shown.

If your operator restricts, suspends or terminates your subscription, or charges you differently, because messages were sent automatically, that is a matter between you and your operator (see Section 15). A paid SMS provider can be configured instead of or alongside the Relay (Sections 8.2 and 8.3); those routes do not use your own SIM and are not subject to your mobile plan's terms.

When configured, Scisso can route SMS through a third-party SMS gateway (currently SMSAdvert, shown in the app as SMS Direct) as a fallback or primary provider. Messages sent via the gateway are delivered from the gateway's own sender (not your business phone number), but the message content identifies your business by name.

Gateway delivery requires prepaid SMS credits (see Section 7.10). Credits are deducted when a message is routed to the gateway. The cost per message depends on the destination country and message length (number of segments). If your credit balance is insufficient, the gateway is skipped and the next available provider in your chain is tried.

Gateway delivery depends on the third-party provider's infrastructure and the downstream carrier networks they use. We do not operate or control the gateway infrastructure.

You configure which providers are active and their priority order. When an SMS is dispatched, Scisso selects the first available provider in your chain. Once a provider is selected for a message, all retry attempts for that message use the same provider. This prevents duplicate deliveries that could occur if a message were re-routed mid-lifecycle.

If no provider in your chain can send a message (for example, the relay is offline and your credit balance is insufficient for the gateway), the message waits for credits or for the relay, or is retried, and is not sent if neither happens before it stops being relevant or before the retries run out. Section 15 sets out our liability for undelivered messages.

We do not guarantee SMS delivery via any method. Undelivered messages are retried automatically (up to 10 attempts with increasing delays). To protect your clients, at most 6 SMS and, separately, 6 emails about appointments are sent to one client in any 24 hours; messages over that limit are not sent. One-time codes the client asks for are not limited this way. Factors affecting delivery include mobile network conditions, carrier filtering, recipient phone status, and third-party provider availability. Scisso is an appointment coordination platform, not a telecommunications provider. SMS delivery is a feature of the platform, not a standalone communications service.

Clients can opt out of SMS at any time using the methods described below. Once a client opts out, Scisso will not send them further SMS from your business, even if their phone number is re-entered into the system, until they choose to receive messages again (for example by replying START) or an owner or receptionist switches SMS back on for their record. One-time security codes that the client requests themselves (for example to sign in or confirm a change) are still sent.

By connecting a Google Calendar, you authorise Scisso to perform the following actions on the connected calendar:

• Create events when an appointment is created in Scisso (including from online booking requests), with appointment details such as client name, service, and time
• Update events when an appointment is rescheduled, confirmed, or modified in Scisso (including updating titles, times, descriptions, and status indicators)
• Delete events when an appointment is cancelled or a pending booking is rejected in Scisso
• Set extended properties (private metadata) on events created by Scisso, used to link events back to Scisso records (e.g., customer ID, service ID). These properties are not visible in the Google Calendar UI but are stored on the event.
• Read events from the connected calendar via webhook notifications, to detect appointments created or modified directly in Google Calendar and sync them into Scisso
• Match events to clients using attendee email addresses, calendar colour codes, event title keywords, or client names and telephone numbers written in the event. This matching is best-effort and may require manual review.

In short: creating, rescheduling, confirming, or cancelling appointments in Scisso will create, modify, or delete corresponding events in the connected Google Calendar. Changes made directly in Google Calendar will also be synced back into Scisso.

The Google Calendar API is a third-party service operated by Google LLC and subject to Google's own terms and availability. We make no representations or warranties regarding:

• The continued availability of the Google Calendar API
• The accuracy or timeliness of calendar data synchronisation
• Webhook delivery delays or failures caused by Google's infrastructure
• Changes Google makes to its API that may affect Scisso functionality

Section 15 sets out our liability for Google Calendar outages, delays or changes.

While Scisso is designed to sync calendar data accurately, software bugs, network failures, API changes, or race conditions may occasionally cause unintended outcomes, including but not limited to:

• Events being created, modified, or deleted in your Google Calendar in error
• Duplicate events, missing events, or events with incorrect details
• Extended properties being set, modified, or lost on events
• Sync delays causing stale data to be displayed or acted upon
• Recurring event series being partially or incorrectly updated

Section 15 sets out what we are liable for when this happens.

You are responsible for maintaining your own backups or records of critical scheduling information (for example by exporting your data) and for verifying that calendar data is accurate. You may disconnect your Google Calendar at any time from your profile settings.

Scisso provides a public booking page where prospective and existing clients can browse your services, select an employee, choose a date and time slot, and submit a booking request. Online booking is subject to the following:

• Booking requests are submitted as pending and require explicit confirmation or rejection by the business within the response window you set (by default 4 business hours). Scisso does not automatically confirm bookings on your behalf.
• Pending bookings not confirmed or rejected within that window are rejected automatically; the client is told (unless you have switched those messages off), and any payment taken is refunded in full.
• A booking request does not create a binding appointment or any contractual obligation between Scisso and the client. The booking is a request only. The business decides whether to accept or reject it. When a payment-enabled service requires a deposit or prepayment at booking, the payment is a transaction between the client and the business (see Section 2). If the business rejects the request, does not answer in time, or cancels the appointment itself before it starts, the client gets back everything they paid; the business's refund policy applies when the client cancels or does not come. The policy that applies is the one shown when the client paid: a change to the refund policy applies only to bookings paid after it.
• When a booking is submitted, a corresponding event is created in the assigned employee's Google Calendar (if connected) with a visual pending indicator. The indicator is removed upon confirmation and the event is deleted upon rejection.
• The online booking form is protected by Cloudflare Turnstile, which looks at the visitor's browser and connection (including the IP address) to tell people from bots, to prevent automated abuse (Section 6.6).
• The booking page displays your business name, logo, address, phone number, employee names, employee titles and biographies, service names with descriptions and pricing, and available time slots. If an owner fills in the business details in the Service (legal name, legal form, registered address, trade register number, tax ID, VAT number and a public email), they are shown with the business phone number under "Business details" on the booking, booking management and client update pages, and before the client sends a booking. You are responsible for ensuring all this information is accurate and up to date.
• Available time slots are calculated based on your configured shop hours, existing appointments, and blocked time. Slot resolution (15, 30, or 60 minutes) is configurable. Scisso checks the slot again when the booking is submitted; paid bookings hold the slot for 10 minutes while the client pays. In rare cases two simultaneous requests may still overlap, and you must resolve them.
• The booking form asks for optional consent to promotional messages, unticked by default. Appointment messages (confirmation, reminder, changes) are part of the booking and can be switched off by the client at any time. You are responsible for honouring these choices and for ensuring that any promotional messages comply with applicable electronic communications regulations (including the ePrivacy Directive).
• Clients may include a free-text note with their booking request. This note is visible to your staff. You are responsible for ensuring that notes are handled appropriately and not used to collect sensitive personal data beyond what is necessary.
• You may enable or disable online booking at any time from the settings page. When disabled, the booking page is not available.
• When a service takes payment (a deposit, full prepayment, or the client's choice between them) and your Stripe account is connected, the booking form includes additional steps: billing details (address, optional company information), a Stripe payment form, and your cancellation and refund policy. Email is asked for on payment-enabled services. Billing details are encrypted and stored on the client record. Card details are collected by Stripe and never pass through Scisso servers.
• If you enable client self-service (on by default for new accounts), a client who books online can use a secure manage link (sent by SMS and/or email) for each booking. Depending on your settings, it lets them view the appointment and cancel or move it, either at once or as a request you approve. Before acting, they confirm the phone number on the booking, and a one-time code is required when the cancellation affects a payment. Cancellations follow your refund policy, as described in item 3. You are told in the app and by push notification.
• You are the trader towards your clients. You are responsible for entering accurate details identifying your business as a trader (Section 10.1, item 6), and for your own duties under consumer protection law: your offers, prices (including VAT where required), cancellation, refund and deposit policies, promotions, and the information you must give clients before they book or pay, including any right of withdrawal. The Service provides tools; it does not check your compliance.

Each employee may have a personalised booking URL (a "booking slug") that links directly to their availability on the booking page. Booking slugs are generated from the employee's first name. These URLs are publicly accessible when online booking is enabled.

When a client submits a booking, Scisso may send the following SMS notifications on behalf of the business:

• Booking received - sent to the client confirming that their booking request has been received and is pending review by the business
• Booking rejected - sent to the client if the business rejects their booking request

If the booking is confirmed, the standard appointment confirmation SMS is sent (see Section 8). Each of these SMS types can be individually enabled or disabled by the business.

Scisso generates QR codes that encode URLs for the booking page, client registration forms, and client record update forms. QR codes are generated entirely within the browser and are not transmitted to or stored on Scisso servers. You may download and print QR codes for display in your business premises. The business is solely responsible for the placement, display, and removal of printed QR codes.

When the business is outside of its configured shop hours, the booking page may offer visitors the option to save the business contact details as a vCard file (.vcf). The vCard contains the business's name and contact details (phone, and address and website where set). vCard files are generated in the browser and are not stored on Scisso servers.