Kundavtal

De allmänna villkoren för samarbetet mellan Heqtic och er som kund — roller, ansvar och hur personuppgifter hanteras mellan oss. Version 2026-10-15.

English version

Det här avtalet kompletterar beställnings- och betalningsvillkoren, som reglerar pris, fakturering och avtalstid. Vid motstridighet mellan dokumenten gäller det här kundavtalet, utom i frågor om pris, betalning och avtalstid där beställningsvillkoren gäller. Uppsägningsrätterna enligt § 12 (väsentlig ändring) och § 14 (utdraget force majeure) gäller dock oavsett bindningstid och uppsägningstid i beställningsvillkoren — annars vore de rätterna utan verkan under den inledande avtalsperioden.

Heqtic och Kunden kan därutöver skriftligen avtala om ytterligare kommersiella villkor för just Kundens konto — t.ex. ett förhandlat pris eller en intäktsdelning — som ett tillägg som visas för Kunden i tjänsten innan det godkänns. Ett sådant tillägg kan bara reglera kommersiella villkor av det slaget. Det ändrar aldrig detta kundavtal eller beställnings- och betalningsvillkoren i övrigt, och vid en eventuell konflikt gäller kundavtalet och beställningsvillkoren. Innebär ett sådant tillägg en väsentlig ändring hanteras det enligt § 12 som varje annan ändring.

1. Parter

Detta avtal gäller mellan Heqtic AB, org.nr 559539-2522 (”Heqtic”, ”vi”), och det företag som accepterar avtalet i tjänsten (”Kunden”, ”ni”). Den person som accepterar intygar att hen har behörighet att ingå avtalet för Kundens räkning. Avtalet ingås elektroniskt i tjänsten; accepten registreras med namn, e-postadress, tidpunkt och version.

2. Tjänsten

Heqtic levererar RBS-leveranser (Researched Buying Signals) — prospektspecifika researchunderlag om företag som matchar den ICP Kunden angett. Varje underlag innehåller bolagsfakta, en daterad köpsignal, en identifierad beslutsfattare med kontaktuppgifter, ett förslag till första budskap samt källhänvisningar.

Heqtic skickar inga utskick åt Kunden. All kontakt med de prospekt som förekommer i ett underlag tas av Kunden själv, från Kundens egna kanaler. Det har betydelse för ansvarsfördelningen i § 5.

Tjänsten utvecklas löpande. Vi lägger till, ändrar och tar bort funktioner efter hand. Det får vi göra så länge den avtalade leveransen inte försämras väsentligt — det vill säga RBS-leveranser enligt den nivå Kunden valt, med det innehåll som beskrivs ovan. En ny funktion som är valfri och som Kunden själv måste aktivera för att den ska göra något utgör inte en väsentlig ändring enligt § 12, eftersom Kunden inte berörs av den förrän Kunden väljer det. Detsamma gäller ändringar av utseende och arbetsflöde, rättelser och förtydliganden.

Undantaget från det. Innebär en ny funktion att vi behandlar en ny kategori av personuppgifter, behandlar personuppgifter för ett nytt ändamål, eller anlitar en ny kategori av underbiträde, så gäller § 12 även om funktionen är valfri och avstängd från början. Att Kunden själv väljer om funktionen ska användas ändrar nämligen ingenting för de personer uppgifterna handlar om.

Vissa delar av avtalet pekar vidare till sidor vi uppdaterar löpande: integrationssidan (§ 6), underbiträdessidan (§ 7) och integritetspolicyn (§ 8). De sidorna beskriver hur vi gör något som det här avtalet redan tillåter — de kan alltså inte utvidga vad vi får göra. Ändras principen och inte bara detaljen är det en ändring av avtalet och hanteras enligt § 12. Varje version av avtalet finns på ändringssidan.

3. Användare hos Kunden

Kunden kan ha flera inloggningar: den person som ingick avtalet (kontoägaren) och de kollegor kontoägaren låter lägga till (användare). Kontoägaren har rätt att utse ytterligare användare inom sin egen organisation.

Samtliga användare på kontot delar leveranser, nivå och integrationer. Endast kontoägaren kan hantera fakturauppgifter, ta bort användare och begära radering av hela kontot.
Kunden ansvarar för vad dess användare gör i tjänsten, som för sitt eget handlande. Det omfattar bland annat att en användare kan koppla, byta eller koppla bort Kundens CRM och Slack-kanal (§ 6) — vi loggar vem som gjort det, men vi hindrar det inte.
Kunden ansvarar för att ta bort användare som slutar eller byter roll, och för att informera den som tas bort. Vi meddelar inte personen.
Vi behandlar användarnas tjänste-e-postadresser enligt integritetspolicyn avsnitt 2.6. En användare kan alltid vända sig direkt till oss med sina rättigheter, även efter att Kunden tagit bort deras åtkomst.

4. Personuppgifter — roller

Det här avsnittet avgör vem som ansvarar för vad, och skiljer sig från vad många förväntar sig. Läs det gärna noga.

