Startup-land: Her er de cowboytrick, der gav Queue-it succes

Danske Queue-it har fået over 500 mio. mennesker til at vente i kø på at få adgang til overbelastede hjemmesider. Der skulle næsten ingen markedsføring, men en del cowboytrick til, før it-iværksætternes idé slog igennem.

Hvordan får man folk til at vælge en løsning, som de ikke engang aner eksisterer?

Det spørgsmål stillede de tre stiftere af danske Queue-it sig for fem år siden, da de barslede med planerne om at lancere et dengang stort set ukendt fænomen: Et cloudbaseret køsystem til hjemmesider, der var overbelastet af for meget trafik. Som eksempelvis skat.dk, når årsopgørelsen bliver frigivet, og horder af danskere stormer mod websitet for at finde ud af, om de skal have penge tilbage i skat.

Dengang var den typiske løsning på overbelastning, at man måtte opgradere serverkapaciteten. En både dyr og svært skalerbar løsning. For hvis spidsbelastningen kun opstod en gang om året, så stod man pludselig med dyr hardware, der ikke blev brugt resten af årets 364 dage.

Queue-its løsning går ud på at aflaste hjemmesiderne ved at parkere besøgende i kø i Amazons sky og gradvist give dem adgang til de spidsbelastede sider igen.

»Vi var inspireret af artikler i medierne om websites, der crashede, når de havde for mange brugere. Det var en lidt cowboyagtigt fed udfordring at løse,« siger forretningsdirektør af Queue-it Camilla Ley Valentin, der også blev kåret som årets kvindelige iværksætter i 2012, til Version2. Hun startede it-virksomheden sammen med Martin Pronk og Niels Henrik Sodemann.

Selvom Queue-its køsystem oftest er billigere end at opgradere serverne, var det alligevel en udfordring at få folks øjne op for det.

»Det har været en af vores helt store udfordringer, at vores køsystem er en helt ny måde at gribe det an på. Man skal derhen, hvor man opfatter det på lige fod med andre performance-værktøjer, og det sker ikke lige over en nat,« siger Camilla Ley Valentin.

I dag har over en halv mia. mennesker - eller ca. syv pct. af verdens befolkning - været igennem det danske køsystem, men før det kom så vidt, gik der lang tid, før ideen slog igennem. Queue-its grundlæggere havde dog et trumfkort i ærmet, der lå i selve den måde, deres produkt var designet på.

Måtte bruge cowboytrick for at få foden indenfor

Da de tre it-iværksættere i starten prøvede at sælge ideen om deres køsystem, slog de hovedet mod en mur.

»Kunderne sagde, at »det lyder rigtig smart, men fortæl det til nogle andre, for vi har ikke brug for det,« siger Queue-its tekniske direktør og medstifter, Martin Pronk, og fortæller om udfordringerne ved at være en lille startup:

»Det er nemmere at overbevise om, at Queue-it er det rigtige, når vi kan lave kundereferencer med store internationale brands,« siger han.

Iværksætterne brugte derfor flere små cowboytrick i starten for at fremstå som en mere etableret virksomhed. Eksempelvis undlod de at skrive virksomhedens adresse på deres hjemmeside, så kunderne ikke kunne søge på den og få en idé om, hvor lille virksomheden var på det tidspunkt. Ofte lod de også, som om de omstillede telefonen til forskellige afdelinger i virksomheden, selvom det kun var de tre grundlæggere, der tog telefonen. Desuden satte de flere internationale telefonnumre op, så især amerikanske kunder fik indtrykket af, at virksomheden havde en amerikansk afdeling.

»Det er nogle små trick, som de fleste i startup-miljøet bruger,« tilkendegiver Camilla Ley Valentin.

Det lykkedes også kun at få de første kunder med ideen om et køsystem, fordi iværksætterne allerede havde nogle forretningsforbindelser, der stolede på dem.

»De første salg var ikke produktsalg, men menneskesalg. De måtte have tiltro til os,« siger Martin Pronk.

Det blev 169.000 vildtjægere, der i 2011 skulle prøve at stå i kø hos Queue-it for første gang.

Læs også: 169.000 jægere indberetter døde dyr med cloud-baseret køsystem

Køsystemet fik sin jomfrutur hos Naturstyrelsen, da jægerne skulle foretage den årlige fornyelse af deres jagttegn på nettet og indberette, hvad de havde skudt. Det var en begivenhed, som før havde lagt styrelsens hjemmeside ned, men denne gang holdt systemet næsen oven vande.

