Onderwerp: Nieuw kosten-model?

Bijna 20 jaar geleden zijn we begonnen met de verkoop van hosting.
Onze pakketten zijn nog steeds gebaseerd op de basis die we toen gelegd hebben:
- x MB webspace
- y MB traffiek
- z aantal mailboxen
- 1 database.

Ondertussen is de wereld echter veranderd, en we beginnen met problemen te komen.
We hebben nu websites:
- veel traffiek, weinig space (betalen bij voor traffic)
- veel space, maar geen traffiek (betalen bij voor space)
- heel grote databases (veel CPU), betalen niets bij
- normale databases, maar zeer intensief gebruik (veel CPU), betalen niets bij.
- grote mailboxen van honderden MB, maar niet gebruikt, betalen bij voor space
- kleine mailboxen maar heel intensief gebruikt, betalen niets bij.

Wij zitten te denken aan een sort "credits"-systeem (zoals bij aanbod Virtuele servers), maar dan moet je ook alles kunnen meten (probleem: mysql-cpu gaan meten)
Heeft iemand al zoiets gelijkaardigs gezien, of een gedacht daarover?

Als je na 20 jaar nog steeds alleen maar met MB hosting pakketten werkt dan heb je toch echt zitten slapen. Voornamelijk als je nu pas merkt dat "de wereld echter veranderd is".

Het bedrag dat je ontvangt voor zulke pakketten blijft dus hetzelfde als 20 jaar geleden voor een paar MB's terwijl schijfruimte en dataverkeer met het jaar goedkoper wordt.

Dan ga je nu pas actie ondernemen, omdat je in de problemen komt? Klanten die weglopen, omdat het bijbetalen te duur is?

Ik vind je vraag over credits vrij vaag. Waar wil je het voor gebruiken? Normale pakketten of als er bijbetaald moet worden?

Hopelijk wordt het nieuwe kosten-en-verdien-model niet alleen gebaseerd op een credit systeem. Lijkt me eerder dat je de pakketten eens aan gaat passen.

Ik ben het wel met thenob eens, het zou fijn zijn als er een ander model komt.

Wij werken momenteel ook op basis van aantal bezoekers per maand en de database omvang. De rest is fair use.

De bezoekers kan je uitlezen met een stats oplossing als webalizer.

Het is voor klanten dan ook makkelijker te bepalen welk pakket bij hun past, de meeste weten via Google Analytics wel hoeveel bezoekers er maandelijks zijn.

Sent from my GT-I9505 using webhostingtalk mobile app

Niemand houdt je tegen om een ander model te ontwikkelen.