Heqtic är personuppgiftsansvarig för den research vi gör om prospekt. Kunden anger målgruppskriterier (ICP). Heqtic bestämmer självständigt hur, från vilka källor och om vilka enskilda personer research görs, gör en egen dokumenterad intresseavvägning, återanvänder underlaget i sin egen verksamhet och svarar självt för de registrerades rättigheter fram till leverans. Den rättsliga grunden är berättigat intresse (GDPR art. 6.1 f, skäl 47). Vi är alltså inte Kundens personuppgiftsbiträde för det underlaget, och något personuppgiftsbiträdesavtal är därför inte det instrument som reglerar detta förhållande.
När en leverans lämnats över blir Kunden självständigt personuppgiftsansvarig för sin kopia och för all behandling Kunden gör därefter — inklusive utskick, uppföljning och överföring till egna system.
För Kundens egna uppgifter — kontouppgifter, ICP-underlag och fakturauppgifter — behandlar vi uppgifterna för att fullgöra detta avtal (art. 6.1 b).

Skulle vi i någon framtida funktion behandla personuppgifter för Kundens räkning och på Kundens instruktion, tecknar vi ett separat personuppgiftsbiträdesavtal för just den funktionen innan den tas i bruk.

Om rollfördelningen skulle bedömas annorlunda. Skulle en tillsynsmyndighet eller domstol bedöma att parterna är gemensamt personuppgiftsansvariga enligt art. 26, eller att Heqtic är personuppgiftsbiträde för viss behandling, ska parterna utan dröjsmål och i god tro ingå ett avtal enligt art. 26 respektive art. 28 för den behandlingen. Övriga villkor i detta avtal påverkas inte, och en sådan bedömning innebär inte i sig ett avtalsbrott från någon parts sida.

4a. Heqtic Pipeline — rollfördelning för driftslagret

Kunden kan välja att arbeta med levererade RBS:er i Heqtic Pipeline, ett CRM-verktyg vi själva bygger och driftar (skilt från det CRM Kunden eventuellt kopplar in enligt § 6). Det här avsnittet gäller bara om och när Kunden aktiverar den funktionen, och delar upp ansvaret beroende på vilket lager av Heqtic Pipeline det gäller — § 4 ovan ändras inte av detta.

Själva forskningsunderlaget (bolagsnamn, titel, kontaktvägar, köpsignalsanalys) som speglas in i Heqtic Pipeline omfattas av § 4 ovan precis som vanligt — Heqtic är och förblir självständigt personuppgiftsansvarig för det, på samma grund som för huvudleveransen. Att underlaget visas i ett andra verktygsgränssnitt ändrar inte det.
Driftslagret ovanpå — vilken pipeline-kolumn ett kort ligger i, vem i Kundens team det är tilldelat, anteckningar och uppgifter en säljare själv skriver, egna leads/kontakter Kunden själv lägger in, samt vilken säljare en inskickad ICP tillfaller (”Tilldelning per ICP”) — är Kundens egna användares egna beslut, för Kundens egen säljprocess, i ett verktyg vi råkar driva. Väljer Kunden att aktivera Heqtic Pipeline är Heqtic för just det lagret personuppgiftsbiträde åt Kunden, och den här paragrafen är det personuppgiftsbiträdesavtal § 4 ovan utlovar för en sådan framtida funktion — inget separat avtal krävs utöver det här.
Undantag: uteslut bolag som redan finns i Heqtic Pipeline. Av driftslagret ovan är det bara bolagsnamnen vi, om Kunden slår på funktionen, läser av inför varje ny leverans till Kunden — för att undvika att föreslå ett sådant bolag som nytt prospekt igen. Till skillnad från resten av driftslagret, där Heqtic är personuppgiftsbiträde, är Heqtic för just den här avläsningen och de namn som då hämtas självständigt personuppgiftsansvarig enligt art. 6.1 f — samma grund och samma princip som redan gäller för motsvarande funktion för Kundens eget externa CRM (§ 6, ”Uteslut företag Kunden redan jobbar med”). Namnen ingår, precis som resten av det underlag Heqtic tar fram, i det som skickas till Heqtics AI-leverantör vid genereringen (se underbiträdessidan) — till skillnad från resten av driftslagret läses alltså de bolagsnamn funktionen omfattar till tredje land, begränsat till just bolagsnamnen och just det ändamålet. Heqtic läser bara bolagsnamn — aldrig kontaktuppgifter, anteckningar, uppgifter eller vem ett kort är tilldelat — och namnen sparas aldrig hos Heqtic utöver själva Pipeline-tavlan: de läses inför varje leverans och kastas direkt efter användning. Funktionen är påslagen som standard så länge Kunden har Heqtic Pipeline aktiverat, men kan när som helst stängas av (eller slås på separat, om Kunden stängt av den) av vilken av Kundens användare som helst, oberoende av om Heqtic Pipeline i övrigt är på.

Varaktighet. Det här avsnittet gäller så länge Kunden har tillgång till Heqtic Pipeline enligt kundavtalet, dock längst till dess detta avtal i sin helhet upphör. Väljer Kunden att tillfälligt gå tillbaka till ”Eget CRM” (§ 6) ligger driftslagrets uppgifter kvar oraderade så att Kunden kan växla tillbaka utan att förlora sitt arbete — radering sker enligt punkten nedan, inte automatiskt vid en sådan växling. De registrerade för driftslagret är Kundens egna anställda/användare (namn och e-post, speglat från Kundens konto hos oss) — samtliga på Kundens konto, inte bara den som faktiskt loggar in i Heqtic Pipeline, eftersom en kollega måste kunna tilldelas en inkommen ICP (”Tilldelning per ICP” ovan) även innan hen själv öppnat verktyget — och, i den mån en anteckning, uppgift eller ett eget inlagt lead nämner en person, det prospekt eller den kontakt det gäller.

