heqticTill appen

Customer Agreement

Svensk version

This is an English translation of Heqtic's Swedish customer agreement (kundavtal), provided for a customer whose own language is English. This agreement is drafted and executed in Swedish. In the event of any discrepancy between this translation and the Swedish original, the Swedish text prevails. The pages this agreement links to below — the integrations page, the sub-processor list, the security page, the privacy policy, and the change log — each have their own English translation too; the change log's own per-entry history remains Swedish (see that page for why).

The general terms for working together between Heqtic and you as a customer — roles, responsibilities, and how personal data is handled between us. Version 2026-10-15.

This agreement supplements the order and payment terms, which govern price, invoicing, and contract term. In the event of a conflict between the two documents, this customer agreement prevails, except on questions of price, payment, and contract term, where the order terms prevail. The termination rights under § 12 (material change) and § 14 (extended force majeure) nevertheless apply regardless of the commitment period and notice period in the order terms — otherwise those rights would be meaningless during the initial contract period.

Heqtic and the Customer may additionally agree in writing to further commercial terms specific to the Customer's account — e.g. a negotiated price or a revenue share — as an addendum shown to the Customer in the service before it is approved. Such an addendum may only govern commercial terms of that kind. It never amends this customer agreement or the order and payment terms otherwise, and in the event of any conflict, the customer agreement and the order terms prevail. If such an addendum constitutes a material change, it is handled under § 12 like any other change.

1. Parties

This agreement is between Heqtic AB, company registration no. 559539-2522 ("Heqtic", "we"), and the company that accepts the agreement in the service ("the Customer", "you"). The person who accepts warrants that they have authority to enter into the agreement on the Customer's behalf. The agreement is entered into electronically in the service; the acceptance is recorded with name, email address, timestamp, and version.

2. The Service

Heqtic delivers RBS deliverables (Researched Buying Signals) — prospect-specific research briefs about companies matching the ICP the Customer has provided. Each brief contains company facts, a dated buying signal, an identified decision-maker with contact details, a draft first-touch message, and source citations.

Heqtic does not send outreach on the Customer's behalf. All contact with the prospects named in a brief is made by the Customer itself, from the Customer's own channels. This matters for the allocation of responsibility in § 5.

The service is developed on an ongoing basis. We add, change, and remove features over time. We may do so as long as the agreed deliverable is not materially degraded — that is, RBS deliverables at the level the Customer has chosen, with the content described above. A new feature that is optional and that the Customer must themselves enable for it to do anything does not constitute a material change under § 12, since the Customer is unaffected by it until the Customer chooses it. The same applies to changes in appearance and workflow, corrections, and clarifications.

The exception to that. If a new feature means we process a new category of personal data, process personal data for a new purpose, or engage a new category of sub-processor, § 12 applies even if the feature is optional and off by default. The Customer's own choice of whether to use the feature changes nothing for the people the data concerns.

Some parts of this agreement refer to pages we update on an ongoing basis: the integrations page (§ 6), the sub-processor page (§ 7), and the privacy policy (§ 8). Those pages describe how we do something this agreement already permits — they can never expand what we are allowed to do. A change to the principle, not just the detail, is a change to the agreement and is handled under § 12. Every version of the agreement is listed on the change log.

3. Users at the Customer

The Customer may have several logins: the person who entered into the agreement (the account owner) and the colleagues the account owner allows to be added (users). The account owner is entitled to designate additional users within their own organisation.

  • All users on the account share deliverables, plan level, and integrations. Only the account owner can manage invoicing details, remove users, and request deletion of the entire account.
  • The Customer is responsible for what its users do in the service, as for its own conduct. That includes a user being able to connect, change, or disconnect the Customer's CRM and Slack channel (§ 6) — we log who did it, but we do not prevent it.
  • The Customer is responsible for removing users who leave or change role, and for informing the person being removed. We do not notify that person.
  • We process users' work email addresses under the privacy policy section 2.6. A user may always contact us directly regarding their own rights, even after the Customer has removed their access.