Het aantal bezoekers en de database omvang zegt ook niet alles. Wat voor site is het (veel grote plaatjes / video's) en hoe is de site opgebouwd qua code.

Idem voor de database hoe deze opgebouwd is etcetera. Webalizer is nou niet bepaald betrouwbaar om stats uit te lezen, dacht ik.

Daarnaast is het nou niet zo ingewikkeld om met een klein webpakket te beginnen en deze te upgraden of te downgraden.

Webalizer is zeker geen goede, maar geeft wel een indicatie die voldoende is om het aantal bezoekers te schatten. Vaak ligt het aantal bezoekers iets hoger dan Google Analytics, maar dat komt ook omdat crawlers/spiders meegeteld worden.

Ik denk dat het voor klanten ook fijner is om een ander model te nemen. Bandbreedte en opslag zegt ze vaak maar weinig en is ook lastig te vergelijken. Bij sommige hosters krijg je bijzonder veel GB/TB opslag en dataverkeer voor een paar euro per maand, dan hoeven ze volgens de specificaties nooit te upgraden. Echter presteert de website toch niet goed, ondanks de capaciteit die nog over is.

Sent from my GT-I9505 using webhostingtalk mobile app

Oorspronkelijk geplaatst door 24x7hosting

Webalizer is zeker geen goede, maar geeft wel een indicatie die voldoende is om het aantal bezoekers te schatten. Vaak ligt het aantal bezoekers iets hoger dan Google Analytics, maar dat komt ook omdat crawlers/spiders meegeteld worden.

Ik denk dat het voor klanten ook fijner is om een ander model te nemen. Bandbreedte en opslag zegt ze vaak maar weinig en is ook lastig te vergelijken. Bij sommige hosters krijg je bijzonder veel GB/TB opslag en dataverkeer voor een paar euro per maand, dan hoeven ze volgens de specificaties nooit te upgraden. Echter presteert de website toch niet goed, ondanks de capaciteit die nog over is.

Sent from my GT-I9505 using webhostingtalk mobile app

Maar aantal bezoekers en grootte van de database zegt natuurlijk ook niks over de prestatie van een website.

Ik denk dat je eerder van pageviews kunt uitgaan dan van bezoekers. Zo heb ik persoonlijk een profielenwebsite gehad. Deze had 'slechts' 10.000 bezoekers per dag, maar wel 1.500.000 pageviews... Ook dan kun je er met 'Fair use' natuurlijk onderuit komen, maar fijn is anders.

Overigens denk ik dat veel (potentiële) klanten juist wel van de duidelijkheid van een gespecificeerd pakket houden.

Je kan in de logs zetten hoe lang de server erover deed om de request te verwerken. Bij 100+ ms kan je dit in rekening brengen bijvoorbeeld.

Tenzij je Amazon heet en deels de vraag kunt bepalen, ben je nog steeds afhankelijk van de vraag van je klant. Als jullie klanten zitten te wachten op een andere prijs structuur, wie zijn wij om je dan daarbij te adviseren?

Er valt veel voor betalen naar gebruik te zeggen. Maar als je dat gaat invoeren moet je het simpel houden. Klanten hebben het soms al moeilijk genoeg met dataverkeer en schijfruimte. Laat staan dat ze plotseling moeten betalen omdat MySQL veel CPU heeft gebruikt in de afgelopen maand. Succes met het uitleggen daarvan aan de groenteboer op de hoek.

Oorspronkelijk geplaatst door getUP

Er valt veel voor betalen naar gebruik te zeggen. Maar als je dat gaat invoeren moet je het simpel houden. Klanten hebben het soms al moeilijk genoeg met dataverkeer en schijfruimte. Laat staan dat ze plotseling moeten betalen omdat MySQL veel CPU heeft gebruikt in de afgelopen maand. Succes met het uitleggen daarvan aan de groenteboer op de hoek.

Daarnaast zijn er klanten die al enige ervaring hebben met hosters en deze zijn enigszins gewend aan het concept van schijfruimte / dataverkeer. Daarnaast heb je velen die weinig verstand hebben van de techniek die erachter draait etcetera.

Een goede host geeft informatie hoe het concept met schijfruimte / dataverkeer werkt. Als iemand het van te voren niet snapt dan is het ook de eigen verantwoordelijkheid om deze informatie in te winnen bij de host, zodat men weet wat hij/zij kan verwachten.

Waarom vincen jullie pay per use zo 'n lastig model? Als je enige usp momenteel prijs is dan wordt je bestaansrecht al snel lastig.
Wat zijn de innovatie kosten ? Je moet je als provider momenteel afvragen wat wijzer is: investeren in hardware of software. Bereken je investeringskosten niet alleen op basis van capaciteit maar ook met het oog op de toekomst. Een software investering is net als een pensioen. Hij moet je op de lange termijn door de winter helpen.

Sent from my GT-P5110 using webhostingtalk mobile app

Je moet zelf even te raden gaan wat je wilt. Wil je heel groot worden dan moet je de prijzen heel laag houden. Maar de bestaande klanten willen ook de service blijven houden die ze nu op dit moment hebben. Beter mag altijd.

Dus is het het afwegen van wat je toekomstperspectief is. De echte hostinggiganten heb ik gemerkt zijn telefonisch niet bereikbaar. Dus een hostingprobleem leg dat maar eens uit. En zodra ze heel veel energie in jouw account moeten steken heb ik het gevoel dat ze je liever kwijt dan rijk zijn.

Dus even je beleid opnieuw gaan uitstippelen.

Het ligt denk ik ook aan het type klant. Zelf bedien ik meer de grotere/belangrijkere websites ipv een DirectAdmin server vol goedkope klanten. De communicatie is dan vaak met een directeur die niet precies weet wat hij nodig heeft, behalve dat het altijd moet draaien en alles volledig managed.

Als je klant een website designer, student of een particulier met een hobby website dan is dat heel anders.

Het verkopen van een dienst per bezoeker is naar mijn mening dus een stuk makkelijker uit te leggen.

Sent from my GT-I9505 using webhostingtalk mobile app

Een goede host geeft informatie hoe het concept met schijfruimte / dataverkeer werkt. Als iemand het van te voren niet snapt dan is het ook de eigen verantwoordelijkheid om deze informatie in te winnen bij de host, zodat men weet wat hij/zij kan verwachten.

Ben ik met je eens. Maar voor de ene klant is het wat makkelijker te bevatten dan voor de andere.

Oorspronkelijk geplaatst door mkd

Waarom vincen jullie pay per use zo 'n lastig model?

Eigenlijk gaat het helemaal niet om wat wij vinden. Wil de klant een model waarin hij betaald voor CPU cycles? Of per iop? Willen zij betalen voor iedere regel in een database? Het model van betalen naar gebruik is helemaal niet lastig. Het is wel een concept wat uitleg nodig heeft en niet voor iedere klant of leverancier geschikt is, afhankelijk van hoe je het concreet maakt natuurlijk. Betalen voor CPU cycles van een database gaat misschien weer wat te ver, maar misschien denken de klanten die je bedient er wel anders over. Dat weet ik niet, ik heb er geen onderzoek naar gedaan, dus daar kan ik eigenlijk weinig over zeggen.

Daarbij zijn investeren in hardware of in software zijn niet de enige twee keuzes die er zijn. Sterker nog, in mijn ogen zijn dat de randvoorwaarden. Niet onbelangrijk, maar niet waar dienstverlening om draait of waar je mee verder komt. Het is een hulpmiddel. Maar misschien kun je toelichten wat je hier precies mee bedoelt want ik kan zomaar iets anders er over nadenken.

Overigens ben ik het 100% met je eens dat als prijs een USP is voor je, je bestaansrecht er moeilijk wordt.

Je moet zelf even te raden gaan wat je wilt. Wil je heel groot worden dan moet je de prijzen heel laag houden.

Je zegt het precies verkeerd: wil je de prijzen heel laag houden moet je heel groot zijn. Pas dan heb je schaalvoordeel. Concurreren op prijs is het gevaarlijkste wat er maar is. Of kun jij je het permitteren om structureel verlies te maken tot dat je op een schaal zit om mee te doen met de grote jongens en te profiteren van je schaal? Dat denk ik niet. Als je denkt van wel dan zien we waarschijnlijk over een aantal maanden of een topic met een rits aan klachten of een topic waarin het bedrijf verkocht wordt. Het zal niet de eerste keer zijn.

Het verkopen van een dienst per bezoeker is naar mijn mening dus een stuk makkelijker uit te leggen.

Tenzij iedere website exact hetzelfde is en iedere bezoeker hetzelfde beweegt over een website kun je met die informatie echt helemaal niets en verkoop je gebakken lucht. Om een extreem voorbeeld te geven: ik heb 1000 bezoekers per dag. Toevallig komen al deze bezoekers op dezelfde minuut op mijn website. Mijn website verwerkt statististieken van alle CBR gegevens en biedt deze ter download aan in een ZIP file van 20GB. Alle bezoekers hebben een 100Mbit verbinding en zij verwachten een snelle response (zowel de initiële pagina, als de download). Maar deze klanten betalen wel voor deze dienst. Resultaat: klanten boos, directeur van de website boos. Maar als jij met hem aan tafel zit en je kunt het makkelijker verkopen omdat je per bezoeker afrekent, dan zit je met de verkeerde persoon aan tafel. Dan lever je misschien precies wat je hebt afgesproken, maar je levert een service van niets.

Daar tegenover staan SaaS platformen. Daarmee kan het wel, maar daar gaat het nu niet over.

Dan heb je nog altijd fair use, bij bijzondere websites/applicaties moet je afwijken van de standaard prijs en maatwerk leveren.

Daarnaast gaat het wederom niet om een budget klant op een enkele DirectAdmin server, maar juist om een managed website geschaald over meerdere servers met loadbalancers en caching. Dan is 1000 bezoekers met ieder 20GB op 100Mbit prima haalbaar, tegen de juiste prijs. Dat is ook prima uit te leggen, los van de prijs per bezoeker.

Als ik echter een webshop draai met een flink klantenbestand, en ze zetten een actie op Facebook, dan willen ze gewoon onbeperkt kunnen schalen en achteraf afrekenen per bezoeker. Op een enkele dedicated server/vps of DirectAdmin server met X dataverkeer en X GB opslag zou deze website elke keer crashen bij een actie, maar bij een groot opgezet shared platform met meerdere backend servers niet. Als er dan plots ruim 10.000 bezoekers komen enkel voor deze website, dan is dat goed te verwerken over meerdere servers en caching en waar nodig schakel je tijdelijk bij.

De klant met een webshop staat samen met andere klanten op dit grote platform, dus het is nog steeds een shared oplossing maar dan wel groter en managed aangepakt. Die profiteerd dus van de totale kracht bij piek momenten en betaald nog steeds per bezoeker per maand.

Deze oplossing is ook handig voor seizoen websites, zoals een vuurwerk webshop en een skivakantie webshop. Zij kunnen enorme druktes verwerken terwijl ze niet onnodig veel betalen buiten de seizoenen. Dit is simpelweg veel makkelijker en eerlijker te verkopen. Betalen en kracht hebben wanneer het nodig is en de kosten laag houden zodra het weer rustig is. Dat is een stuk fijner als klant dan wanneer je altijd maar hetzelfde moet betalen voor een dedicated server/vps of DirectAdmin pakket, waarbij je nog niet makkelijk kan schalen.

Enig nadeel is dat je servers op een normale dag slechts 10% benut worden en je servers standby hebt staan, je moet veel rekening houden met pieken en kan dus zeker niet oversellen. Echter is de prijs ook wel anders dan die van een DirectAdmin pakket.

De klanten die wij hebben draaien op dit platform zijn in ieder geval erg tevreden met de capaciteit. Een klant had laatst zo'n goedlopende Facebook actie en kon alle orders verwerken, terwijl de vorige hosting partij crashte bij een veel kleinere actie. Daarnaast hebben we beide lol van de actie, want ik breng meer in rekening en de klant heeft goed kunnen verdienen, win win dus.

Betalen per pageview kan ook, maar ook dat is weer een stuk ingewikkelder uit te leggen en varieert per website. Ik neem meestal een gemiddelde bij dit soort diensten. Sommige betalen dus iets te veel en andere iets te weinig, maar samen komt het uit op het bedrag wat nodig is om alles te kunnen draaien. En als het echt weer een bijzondere situatie is komt fair use en maatwerk weer naar voren.

Hebben anderen niet dit soort prijs-modellen? Of klanten die geen idee hebben wat dataverkeer is en hoeveel ze verbuiken?

Sent from my GT-I9505 using webhostingtalk mobile app