För driftslagret åtar vi oss att:

behandla uppgifterna bara enligt Kundens instruktioner — i första hand Kundens egna användares handlingar i verktyget (flytta ett kort, skriva en anteckning, tilldela en ägare). Bedömer vi att en instruktion strider mot dataskyddsregler meddelar vi Kunden omedelbart;
se till att alla med åtkomst till uppgifterna omfattas av sekretess;
vidta lämpliga tekniska och organisatoriska säkerhetsåtgärder utifrån risken (art. 32) — inloggning sker via Kundens egen inloggning hos oss (ingen separat lösenord att läcka), driftslagret ligger i en egen databasavgränsning, och en RBS som dras tillbaka eller raderas i huvudtjänsten tas bort härifrån också. En invändning eller raderingsbegäran som förs in i spärrlistan tar i normalfallet bort ett redan skapat kort omedelbart, och kontrolleras även en gång per dygn som extra säkerhet. Se säkerhetssidan för hur vi beskriver detta i nuläget — den sidan beskriver, den utvidgar inte detta åtagande;
inte anlita något underbiträde utöver det som redan gäller för huvudtjänsten (§ 7) — samma lagring, ingen överföring till tredje land för detta lager. Kunden godkänner härmed generellt de underbiträden som vid var tid anges på underbiträdessidan, enligt samma varsel-/invändningsrutin som § 7, och vi ålägger ett sådant underbiträde samma skyldigheter som detta avsnitt och svarar själva för dess behandling;
bistå Kunden med registrerades rättigheter (art. 15–22) och med Kundens egen efterlevnad av art. 32–36 (säkerhet, personuppgiftsincidenter, konsekvensbedömningar), utifrån behandlingens art och den information vi har tillgänglig;
underrätta Kunden utan onödigt dröjsmål efter att vi fått kännedom om en personuppgiftsincident som rör driftslagret — det här är det underrättelse-åtagande som gäller för den här delen, inte § 14:s (som gäller Kundens egna konto- och fakturauppgifter samt det underlag vi själva är personuppgiftsansvariga för);
vid detta avtals upphörande, eller på Kundens begäran dessförinnan — inklusive en begäran om att radera driftslagret specifikt utan att avsluta hela kundrelationen — radera driftslagrets uppgifter eller lämna dem tillbaka — gäller inte själva forskningsunderlaget, som styrs av § 8;
tillhandahålla den information som rimligen krävs för att visa att vi följer detta, och tillåta rimligt varslade granskningar.

Kundens egen behandling av driftslagret (vilken kolumn, vem det är tilldelat, era egna anteckningar) sker under Kundens egen rättsliga grund som personuppgiftsansvarig för den delen — på samma sätt Kunden redan är personuppgiftsansvarig för sin egen behandling efter att en RBS levererats (§ 4).

5. Kundens ansvar som personuppgiftsansvarig

Eftersom Kunden själv kontaktar prospekten (§ 2) ansvarar Kunden för sin egen behandling. Kunden åtar sig särskilt att:

ha en egen rättslig grund för sina utskick och sin uppföljning, och att följa tillämpliga regler för direktmarknadsföring och elektronisk kommunikation;
vid telefonkontakt själv kontrollera numret mot NIX-Telefon och i övrigt följa marknadsföringslagens regler för telefonförsäljning innan Kunden ringer ett nummer i ett underlag — ett sådant nummer kan vara en privatpersons mobilnummer, vilket anges i integritetspolicyn. Kontrollen är Kundens ansvar: Heqtic varken ringer prospekt själv eller kontrollerar numret mot NIX före leverans (§ 2). Samtal bör hållas inom den yrkesroll underlaget beskriver, under normal kontorstid, och ska avbrytas om personen ber om det;
avser ett underlag ett prospekt i ett annat land än Sverige — till exempel i USA — därutöver själv ta reda på och följa det landets egna regler för direktmarknadsföring. Detta är ett tillägg, inte ett undantag: GDPR och denna paragrafs övriga skyldigheter (rättslig grund, informationsskyldighet, hantering av invändningar) gäller Kundens egen behandling fullt ut oavsett i vilket land prospektet finns — det är bara detkanalspecifika regelverket (NIX-Telefon/ marknadsföringslagen respektive mållandets motsvarighet) som skiljer sig. För prospekt i USA gäller till exempel CAN-SPAM Act för e-post (bland annat en fungerande avregistreringslänk som hanteras inom tio arbetsdagar, och en giltig postadress i varje mejl) och TCPA samt federala och delstatliga spärrlistor (”Do Not Call”) för telefon- och sms-kontakt — reglerna skiljer sig från de svenska och är på vissa punkter strängare, bland annat för automatiserade uppringningar och sms till mobilnummer. Kontrollen och efterlevnaden av mållandets regler är Kundens ansvar på samma sätt som för NIX-Telefon ovan: Heqtic skickar inga utskick och ringer inga samtal åt Kunden (§ 2), och kontrollerar eller intygar inte att ett specifikt nummer eller en specifik adress får kontaktas enligt mållandets regler;
lämna den information till de registrerade som Kunden är skyldig att lämna i egenskap av personuppgiftsansvarig för sin egen behandling;
själv respektera invändningar och avregistreringar som når Kunden direkt, och vidarebefordra dem till oss utan onödigt dröjsmål. En prospekt som svarar Kunden att de inte vill bli kontaktade har vänt sig till Kunden, inte till oss — det svaret når inte automatiskt vår spärrlista. Skicka det till sam@heqtic.se. Detta är ingen formalitet: personen har vänt sig till den enda part de kan se, och utan vidarebefordran fortsätter vi behandla dem. Vårt åtagande i gengäld framgår nedan;
inte vidareförsälja eller på annat sätt tillgängliggöra levererade underlag för tredje part (§ 10).