4. Personal data — roles

This section determines who is responsible for what, and differs from what many expect. Please read it carefully.

  • Heqtic is the controller for the research we conduct about prospects. The Customer sets target-audience criteria (ICP). Heqtic independently decides how, from which sources, and about which specific individuals research is conducted, performs its own documented balancing-of-interests assessment, reuses the material in its own business, and is itself responsible for data subjects' rights up until delivery. The legal basis is legitimate interest (GDPR Art. 6.1(f), recital 47). We are therefore not the Customer's processor for that material, and a data processing agreement is accordingly not the instrument that governs this relationship.
  • Once a deliverable has been handed over, the Customer becomes an independent controller for its own copy and for all processing the Customer carries out thereafter — including outreach, follow-up, and transfer to its own systems.
  • For the Customer's own data — account details, ICP material, and invoicing details — we process the data to perform this agreement (Art. 6.1(b)).

Should any future feature mean we process personal data on the Customer's behalf and on the Customer's instruction, we will enter into a separate data processing agreement for that specific feature before it is put into use.

If the allocation of roles were assessed differently. Should a supervisory authority or court determine that the parties are joint controllers under Art. 26, or that Heqtic is a processor for a particular processing activity, the parties shall promptly and in good faith enter into an agreement under Art. 26 or Art. 28 respectively for that processing. The other terms of this agreement are unaffected, and such a determination does not in itself constitute a breach of contract by either party.

4a. Heqtic Pipeline — role allocation for the operational layer

The Customer may choose to work with delivered RBSes in Heqtic Pipeline, a CRM tool we build and operate ourselves (separate from any CRM the Customer connects under § 6). This section applies only if and when the Customer activates that feature, and divides responsibility depending on which layer of Heqtic Pipeline is concerned — § 4 above is unchanged by this.

  • The research material itself (company name, title, contact routes, buying-signal analysis) mirrored into Heqtic Pipeline is covered by § 4 above exactly as normal — Heqtic is and remains an independent controller for it, on the same basis as for the primary deliverable. The material being shown in a second tool interface does not change that.
  • The operational layer on top — which pipeline column a card sits in, which of the Customer's team it is assigned to, notes and tasks a salesperson writes themselves, the Customer's own leads/contacts entered manually, and which salesperson a submitted ICP is assigned to ("ICP assignment") — is the Customer's own users' own decisions, for the Customer's own sales process, in a tool we happen to operate. If the Customer activates Heqtic Pipeline, Heqtic is, for that layer specifically, a processor for the Customer, and this clause is the data processing agreement § 4 above promises for such a future feature — no separate agreement is required beyond this one.
  • Exception: excluding companies already in Heqtic Pipeline. Of the operational layer above, only the company names are read by us, if the Customer enables the feature, ahead of each new delivery to the Customer — to avoid proposing such a company as a new prospect again. Unlike the rest of the operational layer, where Heqtic is a processor, Heqtic is, for this specific lookup and the names retrieved by it, an independent controller under Art. 6.1(f) — the same basis and the same principle that already applies to the corresponding feature for the Customer's own external CRM (§ 6, "Exclude companies the Customer already works with"). The names are included, just like the rest of the material Heqtic produces, in what is sent to Heqtic's AI vendor during generation (see the sub-processor page) — unlike the rest of the operational layer, the company names this feature covers are therefore transferred to a third country, limited to just the company names and just that purpose. Heqtic reads only company names — never contact details, notes, tasks, or who a card is assigned to — and the names are never stored by Heqtic beyond the Pipeline board itself: they are read ahead of each delivery and discarded immediately after use. The feature is on by default for as long as the Customer has Heqtic Pipeline activated, but can be turned off at any time (or turned on separately, if the Customer has turned it off) by any of the Customer's users, regardless of whether Heqtic Pipeline is otherwise on.

