Use Slinger

You start for free at app.slinger.to. You land straight in the dashboard.

On the Organisation page you set your name, profile photo/logo and business address.

On the Addresses page you create the locations that serve as destinations, before creating a widget.

On the Widgets page you create a new widget. In the Settings tab you then set the cover photo (1300 x 650 pixels), optionally a video header, a default address, and the language settings.

When creating it, you choose what the widget is for: an open event or location (for example a festival or concert), accessible to anyone who visits the widget, or a closed group (for example your colleagues for commuting or your sports team), visible only to invited members.

Yes, alongside the cover photo you also set the widget’s colours, so it matches your own branding.

Yes, in the Settings tab you switch payments on or off. When it’s on, passengers can pay directly via Stripe when booking a ride.

Yes, automatically sending the feedback email after a ride is also a setting you can switch on or off per widget.

Yes, you set the maximum number of seats per car yourself.

Yes, you set a maximum suggested price per kilometre that drivers are allowed to ask. This also matters for insurance purposes.

Yes, in the Settings tab you switch the waiting list on or off. If no ride is available, visitors can join the waiting list and are automatically notified as soon as a spot opens up.

Yes, you set whether distances are shown in kilometres or miles, and whether times appear in 24-hour or 12-hour format.

Slinger supports 10 languages: EN, NL, FR, DE, DA, ES, IT, CS, HU and SK. In the Settings tab, under Language settings, you switch on which languages are active per widget. Visitors automatically get the language that suits them; you can also fix it to a single language at installation.

Yes, in the Integrations tab (under “More”) you’ll find connections with Atleta, Cvent, Paylogic, Stager, Tracx, Utick and Weeztix.

Yes. Other connections are possible on request, and we offer a public API for your own integrations, documented at app.slinger.to/docs/api.

For events, yes: besides cars, the widget also supports buses and minibuses up to 90 seats.

In the Installation tab you can choose from three methods: Widget (paste the script tag directly before the closing </body> tag), Widget via GTM (via Google Tag Manager), or In your app (embedded in your own native app). With the script tag you can add options: position (left/right), whether the widget is open by default (separately for desktop and mobile), the size (small/medium), and the language (automatic, or fixed to a specific language).

A closed group is private and ongoing, for example your colleagues for commuting or your sports team: only invited members see the group and the rides within it. This is unlike an open event or location, which anyone visiting the widget can access.

Yes, your group’s branding also shows up within the Slinger app itself, not just on the widget on your own website.

Via bulk import or individual invitations on the Colleagues page. Members can also invite each other from within the app.

A closed group is really its own private space within the Slinger app. Members see who’s in the group via the colleagues tab, plan recurring rides via the calendar tab instead of setting them up every day, and manage group rides in their own rides tab.

Yes, you can set it so that only people with an email address from a specific domain can access the group. They can then sign in immediately, without separate approval.

Within your widget, in the Promote tab, you’ll find the mailing tool to reach members directly.

On the Media page you’ll find onboarding guides (separate ones for commuting and events), complete Campaign Kits per industry (“Share Your Ride” for Business, Music and Sports), and standalone photos and videos.

On the Statistics page you get a complete overview: number of rides, matches, drivers and passengers, kilometres saved and CO₂ emissions. There’s also a map showing where rides started and ended. If you have multiple widgets, you can also zoom in per widget via the Statistics tab within that widget.

A driver is a user who offers a ride with at least one available seat; the driver counts once the ride has been finalised. A passenger requests a seat with a driver; that request sits as requested until the driver confirms it, only then is it a confirmed passenger. A match happens when a driver confirms a passenger: one confirmed passenger equals one match. If a driver has three confirmed passengers, that counts as three matches. A draft, requested, refused, or passenger-cancelled request doesn’t count, and neither does a ride that was confirmed but later cancelled.

The waiting list holds users who wanted a ride but couldn’t find a suitable one. If someone later finds a ride (status “ride found”), they stay counted on the waiting list and also count as a match.

Per event, in the Events tab within your widget, you see the pickup locations participants entered.

We calculate CO₂ savings as shared kilometres × number of passengers × an emissions factor of 0.196 kg CO₂ per kilometre, set in consultation with KNVB and Climate Neutral Group. We count the actual number of passengers per ride, so 1, 2 or 3, not a fixed average.

After every completed ride, we automatically send the driver and passenger an email, or a message in the app, asking them to rate their experience from 1 to 5 stars and optionally leave a comment.

On the Feedback page in the dashboard you’ll see all incoming ratings and comments, enabled by default.

You manage that on the Admin team page. There you invite team members who get access to the dashboard itself: managing widgets, viewing statistics, gathering content. Only invite people you trust here, as admins get access to sensitive information.

You log in with your work email address, verified through a one-time code of 6 digits that is valid for 30 minutes. Access comes through an invitation from your organization admin, or by registering yourself on your organization’s whitelisted email domain. In both cases, access is only granted after the code has been entered. So it’s not just the domain that’s trusted, it’s actually verified that you can access that mailbox.

Not by default, no. Slinger is a standalone application by default, without any connection to your organization’s internal systems, and it doesn’t use SSO. If you do want that, it’s possible through our public API. That’s custom work, not standard functionality.

Data is encrypted at rest and in transit, with connections running over TLS. Access is restricted through authorization and is logged.

With DigitalOcean, in Amsterdam. All processing and storage takes place within the EU/EEA.

Besides hosting with DigitalOcean, payments run through Stripe. Any changes to these parties are communicated in advance.

Access can always be revoked immediately, by your organization admin or by Slinger. Right now this is still a manual action: there’s no automatic link with your HR system that triggers this when someone leaves. We’re happy to help set up a fixed process for this if needed.

Yes. Slinger has a Data Protection Officer, works according to privacy by design, and gives users the standard GDPR rights: access, correction, erasure, restriction, objection, and withdrawal of consent.

Account data is kept for as long as your account is active, and for another 6 months to 2 years afterwards depending on the type of data. Financial records are kept for 7 years due to statutory retention requirements.

Without undue delay, including the nature of the incident, which data was affected (if known), the possible consequences, and the measures taken or proposed. Slinger fully cooperates with any reporting obligations your organization has towards regulators or affected individuals.

Yes, as a standard annex to our business terms. Ask your sales contact for it.

Yes. Business customers may have an audit carried out annually, or when there are concrete indications of non-compliance, to check that Slinger is meeting its commitments.

Slinger uses profiling to personalize the service, but no automated decision-making with legal effect is applied. Decisions that affect users always involve human review.

In principle not from Slinger’s side, since we are the data controller for the core functionality. The final assessment of whether a DPIA is needed sits with your own organization or privacy officer.