Vårt åtagande. En invändning eller raderingsbegäran som når oss — direkt från personen eller vidarebefordrad av Kunden — för vi in i spärrlistan inom 5 arbetsdagar, kostnadsfritt, och bekräftar till Kunden. Därefter stoppas personen i alla framtida leveranser, även till våra andra kunder. Spärren tillämpas på de identifikatorer vi kan matcha på (e-post, domän, telefonnummer, LinkedIn-profil, samt namn i kombination med bolag eller kommun).

Vi berättar när det rör en person ni redan fått. Om en registrerad invänder eller begär radering och personen förekommer i en RBS som redan levererats till Kunden, meddelar vi Kunden utan onödigt dröjsmål och senast inom 5 arbetsdagar, med den RBS:ens publika id (art. 19). Kunden ska då radera motsvarande uppgifter i sina egna system — inklusive anteckningar och fritext — utan onödigt dröjsmål. Utan det beskedet vore Kundens skyldighet omöjlig att fullgöra, eftersom en radering hos oss inte når den kopia Kunden redan fått eller fört vidare.

6. Integrationer Kunden själv kopplar in

Kunden kan frivilligt koppla sitt eget CRM, sin egen Slack-kanal eller en egen webhook, med en nyckel eller URL Kunden själv utfärdar. Ingenting skickas dit utan att Kunden kopplat in det. Vilka system som stöds, exakt vad som förs över och vilka inställningar som finns framgår av integrationssidan, som vi uppdaterar löpande i takt med att tjänsten utvecklas (§ 2). Villkoren nedan gäller oavsett hur den sidan ser ut, och sidan kan inte utvidga dem.