Duration. This section applies for as long as the Customer has access to Heqtic Pipeline under the customer agreement, but never longer than until this agreement as a whole ends. If the Customer chooses to temporarily switch back to "Own CRM" (§ 6), the operational layer's data remains undeleted so the Customer can switch back without losing their work — deletion happens under the point below, not automatically on such a switch. The data subjects for the operational layer are the Customer's own employees/users (name and email, mirrored from the Customer's account with us) — everyone on the Customer's account, not only whoever actually logs into Heqtic Pipeline, since a colleague must be assignable to an incoming ICP ("ICP assignment" above) even before they themselves open the tool — and, to the extent a note, task, or a manually entered lead names a person, the prospect or contact it concerns.

For the operational layer, we undertake to:

  • process the data only under the Customer's instructions — in the first instance, the Customer's own users' actions in the tool (moving a card, writing a note, assigning an owner). If we consider an instruction to conflict with data-protection rules, we will notify the Customer immediately;
  • ensure that everyone with access to the data is bound by confidentiality;
  • implement appropriate technical and organisational security measures based on the risk (Art. 32) — login happens via the Customer's own login with us (no separate password to leak), the operational layer sits in its own database partition, and an RBS that is withdrawn or deleted in the main service is also removed from here. An objection or deletion request entered into the suppression list normally removes an already-created card immediately, and is also checked once per day as an extra safeguard. See the security page for how we describe this today — that page describes, it does not expand, this commitment;
  • not engage any sub-processor beyond those already in place for the main service (§ 7) — the same storage, no transfer to a third country for this layer. The Customer hereby generally approves the sub-processors listed from time to time on the sub-processor page, under the same notice/objection procedure as § 7, and we impose the same obligations as this section on any such sub-processor and remain responsible for its processing ourselves;
  • assist the Customer with data subjects' rights (Art. 15–22) and with the Customer's own compliance with Art. 32–36 (security, personal-data breaches, impact assessments), based on the nature of the processing and the information available to us;
  • notify the Customer without undue delay after becoming aware of a personal-data breach concerning the operational layer — this is the notification commitment that applies to this part specifically, not the one in § 14 (which covers the Customer's own account and invoicing details and the material we are ourselves the controller for);
  • on termination of this agreement, or at the Customer's request before then — including a request to delete the operational layer specifically without ending the entire customer relationship — delete the operational layer's data or return it — this does not cover the research material itself, which is governed by § 8;
  • make available the information reasonably required to demonstrate our compliance with this, and allow reasonably notified audits.

The Customer's own processing of the operational layer (which column, who it is assigned to, your own notes) takes place under the Customer's own legal basis as controller for that part — the same way the Customer is already a controller for its own processing after an RBS has been delivered (§ 4).

5. The Customer's responsibility as controller

Since the Customer itself contacts the prospects (§ 2), the Customer is responsible for its own processing. The Customer specifically undertakes to:

  • have its own legal basis for its outreach and follow-up, and to comply with applicable rules on direct marketing and electronic communications;
  • for phone contact, check the number against the Swedish NIX-Telefon do-not-call register itself and otherwise comply with the Swedish Marketing Act's rules on telephone sales before the Customer calls a number in a brief — such a number may be a private individual's mobile number, as stated in the privacy policy. The check is the Customer's responsibility: Heqtic neither calls prospects itself nor checks the number against NIX before delivery (§ 2). Calls should be made within the professional role the brief describes, during normal office hours, and must be ended if the person asks for it;
  • if a brief concerns a prospect in a country other than Sweden — for example the United States — additionally find out and comply with that country's own rules on direct marketing. This is an addition, not an exception: GDPR and this section's other obligations (legal basis, information duty, handling of objections) apply fully to the Customer's own processing regardless of which country the prospect is in — only the channel-specific rules (NIX-Telefon/the Marketing Act, or the destination country's equivalent) differ. For prospects in the United States, for example, the CAN-SPAM Act applies to email (including a working unsubscribe link handled within ten business days, and a valid postal address in every email) and the TCPA and federal and state Do Not Call registers apply to phone and SMS contact — these rules differ from the Swedish ones and are in some respects stricter, including for automated dialling and SMS to mobile numbers. Checking and complying with the destination country's rules is the Customer's responsibility in the same way as for NIX-Telefon above: Heqtic sends no outreach and makes no calls on the Customer's behalf (§ 2), and does not check or warrant that a specific number or address may be contacted under the destination country's rules;
  • provide data subjects with the information the Customer is required to provide as controller for its own processing;
  • itself respect objections and opt-outs that reach the Customer directly, and forward them to us without undue delay. A prospect who tells the Customer they do not want to be contacted has turned to the Customer, not to us — that response does not automatically reach our suppression list. Send it to sam@heqtic.se. This is not a formality: the person has turned to the only party they can see, and without forwarding we continue processing them. Our commitment in return is set out below;
  • not resell or otherwise make delivered material available to third parties (§ 10).

Our commitment. An objection or deletion request that reaches us — directly from the person or forwarded by the Customer — is entered into the suppression list within 5 business days, free of charge, and confirmed to the Customer. The person is then blocked from all future deliverables, including to our other customers. The block is applied to the identifiers we can match on (email, domain, phone number, LinkedIn profile, and name in combination with company or municipality).

We tell you when it concerns a person you already received. If a data subject objects or requests deletion and the person appears in an RBS already delivered to the Customer, we notify the Customer without undue delay and no later than within 5 business days, with that RBS's public ID (Art. 19). The Customer must then delete the corresponding data in its own systems — including notes and free text — without undue delay. Without that notification, the Customer's obligation would be impossible to fulfil, since a deletion on our side does not reach the copy the Customer has already received or passed on.

6. Integrations the Customer connects itself

The Customer may voluntarily connect its own CRM, its own Slack channel, or an own webhook, using a key or URL the Customer itself issues. Nothing is sent there unless the Customer has connected it. Which systems are supported, exactly what is transferred, and which settings exist are described on the integrations page, which we update on an ongoing basis as the service develops (§ 2). The terms below apply regardless of what that page says, and the page cannot expand them.

  • The recipient is the Customer's own system, not a sub-processor of Heqtic. We have no agreement with, and no access to, the Customer's CRM account beyond the key the Customer has provided. The Customer is responsible for having its own data processing agreement with its CRM provider — that is the Customer's relationship with the provider, not ours.
  • The Customer is an independent controller for the copy that lands there, and is responsible for deleting that copy. That obligation also covers notes, other free text, and attached files transferred together with the contact — not only the contact record itself. The first time an RBS is transferred, we attach the entire RBS as a file to the deal and the contact. The file is uploaded as a private file attached to the note, never to a public file library at the CRM provider. It contains the same material the Customer sees with us, including contact details, and must be deleted together with the contact record. A deletion on our side does not reach into the Customer's system.
  • Automatic transfer on delivery. The Customer may choose to have every RBS transferred to the CRM automatically as soon as it is delivered. The choice may be made by any of the Customer's users, is off by default, can be turned off at any time, and is reset if the Customer disconnects or changes CRM. If the Customer chooses this, the Customer's CRM receives a copy of every delivered contact — even ones nobody at the Customer gets to work on — which expands the deletion obligation under the point above. Contacts who have requested not to be processed are never transferred, regardless of setting. If we withdraw an RBS, we remove the deal we created; the note, attached file, and contact record must be removed by the Customer themselves.
  • We only write records we ourselves created. If the contact or company already exists at the Customer, we reuse the record to link the deal correctly, but we never overwrite data the Customer already has. To avoid duplicates, we may need to search the Customer's account by company name and by the prospect's email address before a transfer. The search means the address appears in the CRM provider's own request logs, at the provider the Customer itself has an agreement with. From the search we store only the matched record's ID — no other data from the Customer's CRM. The integrations page states which systems the search applies to.
  • Slack appears in two different roles, and they should not be confused. The channel the Customer connects is the Customer's own, just like the CRM above, and the Customer is responsible for what remains in it — including notifications containing a download link to an RBS as a PDF. The link has no fixed expiry, but is guaranteed to stop working no later than when the RBS is withdrawn, when we have entered an objection or deletion request into the suppression list (§ 5, which can take up to 5 business days from when the objection reaches us), or when the contact details age out of the material (§ 8, normally 12 months after delivery) — whichever happens first. The notification remains in the channel until the Customer removes it, even after the link has stopped working — and since the link has no fixed expiry, it can conversely keep working for someone added to the channel long afterward. Choose a private channel accordingly, and clear out old notifications regularly: anyone who can see the channel can download the material without logging in with us, for as long as the link remains valid — regardless of whether that person was in the channel when the notification was sent. The delivery of the notification itself, however, goes through Slack's own infrastructure on our behalf — which is why Slack is also listed as a sub-processor on the sub-processor page and is covered by the notice rule in § 7.
  • The Customer can also turn on an email notification to the account's own account owner, sent when new RBSes are approved. Optional and off by default. At the account owner's request, we can additionally add a further, named recipient who receives the same email — for example a colleague who should only receive the notification, without getting their own login with us. We only do this once the intended recipient has themselves confirmed they want the emails. Since that person is not a party to this agreement, we base the processing of their address not on the agreement but on legitimate interest (GDPR Art. 6.1(f)) — see the privacy policy section 2.6. The account owner is responsible for asking us to remove the recipient again if that person leaves or changes role, in the same way as for users under § 3. If several RBSes are approved in the same batch, a separate email is sent per company, not one combined email. Each such email attaches a download link to that specific RBS as a PDF — the same kind of link, on the same terms, as the Slack notification's PDF link above. The link has no fixed expiry, but is guaranteed to stop working no later than when the RBS is withdrawn, when we have entered an objection or deletion request into the suppression list (§ 5, which can take up to 5 business days from when the objection reaches us), or when the contact details age out of the material (§ 8, normally 12 months after delivery) — whichever happens first. If five RBSes are approved at once, the account owner therefore receives five emails, each with its own such link; the Customer is responsible for not forwarding any of the emails to anyone who does not already have access. Each such email also contains a short sentence about which type of buying signal is involved (e.g. "a new hire" or "a leadership change") — drawn from a small, pre-defined list of categories and never from the free-form research text; never figures, dates, or any person's name. If we do not recognise the category, a fully generic sentence is shown instead. Each company row also has two short links where the Customer — without logging in — can mark the company as "Already a customer" or "Not interested" directly from the email; the click only updates that company's status in the Customer's own pipeline with us and discloses no further information about the prospect. These links exist regardless of how many RBSes the notification concerns, and — just like the PDF link above — have no fixed expiry: they keep working until the RBS is withdrawn and possibly approved again (a narrower condition than the PDF link's, which also stops working on an objection, deletion request, or aged-out contact detail). The same responsibility not to forward the email therefore also applies to these links, since anyone with a forwarded copy could otherwise click and affect the Customer's own pipeline. Like the Slack notification, the email is delivered through one of our own sub-processors on our behalf — which is why our email provider is also listed as a sub-processor on the sub-processor page and is covered by the notice rule in § 7. A third, free-text option, "Leave feedback", lets the Customer — without logging in — write a comment about that specific RBS directly from the email. The comment is stored with us and may be used, together with the Customer's other feedback, to improve future RBSes for that specific account. The comment is automatically screened to ensure it does not contain sensitive personal data about the contact (e.g. health, trade-union membership, religion, or political opinion); if it contains such data, it is not stored. The Customer is responsible for not entering such data, and for not forwarding the email to anyone who does not already have access — the same responsibility that applies to the links above. The same option to leave a free-text comment about a specific RBS is also available in the logged-in customer portal (a field separate from the Customer's own private notes about the RBS, which we do not read) — the same screening, the same storage, and the same use as for the email link above, and the same responsibility for the Customer not to enter sensitive personal data about the contact.
  • The Customer can instead, or in addition, connect its own webhook — a URL the Customer itself specifies, to a system the Customer itself controls. The feature is optional and off by default. The recipient is the Customer's own system, not a sub-processor of Heqtic, in the same way as the CRM above. On each delivery, we post the RBS's data as structured JSON to that URL — the same material transferred to the CRM (contact details, buying signal, analysis, and sources) plus, when one is stored, the entire RBS as a PDF, attached directly in the call. A link to the same PDF is also included. The link requires no login with us — anyone with the URL can open the material. Unlike the Slack link above, it has no fixed lifespan set in advance, but is guaranteed to stop working no later than when the RBS is withdrawn, when we have entered an objection or deletion request into the suppression list (§ 5 — which can take up to the 5 business days § 5 allows from when the objection reaches us), or when the contact details age out of the material under § 8 (normally 12 months after delivery) — whichever happens first. Contacts who have requested not to be processed are never posted, regardless of setting. The Customer is responsible for storing the link and the received content only in access-controlled systems, for the same reasons as for the Slack channel above, and for deleting the received copy on its side — a deletion on our side does not reach into the Customer's system.
  • If the Customer turns on the Automatic status update feature, we read, at most once per day, whether deals we ourselves created have been marked won or lost, and store that answer on the corresponding RBS. For Pipedrive only, the Customer can, under the same feature, additionally choose which of the Customer's own pipeline stages in their Pipedrive account means "Contacted" (e.g. a dedicated column for deals the Customer has reached out to) — the stage cannot be the same one the Customer has chosen for where new deals are created, if any. If the Customer has made that choice, at the same daily read we also check whether the deal is in that stage, and mark the corresponding RBS as contacted. For this feature we read no other deals, and no contacts, notes, activities, or messages — only the outcome value and, for Pipedrive when the Customer has chosen a stage as above, which of the two stages the deal is in (see the next point for the other feature that reads the Customer's CRM). A status the Customer has set manually is never overwritten. The feature — including the Pipedrive stage choice — is off by default and can be turned off at any time; turning it off also resets the stage choice, so that turning it back on later does not silently resume a read the Customer had once turned off. Turning on the feature is consent to access the Customer's own system — not a processing instruction under Art. 28. We process the outcome value (and any contacted marking) we retrieve as an independent controller for our own purpose: to follow up on the quality of what we have delivered, based on Art. 6.1(f) and the same balancing of interests as for the material otherwise.
  • Exclude companies the Customer already works with. The Customer can turn on having us read the company/organisation names in the Customer's CRM ahead of each delivery — to avoid proposing such a company as a new prospect. The feature is off by default, can be turned on or off by any of the Customer's users, and is reset if the Customer disconnects or changes CRM. We only read established company/ organisation records — never contact persons, deal values, notes, activities, or a specific deal's own name/title, not even for an ongoing deal — only the names of the Customer's existing company records, and they are never stored with us: they are read ahead of each delivery and discarded immediately after use. Like the outcome value we retrieve under the point above, we process the names we read here as an independent controller, based on Art. 6.1(f), for that purpose — and the names are included, just like the rest of the material we produce, in what is sent to our AI vendor during generation (see the sub-processor page).
  • Which region the Customer's CRM stores data in is determined by the Customer's own account and is the Customer's responsibility.

