Pushferry

Pushferry vs. een virtueel nummer: wat heb je écht nodig?

2026-09-06

Zodra een bedrijf besluit dat "iedereen zijn eigen mobiele nummer geven aan klanten" niet meer werkt, komt vroeg of laat de naam Voys, Dubline of EigenNummer voorbij. Het zijn gevestigde partijen in een Nederlandse markt die groot en volwassen is: één zakelijk nummer, een cloud-telefooncentrale erachter, en een team dat via een app of vaste toestellen opneemt alsof ze op kantoor zitten. Voor bedrijven die veel bellen, is dat precies het juiste gereedschap. De vraag die dit artikel wil beantwoorden is eerlijker en specifieker: wat als bellen niet het probleem is, en sms wel?

Wat een virtueel nummer daadwerkelijk oplost

Een aanbieder als Voys of Dubline verkoopt in de kern telefonie: één nummer dat naar meerdere toestellen of een app kan doorschakelen, een keuzemenu voor binnenkomende gesprekken, wachtrijen, voicemail die naar e-mail gaat, statistieken over gespreksduur en bereikbaarheid. Dat is precies waar EigenNummer met de aanduiding "voor teams" op mikt: meerdere mensen, één herkenbaar nummer, professionele afhandeling van telefoonverkeer. Beltify en Telsmart zitten in dezelfde hoek. Het is degelijke, doordachte techniek voor bedrijven waar de telefoon continu overgaat.

Sms is in dat pakket meestal een bijzaak. Sommige van deze partijen bieden er iets voor, maar het is niet waar het product om draait, en het is ook niet waar de prijs op gebaseerd is — je betaalt voor telefonie-infrastructuur, of je die belfunctionaliteit nu volledig gebruikt of niet.

Wat als je alleen sms-zichtbaarheid nodig hebt

Veel kleinere teams hebben helemaal geen wachtrij of keuzemenu nodig. Ze hebben één telefoon met een nummer dat al jaren in omloop is — bij leveranciers, op facturen, bij een enkele terugkerende klant — en het enige echte probleem is dat de sms'jes die daarop binnenkomen, blijven hangen bij wie toevallig dat ene toestel vasthoudt. Er wordt niet gebeld naar dat nummer, of nauwelijks. Er wordt ge-sms't: een bevestiging, een code, een korte vraag.

Voor precies dat scenario is een volledige telefooncentrale overkill. Je koopt in feite een compleet belsysteem om één specifiek sms-probleem op te lossen. Pushferry doet het omgekeerde: het raakt niet aan de telefonie, verandert niets aan hoe er gebeld wordt, en richt zich puur op het doorsturen van sms'jes en app-meldingen van dat bestaande toestel naar Slack, e-mail of een webhook. Je installeert de app op de telefoon die het nummer al draagt, en vanaf dat moment ziet het hele team wat er binnenkomt, zonder dat er iemand fysiek de telefoon hoeft door te geven.

De prijsvergelijking is niet toevallig

Cloud-telefonie wordt doorgaans per gebruiker of per lijn geprijsd — logisch, want je betaalt voor capaciteit om gesprekken te voeren. Pushferry rekent per aangesloten toestel, niet per bericht en niet per teamlid: gratis voor één telefoon met onbeperkt doorsturen, 9 dollar per maand voor Solo, 29 voor Team, 79 voor Business naarmate er meer toestellen bijkomen. Als je maar één telefoon hebt die sms-verkeer voor het hele team moet delen, zit je dus op een fractie van wat een volwaardig VoIP-abonnement voor hetzelfde team zou kosten — simpelweg omdat je geen belinfrastructuur meebetaalt die je niet gebruikt.

Wanneer je toch echt een virtueel nummer nodig hebt

Eerlijkheid hierover hoort bij een goede vergelijking: zodra klanten je moeten kunnen bellen, zodra je een keuzemenu, wachtrij of meerdere gelijktijdige gesprekken nodig hebt, is Pushferry niet het antwoord. Dan koop je bewust telefonie, en zijn Voys, Dubline of EigenNummer de juiste keuze — dat is hun vak, en ze doen het goed. Pushferry vervangt geen telefooncentrale en doet ook geen moeite om dat te doen.

De vraag die het waard is om jezelf te stellen, is dus niet "welke van de twee is beter", maar welk deel van het probleem daadwerkelijk pijn doet. Gaat het om gesprekken die ergens moeten landen, of om sms'jes die op één toestel blijven liggen terwijl het hele team ze nodig heeft? Het antwoord op die vraag bepaalt welk gereedschap logisch is — en voor een verrassend groot deel van de kleinere teams blijkt het tweede scenario het echte probleem te zijn.