Mottagaren är Kundens eget system, inte ett underbiträde till Heqtic. Vi har inget avtal med och ingen åtkomst till Kundens CRM-konto utöver den nyckel Kunden lämnat. Kunden ansvarar för att ha ett eget personuppgiftsbiträdesavtal med sin CRM-leverantör — det är Kundens förhållande till leverantören, inte vårt.
Kunden är självständigt personuppgiftsansvarig för den kopia som landar där, och ansvarar för radering av den kopian. Den skyldigheten omfattar även anteckningar, annan fritext och bifogade filer som förs över tillsammans med kontakten — inte bara själva kontaktposten. Första gången en RBS förs över bifogar vi hela RBS:en som fil till affären och kontakten. Filen laddas upp som en privat fil kopplad till anteckningen, aldrig till ett publikt filbibliotek hos CRM-leverantören. Den innehåller samma underlag som Kunden ser hos oss, inklusive kontaktuppgifter, och måste raderas tillsammans med kontaktposten. En radering hos oss når inte in i Kundens system.
Automatisk överföring vid leverans. Kunden kan välja att varje RBS förs över till CRM:et automatiskt så snart den levererats. Valet kan göras av vilken av Kundens användare som helst, är avstängt från början, kan stängas av när som helst, och nollställs om Kunden kopplar från eller byter CRM. Väljer Kunden detta får Kundens CRM en kopia av varje levererad kontaktperson — även de ingen hos Kunden hinner arbeta med — vilket utökar raderingsskyldigheten enligt punkten ovan. Kontakter som begärt att inte behandlas förs aldrig över, oavsett inställning. Drar vi tillbaka en RBS tar vi bort den affär vi skapat; anteckning, bifogad fil och kontaktposten måste Kunden ta bort själv.
Vi skriver bara poster vi själva skapat. Finns kontakten eller bolaget redan hos Kunden återanvänder vi posten för att koppla affären rätt, men vi skriver aldrig över uppgifter Kunden redan har. För att undvika dubbletter kan vi behöva söka i Kundens konto på bolagsnamn och på prospektets e-postadress före en överföring. Sökningen innebär att adressen förekommer i CRM-leverantörens egna anropsloggar, hos den leverantör Kunden själv har avtal med. Av sökningen sparar vi bara den träffade postens id — inga andra uppgifter från Kundens CRM. Integrationssidan anger för vilka system sökningen sker.
Slack förekommer i två olika roller, och de ska inte blandas ihop. Den kanal Kunden kopplar in är Kundens egen, precis som CRM:et ovan, och Kunden ansvarar för vad som ligger kvar i den — inklusive notiser som innehåller en nedladdningslänk till en RBS som PDF. Länken är inte tidsbegränsad, men slutar garanterat fungera senast när RBS:en dras tillbaka, när vi fört in en invändning eller raderingsbegäran i spärrlistan (§ 5, kan ta upp till 5 arbetsdagar från det att invändningen når oss), eller när kontaktuppgifterna åldras ut ur underlaget (§ 8, normalt 12 månader efter leverans) — det som inträffar först. Notisen ligger kvar i kanalen tills Kunden tar bort den, även efter att länken slutat fungera — och eftersom länken inte är tidsbegränsad kan den tvärtom fortsätta fungera för den som läggs till i kanalen långt senare. Välj därför en privat kanal och rensa bort gamla notiser med jämna mellanrum: den som ser kanalen kan ladda ner underlaget utan att logga in hos oss, så länge länken fortsätter gälla — oavsett om personen fanns med i kanalen när notisen skickades. Själva leveransen av notisen går däremot genom Slacks infrastruktur på vårt uppdrag — därför står Slack också som underbiträde på underbiträdessidan och omfattas av varselregeln i § 7.
Kunden kan också slå på en e-postnotis till kontots egen kontoägare, som skickas när nya RBS:er är godkända. Frivillig och avstängd som standard. På kontoägarens begäran kan vi dessutom lägga till en ytterligare, namngiven mottagare som får samma mejl — till exempel en kollega som bara ska ha notisen, utan att få en egen inloggning hos oss. Vi gör det bara sedan den tilltänkta mottagaren själv bekräftat att de vill ha mejlen. Eftersom den personen inte är part i det här avtalet grundar vi behandlingen av dennes adress inte på avtalet utan på berättigat intresse (GDPR art. 6.1 f) — se integritetspolicyn avsnitt 2.6. Kontoägaren ansvarar för att be oss ta bort mottagaren igen om personen slutar eller byter roll, på samma sätt som för användare enligt § 3. Godkänns flera RBS:er i samma omgång skickas ett eget mejl per bolag, inte ett samlat mejl. Varje sådant mejl bifogar en nedladdningslänk till just den RBS:en som PDF — samma sorts länk, med samma villkor, som Slack-notisens PDF-länk ovan. Länken är inte tidsbegränsad, men slutar garanterat fungera senast när RBS:en dras tillbaka, när vi fört in en invändning eller raderingsbegäran i spärrlistan (§ 5, kan ta upp till 5 arbetsdagar från det att invändningen når oss), eller när kontaktuppgifterna åldras ut ur underlaget (§ 8, normalt 12 månader efter leverans) — det som inträffar först. Godkänns fem RBS:er samtidigt får kontoägaren alltså fem mejl, vart och ett med sin egen sådana länk; Kunden ansvarar för att inte vidarebefordra något av mejlen till någon som inte redan har åtkomst. Varje sådant mejl innehåller också en kort mening om vilken typ av köpsignal det rör sig om (t.ex. "en nyrekrytering" eller "en ledningsförändring") — hämtad ur en liten, i förväg fastställd lista av kategorier och aldrig ur den fria forskningstexten; aldrig siffror, datum eller någon persons namn. Känner vi inte igen kategorin visas en helt generell mening i stället. Varje bolagsrad har också två korta länkar där Kunden — utan att logga in — kan markera bolaget som "Redan kund" eller "Inte intressant" direkt från mejlet; klicket uppdaterar bara bolagets status i Kundens egen pipeline hos oss och lämnar ingen ytterligare uppgift om prospektet ut. Dessa länkar finns oavsett hur många RBS:er notisen gäller, och är — precis som PDF-länken ovan — inte tidsbegränsade: de fortsätter fungera tills RBS:en dras tillbaka och eventuellt godkänns på nytt (ett smalare villkor än PDF-länkens, som också slutar fungera vid en invändning, raderingsbegäran eller åldrad kontaktuppgift). Samma ansvar att inte vidarebefordra mejlet gäller alltså även dessa länkar, eftersom vem som helst med en vidarebefordrad kopia annars kan klicka och påverka Kundens egen pipeline. Precis som Slack-notisen levereras mejlet genom en av våra egna underbiträden på vårt uppdrag — därför står vår e-postleverantör också som underbiträde på underbiträdessidan och omfattas av varselregeln i § 7. Ett tredje, fritextbaserat alternativ, "Lämna feedback", låter Kunden — utan att logga in — skriva en kommentar om den specifika RBS:en direkt från mejlet. Kommentaren sparas hos oss och kan komma att användas, tillsammans med Kundens övriga återkoppling, för att förbättra framtida RBS:er åt just detta konto. Kommentaren granskas automatiskt för att inte innehålla känsliga personuppgifter om kontaktpersonen (t.ex. hälsa, facklig tillhörighet, religion eller politisk åsikt); innehåller den sådana uppgifter sparas den inte. Kunden ansvarar för att inte skriva in sådana uppgifter, och för att inte vidarebefordra mejlet till någon som inte redan har åtkomst — samma ansvar som gäller länkarna ovan. Samma möjlighet att lämna en fritextkommentar om en specifik RBS finns även i den inloggade kundportalen (ett fält skilt från Kundens egna, privata anteckningar om RBS:en, som vi inte läser) — samma granskning, samma lagring och samma användning som för mejllänken ovan, och samma ansvar för Kunden att inte skriva in känsliga personuppgifter om kontaktpersonen.
Kunden kan istället, eller också, koppla en egen webhook — en URL Kunden själv anger, mot ett system Kunden själv kontrollerar. Funktionen är frivillig och avstängd som standard. Mottagaren är Kundens eget system, inte ett underbiträde till Heqtic, på samma sätt som CRM:et ovan. Vid varje leverans postar vi RBS:ens uppgifter som strukturerad JSON till den URL:en — samma underlag som förs över till CRM:et (kontaktuppgifter, säljsignal, analys och källor) samt, när en sådan finns lagrad, hela RBS:en som PDF, bifogad direkt i anropet. En länk till samma PDF följer också med. Länken kräver ingen inloggning hos oss — vem som helst med URL:en kan öppna underlaget. Till skillnad från Slack-länken ovan har den ingen bestämd livslängd i förväg, men slutar garanterat fungera senast när RBS:en dras tillbaka, när vi fört in en invändning eller raderingsbegäran i spärrlistan (§ 5 — det kan ta upp till de 5 arbetsdagar § 5 anger från det att invändningen når oss), eller när kontaktuppgifterna åldras ut ur underlaget enligt § 8 (normalt 12 månader efter leverans) — det som inträffar först. Kontakter som begärt att inte behandlas postas aldrig, oavsett inställning. Kunden ansvarar för att bara spara länken och det mottagna innehållet i behörighetsstyrda system, av samma skäl som för Slack-kanalen ovan, och för radering av den mottagna kopian hos sig — en radering hos oss når inte in i Kundens system.
Slår Kunden på funktionen Automatisk statusuppdatering läser vi högst en gång per dygn av om de affärer vi själva skapat har markerats vunna eller förlorade, och sparar det svaret på motsvarande RBS. Endast för Pipedrive kan Kunden, under samma funktion, dessutom välja vilket eget pipeline-steg i Kundens Pipedrive-konto som betyder "Kontaktad" (t.ex. en egen kolumn för affärer Kunden tagit kontakt med) — steget kan inte vara samma som det Kunden i så fall valt för var nya affärer ska skapas. Har Kunden gjort det valet läser vi vid samma dygnsvisa avläsning även av om affären ligger i det steget, och markerar då motsvarande RBS som kontaktad. För den här funktionen läser vi inga andra affärer, och inga kontakter, anteckningar, aktiviteter eller meddelanden — bara avslutsvärdet och, för Pipedrive när Kunden valt ett steg enligt ovan, vilket av de två stegen affären befinner sig i (se nästa punkt för den andra funktionen som läser av Kundens CRM). En status som Kunden satt för hand skrivs aldrig över. Funktionen — inklusive Pipedrive-stegvalet — är avstängd som standard och kan när som helst stängas av; stängs den av nollställs även stegvalet, så att ett senare påslag inte tyst återupptar en avläsning Kunden en gång stängt av. Att slå på funktionen är ett medgivande till åtkomst till Kundens eget system — inte en behandlingsinstruktion enligt art. 28. Det avslutsvärde (och en eventuell kontaktad-markering) vi hämtar behandlar vi som självständigt personuppgiftsansvariga för vårt eget ändamål: att följa upp kvaliteten i det vi levererat, med stöd av art. 6.1 f och samma intresseavvägning som för underlagen i övrigt.
Uteslut företag Kunden redan jobbar med. Kunden kan slå på att vi, inför varje leverans, läser av bolags-/ organisationsnamnen i Kundens CRM — för att undvika att föreslå ett sådant bolag som nytt prospekt. Funktionen är avstängd som standard, kan slås på eller stängas av av vilken av Kundens användare som helst, och nollställs om Kunden kopplar från eller byter CRM. Vi läser bara etablerade bolags-/organisationsposter — aldrig kontaktpersoner, affärsvärden, anteckningar, aktiviteter eller en enskild affärs eget namn/titel, inte ens för en pågående affär — bara namnen på Kundens befintliga bolagsposter, och de sparas aldrig hos oss: de läses inför varje leverans och kastas direkt efter användning. Liksom det avslutsvärde vi hämtar i punkten ovan behandlar vi de namn vi läser här som självständigt personuppgiftsansvariga, med stöd av art. 6.1 f, för det ändamålet — och namnen ingår, precis som resten av det underlag vi tar fram, i det som skickas till vår AI-leverantör vid genereringen (se underbiträdessidan).
Vilken region Kundens CRM lagrar data i bestäms av Kundens eget konto och ansvaras för av Kunden.