7. Sub-processors

The vendors who process personal data on our behalf are listed on an ongoing basis on the sub-processor page. When we add or change a sub-processor, we notify the Customer at least 14 days in advance. When one of our sub-processors in turn changes its own sub-processor, we pass on the notice as soon as we receive it — some sub-processors give us shorter notice than that, and we cannot promise more advance notice than we ourselves get.

This applies to changes and additions within the categories of processing already disclosed. If the addition constitutes a new category of processing at an external vendor, § 12 applies instead: 30 days' notice and a right to terminate the agreement.

If the Customer objects. The Customer may object to a new sub-processor within the notice period. We cannot promise to refrain — a vendor may be necessary for the service to work at all — but if we proceed anyway, the Customer has the right to terminate the agreement as of the day the sub-processor is put into use, regardless of the commitment period and notice period in the order terms, and at no cost beyond what has already been delivered. A notice with no way out of the agreement would otherwise not be worth much.

8. Storage, disclosure, and deletion

Retention periods are set out in the privacy policy section 3 and applied automatically. In brief: contact details in a delivered RBS are purged after 12 months, the ICP and deliverables after 24 months counted from the most recent delivery, and invoicing details that constitute accounting records are kept for 7 years after the end of the financial year they concern, under the Swedish Accounting Act. The Customer may request earlier deletion of everything except the last of those. The account is not deleted automatically when the agreement ends — it remains until the Customer requests deletion, precisely so the disclosure below remains possible.