Et system, der automatisk markedsfører sig selv

Queue-its store danske gennembrud kom, da Skat i 2012 valgte at lægge køsystemet ind på sin hjemmeside for at forhindre overbelastning, når danskerne skulle ind at læse deres årsopgørelser.

Læs også: Du er nummer 10.549 i køen - Skat parkerer danskerne i skyen for første gang

Hele humlen i forretningen var, at når så mange mennesker oplevede køsystemet, ville der altid være nogle potentielle kunder iblandt dem såvel som journalister, der ville skrive om »det nye køfænomen«. Det gjaldt ikke mindst her på Version2, men også i andre lande har Queue-its anderledes tilgang til at håndtere overbelastede hjemmesider skabt opmærksomhed.

»Det er noget, folk taler om, når vi kommer til et nyt sted,« siger Camilla Ley Valentin.

Efter at et lokalt billetsystem i Chile havde brugt Queue-it til at aflaste hjemmesiden mod 400.000 billethungrende mennesker, der forsøgte at få fingrene i en festivalbillet, gik det stærkt for iværksætterne.

Blandt festivalgængerne var nogle af it-folkene bag landets største webshops, og de kontaktede derefter Queue-it, da e-handlens svar på Black Friday kaldet Cyber Monday nærmede sig og truede med at lægge deres hjemmesider ned.

Da den store e-shoppedag var ovre, havde over en tredjedel af Chiles befolkning været igennem Queue-its køsystem - opmærksomheden om det spredte sig helt automatisk.

»Vi har ikke gjort noget for at få kunder i Sydamerika ud over at få den første deal igennem i forbindelse med festivalbilletterne,« siger Camilla Ley Valentin og fortæller, at iværksætterne hverken har lavet SEO-optimering, opsøgende salg eller andre lokale tiltag for at vinde kunder i Sydamerika.

»Vi er lidt blown away over, hvad der sker. Det er vokset eksponentielt« siger hun.

Forældede databaser bag Queue-its succes

En af grundene til, at Queue-its løsning har vundet indpas hos store kunder som blandt andet Skat, Tickets.com og WWF, er, at mange virksomheder stadig benytter sig af relationelle databaser, der er kendt siden 1960’erne, og som ofte bliver flaskehalsen i systemerne, når tusindvis af brugere klikker sig ind ifølge Martin Pronk. Derfor er køløsningen ofte den hurtigste udvej og det billigste alternativ til at skifte hele systemet.

»Det er let at sætte flere servere på for at imødegå belastning, men svært at skalere databaserne eller betalingsudbyderne,« siger han og påpeger, at Queue-it først kommer til sin ret, når brugerne på hjemmesiden indgår en transaktion enten ved at købe noget eller registrere sig på sitet. I de tilfælde skal der skrives til databaserne eller interageres med betalingsudbyderne, og så kan de ældre databasesystemer hurtigt komme til kort:

»Det er super svært og dyrt at skalere databaser til de her enkeltstående begivenheder, hvor systemet bliver overbelastet,« siger Martin Pronk og fortsætter:

»Stort set alle kunder bruger relationelle databaser. Det er en samlet kæde, der skal hænge sammen, og den er ikke stærkere end det svageste led.«

Ofte har Queue-its kunder investeret mio. af kr. i deres databaser og er derfor ikke tilbøjelige til lige at udskifte hele systemet til eksempelvis NoSQL-databaser, der ifølge Martin Pronk skalerer bedre, men samtidig også fungerer dårligere til mange forretningssystemer.

»Det er ikke noget, man bare knipser væk og flytter,« siger han og er ikke bange for, at Moores lov skal gå hen og gøre it-virksomhedens produkt overflødigt om nogle år, når den øgede computerkraft kan håndtere flere brugere samtidigt:

»Hjemmesider bliver ved med at gå ned. Man bliver altid ved med at lave systemerne mere og mere komplekse, så vi går altid lige til grænsen og ud over. Sådan er vi mennesker.«

Iværksætterne begyndte at tjene penge på Queue-it i 2012 og havde sidste år et overskud på 750.000 kr. Målet er dog ikke at øge overskuddet, men at få udvidet virksomheden og blive ved med at være »den førende køplatform i verden«. Og så satser de også på at kunne sælge virksomheden en dag, når der er gået hverdag i den.

»Vi ser mere os selv som opfindere end driftsfolk. Vi er stadig i vækstfasen, men på et tidspunkt bliver det hverdag, og så er der nok andre, der er bedre til det,« siger Camilla Ley Valentin.