7. Underbiträden

De leverantörer som behandlar personuppgifter på vårt uppdrag redovisas löpande på underbiträdessidan. När vi lägger till eller byter ett underbiträde meddelar vi Kunden minst 14 dagar i förväg. När ett av våra underbiträden i sin tur byter underbiträde i nästa led vidarebefordrar vi beskedet så snart vi fått det — vissa underbiträden ger oss kortare varsel än så, och vi kan inte utlova längre framförhållning än vi själva får.

Det gäller byten och tillägg inom de kategorier av behandling som redan redovisas. Innebär tillägget en ny kategori av behandling hos en extern leverantör gäller i stället § 12: 30 dagars varsel och rätt att säga upp avtalet.

Om Kunden invänder. Kunden kan invända mot ett nytt underbiträde inom varseltiden. Vi kan inte lova att avstå — en leverantör kan vara nödvändig för att tjänsten ska fungera alls — men går vi ändå vidare har Kunden rätt att säga upp avtalet till den dag underbiträdet tas i bruk, utan hinder av bindningstiden och uppsägningstiden i beställningsvillkoren, och utan kostnad utöver det som redan levererats. Ett varsel utan möjlighet att komma ur avtalet vore annars inte värt mycket.

8. Lagring, utlämnande och radering

Lagringstiderna framgår av integritetspolicyn avsnitt 3 och tillämpas automatiskt. I korthet: kontaktuppgifter i en levererad RBS rensas efter 12 månader, ICP och leveranser efter 24 månader räknat från den senaste leveransen, och fakturauppgifter som utgör räkenskapsinformation sparas i 7 år efter utgången av det räkenskapsår de avser, enligt bokföringslagen. Kunden kan begära radering tidigare av allt utom det sistnämnda. Kontot raderas inte automatiskt när avtalet upphör — det ligger kvar tills Kunden begär radering, just för att utlämnandet nedan ska vara möjligt.