The purge after 12 months covers every contact route to the decision-maker in an RBS — the verified contact details we obtained through enrichment, a contact route the analysis text itself cites (e.g. a switchboard number), and any guessed email address the analysis text itself proposes. The decision-maker's name and the substantive analysis remain. The privacy policy section 3 describes this in more detail, and a deletion request (Art. 17) removes the name and the analysis as well.

Disclosure when the agreement ends. The Customer may, at any time during the contract term and for 30 days afterward, download its deliverables in the service — subject to the retention periods above, which apply during the contract term as well. After that period, the Customer's account and deliverables are deleted on request, and otherwise under the retention periods above, except for what we must retain by law. We do not withhold deliverables as leverage in a payment dispute.

9. Confidentiality

We do not share the Customer's ICP, sales strategy, or other business information with third parties, and do not use it to benefit another customer. Confidentiality applies even after the agreement ends. We may use de-identified experience from the collaboration to improve the service. The Customer's own outcomes on delivered RBSes — e.g. won/lost deals from a connected CRM, or a rating the Customer itself provides — may, in aggregated, categorical form (without company names or contact details), be used to weight the selection in that specific Customer's future deliverables; never to benefit another customer. Using the Customer as a reference publicly requires the Customer's written approval.

The Customer's existing customers — whether the Customer enters them manually (in which case the entry may also concern an ongoing deal the Customer itself names as social proof) or, if the Customer has activated it, we read the names of the Customer's established company/organisation records from the Customer's own CRM under § 6 — are used exclusively to avoid proposing the same company as a new prospect to that specific Customer. We never share them with any other customer, never sell them, and never add them to a shared database. Data retrieved from the Customer's CRM is also never stored with us — see § 6.