Startup-land: Version2 stiller hver uge skarpt på de mest spændende danske it-iværksættere og fortæller historien om deres sejre og nederlag. Synes du, vi mangler nogen? Så skriv til ecl@version2.dk.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Nørregaard Blogger

Jeg mindes at jeg faktisk var en af dem, der oplevede at blive stillet om i "hovedkontoret" da vi var i dialog om netop jagttegnssystemet :-)

Selvom jeg kendte Martin (og Dorte Hidan som var der dengang) lidt i forvejen var det vigtige (eller heldige) nok, at QueueIT kort tid forinden havde holdt en reception for venner af huset hvor de fortalte om konceptet. Da så Naturstyrelsen fortalte mig om det årligt tilbagevendende problem kort tid efter, var QueueIT top-of-mind. Så et råd til start-ups er at huske at der er mere i opgaven end produkt + salg, nemlig at netværke. Måske er konsulenter særligt gode at få med da de jo kommer vidt omkring til kunder som det ellers kan være svært at få kontakt med.

Det glæder mig at QueueIT har kunne bide sig fast. For det er ikke altid bare et spørgsmål om at kunne eller ikke at kunne skalere hardware. Nogle datalogiske problemer (og kundeoplevelser) kan bare ikke skaleres så meget endda. Så også om 5 år er der uanset Mores lov brug for nogle som QueueIT.

  • 3
  • 0
Morten Bøgh

Queue-it's succes er nok også sikret fremover: De 'forældede databaser', SQL-databaserne, er kommet for at blive. De fungerer bedre til mange forretningssystemer - hvilket artiklen ovenfor da også får nævnt i en bisætning.

Standard-eksemplet på den moderne noSQL-verden er 'Amazon' som bruger et database-setup som skalerer ubegrænset med tilføjelse af servere, fordi det et system uden tværgående sammenhænge. Det er derfor man i købssituationen i Amazon fx. får at vide at der er ca 8 bøger tilbage: Applikationen holder ikke styr på hvad de andre instanser af databasen (de andre servere) foretager af salg, men baserer sig på at med jævne mellemrum modtage en lageroptælling. Og derfor sker det ind i mellem at man, efter at have betalt bogen, får en mail om at den er udsolgt, men der forventes ny leverance om et par måneder, og at pengene først vil blive trukket når bogen er afsendt. Det er så en ok afvejning mellem ikke helt korrekte svar i købssituationen og et systemdesign som skalerer med belastningen.

Men: Hvis man lavede banker og skattesystemer i samme design, så ville manglerne opleves som massive. Standard-eksemplet er at et delsystem i banken autoriserer en overførsel fra konto A til konto B, hvorefter ejeren af konto A hæver hele indeståendet på kontoen. Det bliver noget rod hvis overførslen til konto B i forvejen havde lænset kontoen, og hvis denne transaktion kørte på en anden instans af databasen, uden tværgående sammenhæng med den instans af databasen som (tilfældigvis) håndterer ejerens transaktion. SQL håndterer tværgående sammenhænge, hvilket er ressourcekrævende, men kan være nok så nyttigt. Det kan være til at leve med at Amazon sælger den samme bog to gange, men den går ikke i en bank. Det vil ikke opleves postivt når man får tilsendt en mail om at man skal betale de hævede penge tilbage.

Dvs. et frit skalerbart køsystem foran SQL-baserede IT-systemer er et design som med et vist held kombinerer det bedste fra to verdener.

  • 1
  • 0
Allan Ebdrup Blogger

Historien minder lidt om hotmail og deres signatur i mails send derfra. Super gået af QueueIT.

Ang. Relationelle databaser. Det er faktisk ganske muligt at lave synkroniseringspunkter der er gode nok til pengeoverførsler. Helt uden SQL, relationelle databaser eller deres transaktioner (og derfor også i et design baseret på noSQL). Det sker for eksempel hver gang du flytter penge fra et banksystem til et andet. (Og det er bare et eksempel, der er mange mange andre. Verden kører ikke i een stor RDBMS)

De overførsler som jo for nyligt er blevet næsten øjeblikkelige.

Derudover klinger det også lidt hult med Relationelle databasers fortæffeligheder til transaktioner, når jeg tænker på hvor tit jeg har set folk skrue på deres isolationlevels (hånden op hvis du kører serializable i dit høj-volumen produktionssystem)

  • 0
  • 0
Peter Stricker
  • 1
  • 0