Rensningen efter 12 månader omfattar alla kontaktvägar till beslutsfattaren i en RBS — de verifierade kontaktuppgifter vi hämtat via berikning, en kontaktväg som analystexten själv citerat (t.ex. en växeltelefon), och en eventuell gissad e-postadress som analystexten själv föreslår. Beslutsfattarens namn och den sakliga analysen finns kvar. Integritetspolicyn avsnitt 3 beskriver det närmare, och en begäran om radering (art. 17) tar bort även namnet och analysen.

Utlämnande när avtalet upphör. Kunden kan när som helst under avtalstiden, och under 30 dagar därefter, ladda ner sina leveranser i tjänsten — med förbehåll för lagringstiderna ovan, som gäller även under avtalstiden. Efter den perioden raderas Kundens konto och leveranser på begäran, och i övrigt enligt lagringstiderna ovan, med undantag för det vi måste behålla enligt lag. Vi håller inte kvar leveranser som påtryckningsmedel vid en tvist om betalning.

9. Sekretess

Vi delar inte Kundens ICP, säljstrategi eller annan affärsinformation med tredje part, och använder den inte för att gynna en annan kund. Sekretessen gäller även efter att avtalet upphört. Vi får använda avidentifierad erfarenhet från samarbetet för att förbättra tjänsten. Kundens egna utfall på levererade RBS:er — t.ex. vunna/förlorade affärer från en ansluten CRM, eller ett betyg Kunden själv lämnar — kan i sammanställd, kategorisk form (utan företagsnamn eller kontaktuppgifter) användas för att vikta urvalet i just den Kundens framtida leveranser; aldrig för att gynna en annan kund. Att använda Kunden som referens publikt kräver Kundens skriftliga godkännande.

Kundens befintliga kunder — vare sig Kunden skriver in dem själv (då kan uppgiften även gälla en pågående affär Kunden själv namnger som social proof) eller, om Kunden aktiverat det, vi läser namnen på Kundens etablerade bolags-/organisationsposter från Kundens eget CRM enligt § 6 — används uteslutande för att undvika att samma bolag föreslås som nytt prospekt åt just den Kunden. Vi delar dem aldrig med någon annan kund, säljer dem aldrig och lägger aldrig till dem i en gemensam databas. Uppgifter som hämtas från Kundens CRM sparas dessutom aldrig hos oss — se § 6.

10. Immateriella rättigheter

Kunden får nyttja levererade underlag internt och i sin egen säljkommunikation. Underlagen får inte vidareförsäljas eller tillgängliggöras för tredje part. Heqtic behåller alla rättigheter till tjänsten som sådan — pipeline, promptbibliotek, modeller och mallar — och till underlagens format och struktur.

11. Ansvar

Underlagen är researchmaterial och beslutsstöd. Vi arbetar för att de ska vara korrekta och aktuella, men vi garanterar inte att varje uppgift är fullständig eller felfri, och Kunden ansvarar för sin egen bedömning innan underlaget används. Vardera partens sammanlagda ansvar under en tolvmånadersperiod är begränsat till vad Kunden betalat under samma period, utom vid uppsåt eller grov vårdslöshet. Ingen av parterna ansvarar för indirekt skada.

Ingenting i detta avtal begränsar ett ansvar som inte får begränsas enligt tvingande lag.

12. Ändringar av avtalet

Vi kan uppdatera detta avtal. Väsentliga ändringar meddelas kontoägaren minst 30 dagar i förväg — antingen till kontoägarens e-postadress, eller genom ett meddelande som visas för kontoägaren i tjänsten vid inloggning — och Kunden har då rätt att säga upp avtalet till den dag ändringen träder i kraft. Fristen räknas från den dag beskedet faktiskt nått kontoägaren, inte från den dag ändringen publicerades. Den uppsägningsrätten gäller utan hinder av bindningstiden och uppsägningstiden i beställningsvillkoren, och utan kostnad utöver det som redan levererats. Säger Kunden inte upp avtalet före ikraftträdandet gäller den nya versionen från den dagen.