10. Intellectual property

The Customer may use delivered material internally and in its own sales communications. The material may not be resold or made available to third parties. Heqtic retains all rights to the service as such — pipeline, prompt library, models, and templates — and to the format and structure of the material.

11. Liability

The material is research and decision support. We work to ensure it is accurate and current, but we do not guarantee that every detail is complete or error-free, and the Customer is responsible for its own assessment before using the material. Each party's aggregate liability over any twelve-month period is limited to what the Customer has paid during that same period, except in the case of intent or gross negligence. Neither party is liable for indirect damage.

Nothing in this agreement limits any liability that cannot be limited under mandatory law.

12. Changes to the agreement

We may update this agreement. Material changes are notified to the account owner at least 30 days in advance — either to the account owner's email address, or through a notice shown to the account owner in the service upon login — and the Customer then has the right to terminate the agreement as of the day the change takes effect. The period is counted from the day the notice actually reached the account owner, not from the day the change was published. That termination right applies regardless of the commitment period and notice period in the order terms, and at no cost beyond what has already been delivered. If the Customer does not terminate the agreement before it takes effect, the new version applies from that day.

What constitutes a material change. The following always count as material and therefore trigger notice and a termination right:

  • an increased price or new fees for what the Customer has already ordered;
  • a reduced number of deliverables, or the content of an RBS deliverable under § 2 being materially degraded;
  • a changed allocation of roles for personal data under § 4 or § 4a;
  • a longer retention period, or our starting to process personal data for a new purpose;
  • restricted rights for the Customer or expanded responsibility for the Customer, including changes to §§ 5, 6, 8, 10, 11, and 15 — §§ 5 and 6 are the ones that in practice most often grow with a new obligation for the Customer;
  • a new category of sub-processor, i.e. a new kind of processing at an external vendor rather than a change within a category already disclosed under § 7.