Allan Ebdrup Blogger

Ved at sætte en grænse for transaktionsstørrelsen, gør bankerne inkonsistensen til en neglicerbar risiko, men inkonsistensen er stadig til stede.


Det er rigtigt at den mulighed for inkonsistens er der for kreditkort. Den er til stede fordi intet må komme i vejen for at du kan bruge penge i et voldsomt distribueret system - (det er jo her at bankerne tjener penge).
Jeg tvivler på at pengeoverførsler mellem banker tillader inkonsistens, men selv om de skullle, så er min pointe stadig valid, nemlig at man sagtens kan flytte penge uden RDBMS transaktioner, og at det sker i stor stil i verden i dag - det er sådan tingene fungerer.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Standard-eksemplet på den moderne noSQL-verden er 'Amazon' som bruger et database-setup som skalerer ubegrænset med tilføjelse af servere, fordi det et system uden tværgående sammenhænge. Det er derfor man i købssituationen i Amazon fx. får at vide at der er ca 8 bøger tilbage: Applikationen holder ikke styr på hvad de andre instanser af databasen (de andre servere) foretager af salg, men baserer sig på at med jævne mellemrum modtage en lageroptælling. Og derfor sker det ind i mellem at man, efter at have betalt bogen, får en mail om at den er udsolgt, men der forventes ny leverance om et par måneder, og at pengene først vil blive trukket når bogen er afsendt. Det er så en ok afvejning mellem ikke helt korrekte svar i købssituationen og et systemdesign som skalerer med belastningen.


Nej det er ikke sådan NoSQL virker. Du kan sagtens proppe det hele ind i en stor transaktion i NoSQL (så længe du benytter een der understøtter transaktioner), det er et valg Amazon har foretaget.
Mange af Amazons varer er ikke på lager hos Amazon, men hos underleverandører, og derfor vil du opleve at "varelageret" hos Amazon ikke er 100% optalt, i forhold til underleverandørens.
Det er meget naturligt - det samme fænomen som betalingskort og overførsler mellem banker, handler i al almindelighed mv. benytter - dog er de implementeret på RDBMS.

RDBMS og den 2D view på verden med Square Tables, passer bare ikke særlig godt til at beskrive alle de sammenhænge man kunne tænke sig. Nogle gange har man brug for mere simple key/value stores, document stores, graph databaser eller andet.
Og ofte har man brug for ikke at ende i distribuerede transkationer, eller bare transationer for den sags skyld - det er ikke altid alle fire ACID elementer man har brug for.

  • 0
  • 0
Morten Bøgh

Jo - selvfølgeligt kan man lave synkroniseringspunkter 'selvom' man bruger noSQL. Man kan også programmere hele bankapplikationen i Z80 maskinkode, og opnå perfekt synkronisering af konti på tværs af transaktioner - det er bare en helt enormt krævende opgave. Det nemmeste er at bruge en SQL-database (også kaldet RDBMS-database) hvis synkronisering er i focus. Der er alternativer, og de kommer stærkt på banen hvis man reelt ikke har brug for de services som en SQL-database tilbyder. Vælg værktøj udfra opgaven.

Og ja, store dele af bankernes transaktioner kører ikke synkroniseret mod en kontoføring. Men kærnesystemet i banken gør.

Men det ændrer alt sammen ikke på konklusionen i mit indlæg: Hvis synkronisering er i focus (dvs. hvis det er vigtigt at systemet ikke sælger den samme bog to gange), kan din applikation ikke skaleres lineært ved at tilføje flere servere: Mængden af synkroniserings-handshakes mellem serverne vil på et tidspunkt bringe systemet i knæ. Det gælder uanset om du programmerer synkronseringen i SQL, i noSQL eller i Z80 maskinkode, eller hvad du gør. Dvs. istedet for at opskalere systemet mod tilsandings-grænsen, kunne man overveje et opskalerbart køsystem foran applikationen.

Queue-it har potentiale, og det skyldes ikke at vi andre bruger 'forældede databaser'. Potentialet skyldes at de adresserer et generelt problem.

  • 0
  • 1
Allan Ebdrup Blogger

> Vælg værktøj udfra opgaven.

Helt enig. Jeg vil så bare hælde til, at med de mange datastores der er at vælge imellem i dag, vil der altid være mindst et, sikkert flere, bedre alternativer end en af de store traditionelle RDBMS'er. Til enhver usecase.

  • 0
  • 0
Log ind eller Opret konto for at kommentere