Vad som är en väsentlig ändring. Följande räknas alltid som väsentligt och utlöser alltså varsel och uppsägningsrätt:

höjt pris eller nya avgifter för det Kunden redan beställt;
minskat antal leveranser, eller att innehållet i en RBS-leverans enligt § 2 försämras väsentligt;
ändrad rollfördelning för personuppgifter enligt § 4 eller § 4a;
längre lagringstid, eller att vi börjar behandla personuppgifter för ett nytt ändamål;
inskränkta rättigheter för Kunden eller utökat ansvar för Kunden, inklusive ändringar i §§ 5, 6, 8, 10, 11 och 15 — §§ 5 och 6 är de som i praktiken oftast växer med en ny skyldighet för Kunden;
en ny kategori av underbiträde, alltså en ny sorts behandling hos en extern leverantör snarare än ett byte inom en kategori som redan redovisas enligt § 7.

Följande är däremot inte väsentliga ändringar. De börjar gälla när de publiceras, och Kunden får information om dem vid nästa inloggning och på ändringssidan:

nya valfria funktioner som är avstängda från början och som Kunden själv måste aktivera — utom när funktionen innebär en ny kategori av personuppgifter, ett nytt ändamål eller en ny kategori av underbiträde, som framgår av § 2;
ändringar av utseende, navigation och arbetsflöde i tjänsten;
förtydliganden, språkliga rättelser och rättelser av uppenbara fel som inte ändrar innebörden;
ändringar som entydigt är till Kundens fördel;
ett nytt namngivet underbiträde inom en kategori som redan redovisas — det hanteras i stället med 14 dagars varsel enligt § 7;
uppdateringar av de löpande sidor § 2 hänvisar till, så länge de håller sig inom det avtalet redan tillåter.

Varje version är daterad, och den version Kunden accepterat sparas tillsammans med accepten. Hela ändringshistoriken, med datum och vad som ändrats, finns på ändringssidan. Är det tveksamt om en ändring är väsentlig behandlar vi den som väsentlig.

13. Avtalstid

Avtalstid, uppsägning, pris och betalning regleras i beställnings- och betalningsvillkoren.

14. Övriga bestämmelser

Personuppgiftsincident. Drabbas vi av en personuppgiftsincident som rör Kundens uppgifter hos oss — kontouppgifter, ICP-underlag, fakturauppgifter, användarnas adresser eller de nycklar Kunden lämnat för sina integrationer — eller uppgifter i underlag vi levererat till Kunden, underrättar vi kontoägaren utan onödigt dröjsmål och senast inom 72 timmar från det att vi fått kännedom om den, med det vi då vet om vad som hänt, vad som berörs och vad vi gör åt det. Detta gäller vid sidan av vår egen anmälningsskyldighet till IMY — vi är självständigt personuppgiftsansvariga (§ 4), så underrättelsen till Kunden sker för att Kunden ska kunna bedöma sina egna skyldigheter och vidta egna åtgärder, exempelvis återkalla en API-nyckel.
Force majeure. Ingen av parterna ansvarar för förseningar eller brister som beror på omständigheter utanför partens rimliga kontroll — exempelvis avbrott hos underleverantörer, storskaliga nätverks- eller elavbrott, myndighetsbeslut, krig eller naturhändelser. Parten ska underrätta motparten utan dröjsmål. Varar hindret längre än 60 dagar får endera parten säga upp avtalet med omedelbar verkan, utan annan påföljd än att redan utförda leveranser betalas.
Överlåtelse. Ingen av parterna får överlåta avtalet utan motpartens skriftliga godkännande. Godkännande krävs dock inte vid överlåtelse till ett koncernbolag eller i samband med en överlåtelse av hela eller väsentliga delar av verksamheten, förutsatt att förvärvaren övertar avtalet i sin helhet. Kunden ska underrättas om en sådan överlåtelse, och en överlåtelse från Heqtics sida ändrar inte rollfördelningen i § 4 eller varselregeln i § 7.
Vad som gäller efter att avtalet upphört. §§ 4, 4a, 5, 8, 9, 10, 11, 14 och 15 fortsätter att gälla efter avtalets upphörande, i den omfattning deras innehåll kräver det. Det innebär bland annat att Kundens skyldighet att radera på vår underrättelse (§ 5) och att inte vidareförsälja levererade underlag (§ 10) står kvar även när samarbetet är slut.
Ogiltig bestämmelse. Skulle en bestämmelse i avtalet vara ogiltig eller omöjlig att verkställa påverkas inte avtalet i övrigt, och bestämmelsen ska tolkas så att dess syfte uppnås så långt lagen tillåter.

15. Tillämplig lag och tvist

Svensk lag tillämpas. Tvist ska i första hand lösas genom förhandling. Om förhandling inte leder till lösning avgörs tvisten i allmän domstol med Stockholms tingsrätt som första instans.

16. Kontakt

Frågor om avtalet eller dataskydd: sam@heqtic.se. Klagomål kan också riktas till Integritetsskyddsmyndigheten (IMY), imy.se.