Købsguide

Kravspecifikation til digitalt ventelistesystem for andelsboligforeninger

Når en andelsboligforening skal vælge ventelistesystem, bør bestyrelsen ikke kun spørge efter pris. Den bør spørge efter regler, dokumentation, GDPR, betaling, boligtilbud og hvordan systemet fungerer den dag en ny bestyrelse overtager ansvaret.

Formålet med en kravspecifikation

En kravspecifikation gør det lettere at sammenligne ventelistesystemer på andet end salgsord og månedspris. Den hjælper bestyrelsen med at beskrive, hvad foreningen faktisk har brug for, og hvilke krav der skal være opfyldt, før listen flyttes fra regneark, administratorindbakke eller gamle manuelle arbejdsgange.

Brug siden som udgangspunkt for intern afklaring, leverandørdialog og demo. Kravene kan kopieres ind i bestyrelsens beslutningsmateriale og tilpasses foreningens vedtægter.

12 krav et ventelistesystem bør opfylde

Regler for intern og ekstern venteliste

Systemet skal kunne skelne mellem intern og ekstern venteliste, forskellige prioriteringer og særlige regler uden at blande køerne sammen.

Dokumenteret anciennitet

Opskrivningsdato, statusændringer, betalinger og eventuelle afbrydelser skal kunne forklares, så placering på listen ikke bliver en mundtlig vurdering.

Boligtilbud i korrekt rækkefølge

Ved ledig bolig skal systemet kunne udpege relevante personer, sende tilbud, registrere svar og dokumentere, hvorfor nogen eventuelt springes over.

Svarfrister og påmindelser

Foreningen bør kunne se frister, manglende svar og næste skridt uden at lede i mailtråde eller personlige kalendere.

Betaling og fornyelse

Opskrivningsgebyr, årlig fornyelse og manglende betaling bør hænge sammen med aktiv status, så listen ikke fyldes med personer uden reel interesse.

Selvbetjening for medlemmer og ansøgere

Personer på listen bør kunne holde kontaktoplysninger og relevante valg opdateret, så bestyrelsen ikke skal rette data manuelt.

Adgangsstyring

Bestyrelse, administrator og eventuelle udvalg skal have adgang efter rolle. Ikke alle bør kunne se eller ændre alt.

GDPR, sletning og dataminimering

Systemet skal understøtte klare formål, begrænset adgang, slettepolitik, eksport og en praksis hvor gamle eller unødvendige oplysninger ikke lever videre.

Historik og revisionsspor

Det skal være muligt at se, hvem der ændrede hvad, hvornår og hvorfor, især ved boligtilbud, klager eller overdragelse til ny bestyrelse.

Import fra eksisterende data

Gamle regneark, PDF-lister og administratorudtræk skal kunne ryddes op, valideres og importeres uden at miste vigtig historik.

Rapporter til bestyrelse og administrator

Foreningen bør kunne udtrække status på liste, betaling, boligtilbud, passive personer og ændringer uden manuel optælling.

Gennemsigtig pris og support

Leverandøren bør kunne forklare pris, opstart, drift, betalingsgebyrer, support og datamigrering, så totalprisen ikke først bliver tydelig efter valg.

Spørgsmål til leverandører

Når bestyrelsen taler med en leverandør, bør spørgsmålene handle om konkrete situationer. Et system kan se pænt ud i en demo og stadig være svagt, når en person klager over placering, når en bolig skal tilbydes hurtigt, eller når en ny kasserer skal forstå betalingshistorikken.

  • Hvordan dokumenterer systemet en persons placering på ventelisten?
  • Kan systemet håndtere både intern og ekstern liste efter vores vedtægter?
  • Hvad sker der, hvis en person ikke svarer inden fristen?
  • Hvordan importeres vores nuværende regneark, og hvem kvalitetssikrer data?
  • Hvordan ser totalprisen ud med opstart, drift, support og betalinger?
  • Hvordan får vi data ud igen, hvis foreningen senere skifter løsning?

Vurderingsmodel for bestyrelsen

Giv hvert krav en simpel vurdering: opfyldt, delvist opfyldt eller ikke opfyldt. Notér også dokumentation, pris og risiko. Den bedste løsning er ikke nødvendigvis den med flest funktioner, men den der passer bedst til foreningens regler og kan forklares roligt til medlemmerne.

Kriterium Hvad skal vurderes? Hvorfor er det vigtigt?
ReglerIntern/ekstern liste, anciennitet, prioritet og spring i rækken.Fejl i regler skaber mistillid og ekstra bestyrelsesarbejde.
DriftDaglig brug, selvbetjening, betaling, frister og rapporter.Systemet skal spare tid i hverdagen, ikke kun se godt ud i opstarten.
TillidHistorik, GDPR, adgangsstyring, eksport og dokumentation.Foreningen skal kunne forklare beslutninger og håndtere persondata ordentligt.
ØkonomiPris, oprettelse, drift, betalingsgebyrer, support og migrering.Totalprisen skal kunne sammenlignes med både faste abonnementer og aktivitetsbaserede modeller.

Hvordan Andels Venteliste passer til kravene

Andels Venteliste er bygget omkring de samme krav: korrekt anciennitet, strukturerede boligtilbud, tydelig historik, GDPR-orienterede arbejdsgange, import fra eksisterende lister og en fast abonnementspris hvor foreningen beholder 100% af ventelistegebyrerne. Se også feature-overblikket, prissammenligningen og prisberegneren.

Ofte stillede spørgsmål om kravspecifikation

Skal en lille forening lave en kravspecifikation?

Ja, men den kan være kort. Små foreninger har stadig brug for at beskrive regler, ansvar, betaling, adgang og hvad der sker ved boligtilbud.

Hvem bør godkende kravene?

Bestyrelsen bør godkende kravene, og administrator bør inddrages, hvis administrator håndterer venteliste, betaling eller boligtilbud i praksis.

Kan kravene bruges til at sammenligne priser?

Ja. Når kravene er tydelige, bliver det lettere at sammenligne totalpris, fordi man kan se hvilke funktioner, supportopgaver og migreringsopgaver der faktisk er inkluderet.