Integrasjon og konsernløsning
Lekeplassen er den siste permen ingen har digitalisert.
Alle som eier lekeplassapparater har plikt til jevnlig ettersyn og dokumentasjon. Nesten ingen har det i system. Har dere allerede enhetene – som integrasjonspartner, kjede eller forvalter – er dette en modul dere kan legge på, ikke et produkt noen må velge å kjøpe.
Tre måter å bruke Lekko på. Mange trenger mer enn én.
For integrasjonspartnere
Lekeplasskontroll som en modul i deres system
Har dere allerede systemet styrene og forvalterne logger inn i? Vi kobler Lekko på med API, hendelsesvarsler og en innebygd visning i deres farger.
- Boligforvaltningssystemer og styreportaler
- FDV- og driftssystemer
For eget merke
Lekko under deres eget navn
Vil dere tilby lekeplasskontroll til egne kunder uten å bygge noe? Kjør Lekko som det er, med deres logo og deres farger. Ingen utviklere.
- Forvaltere og boligbyggelag med egne kunder
- Alle som heller vil tilby det i eget navn enn å bygge
For kjeder og konsern
Én oversikt over alle enhetene
Femti barnehager eller tre hundre boligselskap? Problemet er å vite hvilke enheter som ikke gjør ettersynet. Konsernstruktur og risikorangert portefølje.
- Barnehage- og skolekjeder
- Kommuner og bydeler
- Eiendomsforvaltere og boligbyggelag
For integrasjonspartnere
Brukeren skal ikke måtte logge inn et annet sted.
Har dere allerede portalen styrene og forvalterne bruker, er det der lekeplassen hører. Ettersynet kan ligge som en visning i deres app, i deres farger, med innloggingen brukeren allerede har – eller dere kan hente dataene over API og bygge grensesnittet selv.
Deres merke, ikke vårt
Logo, farger og typografi settes per partner. Ingen Lekko-merking hvis dere ikke vil ha den.
Ett statusfelt, om det er nok
Vil dere bare vise «lekeplass: kritisk avvik» på eiendomskortet, er det ett API-kall.
Mobil først, fordi runden går ute
Selve ettersynet gjøres med telefonen på lekeplassen. Den innebygde visningen er bygget for det.
Sameiet Bjørkelia · HMS
Lekeplass
7 apparater · Sist kontrollert 24. juli
Innebygd visning – deres farger, deres innlogging, deres navigasjon.
API og hendelser
Alt appen gjør, kan gjøres over API.
Les for å vise status der brukerne deres allerede er. Skriv for å opprette enheter automatisk når de opprettes hos dere. Og få et varsel når noe krever handling, så dere ikke må spørre oss hvert kvarter.
Status til deres eget dashbord
{
"data": [
{
"id": "unit_8fk21",
"name": "Sameiet Bjørkelia",
"external_id": "OBJ-40182",
"status": "critical",
"equipment_count": 7,
"open_defects": { "minor": 2, "moderate": 1, "critical": 1 },
"oldest_open_defect_days": 34,
"inspections": {
"routine_visual": { "last": "2026-07-24", "next_due": "2026-07-31" },
"operational": { "last": "2026-06-02", "next_due": "2026-08-16" },
"annual_main": { "last": "2025-09-11", "next_due": "2026-09-11" }
},
"report_url": "https://api.lekko.tech/v1/units/unit_8fk21/report.pdf"
}
],
"next_cursor": "eyJvIjoyNX0"
}Opprett en enhet når den opprettes hos dere
{
"name": "Borettslaget Nordvik",
"external_id": "OBJ-40199",
"organization_id": "org_kunde_4471",
"template_id": "tpl_borettslag_standard",
"users": [
{ "email": "styret@nordvik.no", "role": "admin" },
{ "email": "vaktmester@drift.no", "role": "inspector" }
]
}
→ 201 Created
{ "id": "unit_91xz4", "status": "ok", "setup_url": "https://app.lekko.tech/…" }Varsel når noe krever handling
{
"event": "defect.critical",
"created_at": "2026-07-30T09:14:22Z",
"unit": { "id": "unit_8fk21", "external_id": "OBJ-40182" },
"defect": {
"id": "def_2p07m",
"equipment": "Huske ved sandkassa",
"finding": "Slitt S-krok i opphenget",
"severity": "critical",
"action": "Apparatet er sperret",
"due_date": "2026-07-31"
},
"signature": "sha256=a91f…"
}REST-API over hele datamodellen
Alt appen gjør, kan gjøres over API: enheter, apparater, ettersyn, avvik og rapporter. Les for å vise status i deres eget grensesnitt, skriv for å opprette enheter og apparater automatisk.
- Organisasjoner og enheter – opprett en enhet når et boligselskap opprettes hos dere
- Apparater med type, plassering, bilde og historikk
- Ettersyn med resultat per sjekkpunkt, og hvem som utførte det
- Avvik med alvorlighetsgrad, frist, ansvarlig og lukkedato
- Rapport som PDF eller strukturert JSON for en valgt periode
Varsler når noe skjer
Dere skal ikke måtte spørre oss hvert kvarter om noe har endret seg. Vi varsler dere i det øyeblikket det skjer, så hendelsen kan havne i deres eget varselsystem, deres oppgaveliste eller deres oppfølging av frister.
- defect.created og defect.critical – et kritisk funn kan opprette en sak hos dere automatisk
- inspection.completed – oppdater status i deres portal i samme sekund
- inspection.overdue – purringen kan gå gjennom deres egne kanaler, med deres tone
- Signerte meldinger, og nye forsøk hvis kallet feiler, så ingen hendelser går tapt om systemet deres er nede en stund
Innebygd visning i deres farger
For brukeren skal det se ut som en del av portalen deres. Ettersynsflyten kan legges inn som en visning i deres app, med deres logo, farger og typografi.
- Ettersyn, avviksliste og rapport som innebygde visninger
- Egne farger, logo og navn – ingen Lekko-merking hvis dere ikke vil
- Fungerer på mobil, som er der ettersynet faktisk gjøres
- Eller motsatt vei: bare et statusfelt per enhet, som dere viser i deres eget grensesnitt
Innlogging brukeren allerede har
Ingen skal måtte huske et passord til noe de bruker fire ganger i året. Brukerne kommer inn med kontoen de har hos dere.
- OIDC eller SAML mot deres identitetsleverandør
- Eller signert overlevering fra deres backend – brukeren merker ingen innlogging
- Roller styres fra deres side og speiles hos oss
- Fjernes en bruker hos dere, er tilgangen borte hos oss
Nye enheter settes opp av seg selv
En integrasjon som krever manuelt arbeid per enhet skalerer ikke. Nye enheter opprettes automatisk fra deres system, med riktige innstillinger fra første dag.
- Opprett enhet, brukere og roller i ett kall
- Standard sjekklister og intervaller settes fra en mal dere styrer
- Avsluttes en enhet hos dere, arkiveres den hos oss – med historikken intakt
Testmiljø før noe er i produksjon
Dere får et eget sandkassemiljø med testdata, egne nøkler og ingen kobling til virkelige enheter. Utviklerne kan bygge ferdig før noen tar en avgjørelse.
- Egne API-nøkler for test og produksjon
- Realistiske testdata: enheter, apparater, ettersyn, avvik
- Varsler mot deres testmiljø
For eget merke
Samme app. Deres logo og deres farger.
Ikke alle vil bygge en integrasjon, og ingen bør måtte gjøre det for å tilby lekeplasskontroll til sine egne kunder. Kjør Lekko som det er, med deres profil lagt over. Vi setter det opp – dere trenger ingen utviklere.
Virksomhet
Sameiet Bjørkelia
Status
Apparater
Ettersyn
Avvik og tiltak
Status
Sameiet Bjørkelia
3 ting trenger oppmerksomhet
Se listen under og følg opp.
Til oppfølging
Forfalt ettersyn
Babyhuske
Visuelt forfalt
Åpent avvik
Slitt S-krok
Huske
Virksomhet
Sameiet Bjørkelia
Status
Apparater
Ettersyn
Avvik og tiltak
Status
Sameiet Bjørkelia
3 ting trenger oppmerksomhet
Se listen under og følg opp.
Til oppfølging
Forfalt ettersyn
Babyhuske
Visuelt forfalt
Åpent avvik
Slitt S-krok
Huske
Deres profil, ikke vår
Logo og farger gjennom hele appen. Kundene deres kjenner igjen avsenderen i grensesnittet og på rapporten de arkiverer.
- Logo og fargeprofil settes opp av oss
- Rapporten kommer med deres logo i topptekst
Samme produkt, ingen egen versjon
Dette er ikke en avstøpning som blir liggende igjen. Det er den samme appen alle andre bruker, med en annen profil lagt over.
- Nye funksjoner kommer samtidig som hos alle andre
- Rettelser og sikkerhetsoppdateringer følger automatisk
- Ingen egen kodebase å vedlikeholde – for noen av oss
Dere eier kunderelasjonen
Kundene er deres. Vi står for driften og for at forskriftskravene er dekket, og holder oss i bakgrunnen.
- Egen organisasjon per kunde, samlet i deres oversikt
- Dere ser porteføljen på tvers, kunden ser bare sin egen
- Hva som skal stå om Lekko i vilkårene, avtales i oppsettet
I gang uten utviklere
Hele forskjellen fra plattform-sporet: her er det ingenting å bygge. Vi setter opp profilen, dere inviterer kundene.
- Vi setter opp profilen og malene
- Dere legger inn kundene, eller vi importerer en liste
- Første kunde kan være i gang uten at noen har skrevet kode
Marginer, supportansvar og hvem som fakturerer sluttkunden avtales per partner. Tar dere støtten og faktureringen selv, ser avtalen annerledes ut enn om vi gjør det. Ta kontakt, så går vi gjennom det konkret.
For kjeder og konsern
Problemet er ikke ett ettersyn. Det er å vite hvem som ikke gjør dem.
Med femti barnehager eller tre hundre boligselskap er spørsmålet aldri «hvordan gjennomfører vi en kontroll». Det er «hvilke av enhetene våre ligger dårligst an akkurat nå». Porteføljedashbordet svarer på det, sortert etter risiko og ikke etter alfabet.
312
enheter
6
kritiske avvik
23
forfalte ettersyn
94 %
gjennomført siste 30 dager
| Enhet | Region | Apparater | Status | |
|---|---|---|---|---|
| Sameiet Bjørkelia | Oslo vest | 7 | Kritisk avvik | Åpent i 34 dager |
| Solstua barnehage | Bergen | 12 | Forfalt | Visuelt ettersyn 19 dager over |
| Borettslaget Nordvik | Oslo øst | 4 | Nær forfall | Funksjonsettersyn om 4 dager |
| Lundeveien barnehage | Trondheim | 9 | Åpne avvik | 2 moderate, frist 12. aug |
| Sameiet Kalvøya | Oslo vest | 5 | I orden | Hovedettersyn 11. sep |
| Fjellstua barnehage | Bergen | 14 | I orden | Alle nivåer à jour |
Viser 6 av 312 · Sortert etter risiko: kritiske avvik, deretter forfalt, deretter nær forfall
Konsernstruktur med felles krav
Bygg strukturen slik organisasjonen faktisk ser ut: konsern, region, enhet. Innstillinger settes én gang på toppen og gjelder for alle enhetene under, med rom for lokale tilpasninger der det trengs.
- Så mange nivåer som organisasjonen har – konsern, region, kommune, avdeling
- Sjekklister, intervaller og varslingsfrister gjelder nedover
- En enhet kan legge til egne punkter, men ikke fjerne konsernets
- Flytt en enhet mellom regioner uten å miste historikken
Porteføljedashbord rangert etter risiko
Ikke en liste over alle enhetene i alfabetisk rekkefølge. En liste som starter med den enheten dere bør ringe i dag.
- Kritiske avvik først, deretter forfalte ettersyn, deretter nær forfall
- Filtrer på region, enhetstype eller ansvarlig
- Se hvor lenge et avvik har stått åpent – ikke bare at det står åpent
- Enheter som ikke har rapportert i det hele tatt, vises for seg
Delegert administrasjon
En regionleder skal se sine enheter, ikke alle. Den som drifter én barnehage skal ikke kunne endre konsernets sjekklister.
- Roller per nivå: konsern, region, enhet
- Leseroller for revisjon, HMS og styret
- Revisjonslogg over hvem som endret hva, og når
Felles sjekklister, styrt sentralt
Skal alle enhetene kontrollere det samme, må noen kunne bestemme det ett sted. Endrer dere malen, gjelder den fra neste ettersyn i hele porteføljen.
- Legg til et punkt sentralt – det dukker opp hos alle ved neste runde
- Ulike maler for ulike enhetstyper: barnehage, skole, uteområde
- Historikken viser hvilken versjon av malen et ettersyn ble gjort etter
Årshjul og bemanning på tvers
Ukentlig visuelt ettersyn på femti enheter er femti runder i uka. Årshjulet viser hva som skal gjøres når, per enhet og per person, så arbeidet kan fordeles før det forfaller.
- Ukens og månedens runder for hele regionen på én skjerm
- Enheter uten en aktiv ansvarlig løftes fram – ferie og turnover er den vanligste grunnen til at det stopper
- Påminnelsen går til den som faktisk skal gjøre jobben, ikke til en felles innboks
Samme apparat, samme feil, flere enheter
Er S-kroken slitt på én huskemodell, er den sannsynligvis slitt på de nitten andre av samme modell. Apparatene registreres med type og produsent, så et funn kan slås opp på tvers av porteføljen.
- Finn alle enheter med samme apparattype eller produsent
- Se om et funn gjentar seg – og hvor ingen har sett etter ennå
- Tall å ta med til leverandøren, i stedet for en følelse
Eksterne får tilgang bare der de skal
Hovedettersynet skal gjøres av en sakkyndig. Den sakkyndige, driftsleverandøren og revisjonen trenger ulik tilgang, og ingen av dem trenger å se hele konsernet.
- Gi en sakkyndig tilgang til utvalgte enheter, for en avgrenset periode
- Driftsleverandøren kan registrere ettersyn uten å kunne endre maler
- Leserolle for revisjon og styret
- Tilgangen løper ut av seg selv – ingen glemte brukere
Samlerapport for hele porteføljen
Én rapport for konsernet, én per region, én per enhet – samme datagrunnlag. Til styret og til revisjon.
- PDF for lesing, Excel og API for videre bearbeiding
- Velg periode og nivå: siste kvartal for én region, siste år for alt
- Nøkkeltall over tid: andel gjennomførte ettersyn, og gjennomsnittlig tid fra funn til lukking
Én avtale, én faktura
Enhetene skal ikke bestille hver for seg med eget kort. Konsernavtale med pris per enhet, og én faktura.
- Pris per enhet, avtalt ut fra volum
- Én faktura til konsernet, med enhetene spesifisert
- Databehandleravtale på konsernnivå – ikke én per enhet
Struktur og felles krav
Sett kravene én gang. La dem gjelde overalt.
Bygg strukturen slik organisasjonen faktisk ser ut, og sett sjekklister, intervaller og varslingsfrister på toppen. Da gjelder de for alle enhetene under. En regionleder ser sine enheter – ikke alle, og ikke bare sin egen.
- Konsern, region og enhet – så mange nivåer dere trenger
- Legg til et sjekkpunkt sentralt, og det gjelder fra neste runde
- En enhet kan legge til lokale punkter, men ikke fjerne konsernets
- Revisjonslogg: hvem endret hva, og når
Gjelder nedover fra konsern
- Sjekklister og egne punkter
- Intervaller og varslingsfrister
- Krav om årlig hovedettersyn
- Rapportmal og logo
Flere organisasjoner
Mange enheter betyr ikke alltid én organisasjon.
En kjede eier enhetene sine selv. En forvalter drifter enheter for kunder som eier dem hver for seg. En kommune har etater med samme forskrift og ulik driftsorganisasjon. Det avgjør hvem som er behandlingsansvarlig, hvem dokumentasjonen tilhører og hva som skjer når en avtale tar slutt – så oppsettet er ikke det samme.
Kjeden
Én virksomhet, mange enheter
KonsernRegionEnhet
Konsernet eier enhetene selv og svarer for dem. Kravene settes på toppen og gjelder nedover, og porteføljen er ett datasett med én eier.
- Én behandlingsansvarlig, én databehandleravtale, én faktura
- Sjekklister og intervaller bestemmes sentralt
- Regionledere ser sine enheter, konsernet ser alle
- Nøkkeltall kan sammenliknes mellom regioner, fordi grunnlaget er likt
Forvalteren
Mange kunder, hver med sine enheter
ForvalterKundeEnhet
Et boligbyggelag eller forvaltningsselskap drifter enheter det ikke eier. Hver kunde er sin egen organisasjon med sine egne data – dere ser alle kundene, kunden ser bare sitt.
- Kundene er adskilt: ingen ser hverandres enheter, avvik eller bilder
- Dere har en forvalterrolle på tvers, med én arbeidsliste for alle kundene
- Rapporten går ut i kundens navn, med kundens logo
- Sier en kunde opp forvaltningsavtalen, følger dataene kunden – ikke dere
Kommunen
Flere etater, samme forskrift
KommuneEtat eller bydelEnhet
Skoler, barnehager, parker og boliger ligger under ulike etater med hver sin driftsorganisasjon, men samme forskrift og samme politiske ansvar. Minstekravene settes sentralt, gjennomføringen ligger hos etaten.
- Felles minstekrav for alle etater, satt ett sted
- Hver etat drifter sine egne enheter, med sine egne folk og leverandører
- Samlet status til kommunedirektør og politisk nivå, uten å be etatene rapportere manuelt
- Alt kan hentes ut som PDF eller Excel til innsyn, journal og tilsyn
Kunder dere forvalter
37 organisasjoner · 214 enheter
Hver kunde er sin egen organisasjon. Kunden ser bare sitt, dere ser alle – og rapporten går ut i kundens navn.
Kunden ser sitt. Dere ser alle. Ingen ser hverandres.
For en forvalter er hver kunde en egen virksomhet med sin egen dokumentasjon og sin egen databehandleravtale. Skillet mellom dem er ikke et filter i grensesnittet, det er selve strukturen – og det er derfor dere kan ha en arbeidsliste på tvers uten at kundene deler noe.
Det gir også et enklere svar på spørsmålet ingen liker å stille i et salgsmøte: hva skjer hvis vi slutter å bruke dere. Dataene tilhører kunden, ikke forvaltningsavtalen.
Det som gjelder uansett modell
Enhetene er adskilte til dere sier noe annet
Utgangspunktet er at en organisasjon bare ser sine egne enheter. Tilgang på tvers er noe som gis bevisst, til en rolle og et nivå – ikke noe som følger av at to enheter ligger i samme system.
En enhet kan ha både eier og forvalter
Enheten har én eier, som eier dokumentasjonen. Andre organisasjoner kan ha tilgang til den – typisk en forvalter, et driftsselskap eller en sakkyndig. Rollen bestemmer hva de kan gjøre, og rapporten går ut i eierens navn.
Bytter en enhet eier eller forvalter, følger historikken enheten
Enheten flyttes til den nye organisasjonen med apparater, ettersyn, avvik og bilder. Den forrige forvalterens tilgang fjernes. Ingen skal måtte begynne dokumentasjonen på nytt fordi en avtale ble reforhandlet.
Enhetene kommer inn uten manuelt arbeid
Tre hundre enheter registreres ikke for hånd. De kan leses inn fra regneark med navn, adresse, region og ansvarlig, eller opprettes over API fra systemet dere har. Apparatene registreres på første runde ute, med bilde og plassering.
Roller og tilganger
Fem roller, og hva de faktisk kan.
«Delegert administrasjon» betyr ingenting før noen ser tabellen. Den som drifter én enhet skal kunne gjøre jobben sin uten å kunne endre konsernets krav, og en sakkyndig som er inne for ett hovedettersyn skal ikke se resten av porteføljen.
| Kan | Konsern | Region | Enhet | Utfører | Leser |
|---|---|---|---|---|---|
| Se porteføljeoversikten | Ja | Eget | Eget | Nei | Eget |
| Gjennomføre ettersyn | Ja | Ja | Ja | Ja | Nei |
| Registrere avvik | Ja | Ja | Ja | Ja | Nei |
| Lukke avvik | Ja | Ja | Ja | Nei | Nei |
| Legge til lokale sjekkpunkter | Ja | Ja | Ja | Nei | Nei |
| Endre maler, intervaller og frister | Ja | Eget | Nei | Nei | Nei |
| Invitere brukere og sette roller | Ja | Eget | Eget | Nei | Nei |
| Hente ut rapport | Ja | Eget | Eget | Eget | Eget |
| Se revisjonsloggen | Ja | Eget | Nei | Nei | Nei |
«Eget» betyr eget nivå og enhetene under det. Utfører er den som går runden – en vaktmester, et driftsselskap eller en sakkyndig – og trenger ikke se resten av porteføljen. Leser er revisjon og styret.
Sikkerhet, personvern og drift
Alt en innkjøper trenger å se, ligger allerede ute.
Databehandleravtalen, listen over underdatabehandlere, hvor dataene ligger og hvordan de hentes ut igjen – publisert og versjonert. Dere kan begynne vurderingen før dere snakker med oss.
Få personopplysninger å vurdere
Lekko handler om apparater, datoer og funn. De eneste personopplysningene er navn og e-post på dem som logger inn, slik at et ettersyn er sporbart til en person.
Data innenfor EU/EØS
Database og bilder ligger hos Amazon Web Services i Frankfurt (eu-central-1). E-post sendes via en leverandør med servere i Irland.
Databehandleravtale og underdatabehandlere på nett
DPA og en oppdatert liste over underdatabehandlere er publisert og versjonert. Dere trenger ikke etterspørre dem for å komme i gang med vurderingen.
Alt kan hentes ut igjen
Hele datasettet kan eksporteres som Excel, PDF og JSON – apparater, ettersyn, avvik og bilder. Ingen innlåsing, og det er et poeng vi mener alvorlig: dokumentasjonen tilhører virksomheten, ikke oss.
Revisjonslogg
Hvem gjorde hva, og når. På konsernnivå betyr det at et ettersyn ikke bare er registrert, men sporbart til en person og et tidspunkt.
Bygget på standardene, ikke på vår tolkning
Sjekklistene følger strukturen i NS-EN 1176 og NS-EN 1177, med henvisning på hvert punkt. Det gjør dem mulige å kryssjekke mot en sakkyndig rapport i stedet for å måtte tas på tro.
Databehandleravtalen og personvernerklæringen er publisert og versjonert – dere trenger ikke etterspørre dem for å begynne vurderingen.
Hvorfor Lekko er enkelt å bygge videre på
Et lite domene, en liten datamodell, og et regelverk som ikke endrer seg hvert år.
Én datamodell, ikke fem integrasjoner
Apparat, ettersyn, sjekkpunkt, avvik, tiltak. Modellen er liten nok å lese på en halvtime og dekker likevel hele regelverket. Det er den som gjør et API mulig i første omgang.
Innholdet er en del av produktet
Sjekklistene, guidene og hjelpebasen er kuratert innhold med kildehenvisninger, ikke tekst noen skrev en gang. Det er den delen som tar lengst tid å bygge opp, og som ikke lar seg kopiere over natten.
Regelverket endrer seg sakte
Lekeplassforskriften er fra 1996. Standardene revideres, men grunnkravene står. Et produkt bygget på dem blir ikke utdatert av neste teknologiskifte.
Markedet er alle som eier en lekeplass
Sameier, borettslag, barnehager, skoler, kommuner, parker. Plikten til jevnlig ettersyn følger eierskapet, og den gjelder uansett hvor mange apparater man har.
Slik kommer vi i gang
Fire steg, og ingen av dem er store.
- 1
En samtale på en halvtime
Dere forteller hva dere har og hvem som skal bruke det. Vi sier hva som er rett vei – API, innebygd visning, konsernstruktur, eller en kombinasjon.
- 2
Vi skisserer løsningen skriftlig
Hvilke endepunkter og hendelser dere trenger, hvordan strukturen og innloggingen skal settes opp, hva som eies av hvem. Kort nok å lese, konkret nok å ta en avgjørelse på.
- 3
Pilot på et utvalg enheter
Ti enheter, én region, eller én kunde. Nok til å se om det virker i praksis, lite nok at ingen tar en stor risiko.
- 4
Utrulling i deres tempo
Konsernavtale, én faktura, og nye enheter som settes opp automatisk fra deres system. Vi følger opp de første ukene tett.
Spørsmål og svar
Kan Lekko ligge inne i vårt eget system, uten egen innlogging?
Ja. Ettersynsflyten, avvikslista og rapporten kan legges inn som innebygde visninger i deres portal, med deres logo, farger og typografi, og med innlogging fra deres identitetsleverandør. Alternativt henter dere bare dataene over API og bygger grensesnittet selv.
Vi forvalter enheter for flere eiere. Kan kundene holdes adskilt?
Ja. Hver kunde er sin egen organisasjon med sine egne enheter, avvik og bilder, og ingen kunde ser en annens. Dere får en forvalterrolle på tvers, med én arbeidsliste for hele porteføljen. Rapporten går ut i kundens navn, og sier en kunde opp forvaltningsavtalen, følger dataene kunden.
Kan én enhet ligge under to organisasjoner?
Enheten har én eier, som eier dokumentasjonen. Andre organisasjoner kan ha tilgang til den – typisk en forvalter, et driftsselskap eller en sakkyndig som skal gjøre hovedettersynet. Rollen bestemmer hva de kan gjøre, og en tilgang kan gis for en avgrenset periode.
Hva skjer hvis en enhet bytter eier eller forvalter?
Enheten flyttes til den nye organisasjonen med apparater, ettersyn, avvik og bilder, og den forrige forvalterens tilgang fjernes. Historikken følger enheten. Ingen skal måtte begynne internkontrollen på nytt fordi en avtale ble reforhandlet.
Hvordan får vi tre hundre enheter inn i systemet?
Enhetene leses inn fra regneark – navn, adresse, region og ansvarlig – eller opprettes over API fra systemet dere har. Apparatene registreres på første runde ute, med bilde og plassering. Vanligvis tas porteføljen i bruk region for region, ikke alt på én dag.
Kan vi styre sjekklistene sentralt?
Ja. Maler settes på konsern- eller regionnivå og gjelder for enhetene under. En enhet kan legge til egne punkter der det er lokale forhold, men ikke fjerne konsernets. Historikken viser hvilken versjon av malen et ettersyn ble gjennomført etter.
Hvem eier dataene?
Virksomheten som har registrert dem. Hele datasettet kan eksporteres som Excel, PDF og JSON, inkludert bilder. Vi mener det er et poeng og ikke en formalitet: internkontrolldokumentasjon skal ikke være noe man mister ved å bytte leverandør.
Hvilke personopplysninger behandler Lekko?
Navn og e-post på dem som logger inn, slik at et ettersyn er sporbart til en person. Resten er apparater, datoer og funn. Det gjør personvernvurderingen kort.
Hvor lagres dataene?
Innenfor EU/EØS. Database og bilder ligger hos Amazon Web Services i Frankfurt (eu-central-1), og e-post sendes via en leverandør med servere i Irland. Databehandleravtale og en versjonert liste over underdatabehandlere er publisert på nettstedet.
Hva kreves av oss teknisk?
For en ren API-integrasjon: at systemet deres kan gjøre HTTP-kall og ta imot varsler. For innlogging uten passord: et OIDC- eller SAML-oppsett, eller en backend som kan signere en overlevering. Dere får et testmiljø med egne nøkler før noe berører virkelige enheter.
Hvordan prises en konsernavtale?
Pris per enhet, satt ut fra volum, med én faktura til konsernet og enhetene spesifisert. For en integrasjon avtaler vi i tillegg hvordan oppsettet skal dekkes. Vi setter prisen i samtalen – det avhenger for mye av antall enheter og hva integrasjonen skal gjøre for at et listepris-tall her ville vært nyttig.
Hva er første steg?
En samtale på en halvtime, der dere forteller hva dere har og hvem som skal bruke det. Skriv til oss via kontaktskjemaet og velg «Integrasjon eller partnerskap», så tar vi det derfra.
Har dere enhetene, har vi resten.
Fortell oss hva dere har og hvem som skal bruke det. Vi sier hva som er rett vei, og hva det krever av dere.