The following, by contrast, are not material changes. They take effect when published, and the Customer is informed of them at the next login and on the change log:

  • new optional features that are off by default and that the Customer must themselves enable — except when the feature involves a new category of personal data, a new purpose, or a new category of sub-processor, as set out in § 2;
  • changes to the appearance, navigation, and workflow of the service;
  • clarifications, language corrections, and corrections of obvious errors that do not change the meaning;
  • changes that are unambiguously to the Customer's benefit;
  • a new named sub-processor within a category already disclosed — that is instead handled with 14 days' notice under § 7;
  • updates to the ongoing pages § 2 refers to, as long as they stay within what the agreement already permits.

Every version is dated, and the version the Customer accepted is stored together with the acceptance. The full change history, with dates and what changed, is on the change log. If it is doubtful whether a change is material, we treat it as material.

13. Contract term

Contract term, termination, price, and payment are governed by the order and payment terms.

14. Other provisions

  • Personal-data breach. If we suffer a personal-data breach concerning the Customer's own data with us — account details, ICP material, invoicing details, users' addresses, or the keys the Customer has provided for its integrations — or data in material we have delivered to the Customer, we notify the account owner without undue delay and no later than within 72 hours of becoming aware of it, with what we know at that time about what happened, what is affected, and what we are doing about it. This applies alongside our own duty to report to the Swedish Authority for Privacy Protection (IMY) — we are an independent controller (§ 4), so the notification to the Customer is so that the Customer can assess its own obligations and take its own measures, for example revoking an API key.
  • Force majeure. Neither party is liable for delays or failures caused by circumstances beyond that party's reasonable control — for example outages at sub-vendors, large-scale network or power outages, government decisions, war, or natural events. The affected party shall notify the other party without delay. If the hindrance lasts longer than 60 days, either party may terminate the agreement with immediate effect, with no consequence other than payment for deliverables already performed.
  • Assignment. Neither party may assign the agreement without the other party's written consent. Consent is, however, not required for an assignment to a group company or in connection with a transfer of all or substantially all of the business, provided the acquirer assumes the agreement in full. The Customer shall be notified of such an assignment, and an assignment by Heqtic does not change the allocation of roles in § 4 or the notice rule in § 7.
  • Survival. §§ 4, 4a, 5, 8, 9, 10, 11, 14, and 15 continue to apply after the agreement ends, to the extent their content requires it. This means, among other things, that the Customer's obligation to delete on our notification (§ 5) and not to resell delivered material (§ 10) remain in place even once the collaboration has ended.
  • Invalid provision. Should a provision of the agreement be invalid or unenforceable, the rest of the agreement is unaffected, and the provision shall be interpreted so that its purpose is achieved to the extent the law allows.

15. Governing law and disputes

Swedish law applies. A dispute shall primarily be resolved through negotiation. If negotiation does not lead to a resolution, the dispute shall be settled by a general court, with Stockholm District Court as the first instance.

16. Contact

Questions about the agreement or data protection: sam@heqtic.se. Complaints may also be directed to the Swedish Authority for Privacy Protection (IMY), imy.se.