Getting help

Email [email protected]. One address covers everything: account problems, bugs, reporting another user, billing questions (short answer there: the platform never charges anyone), or anything the help pages left unanswered. To get a useful reply on the first exchange, include your account email, what you did, what happened, and a screenshot if the problem is visible.

For reporting people or content specifically, you often do not need email at all. The three-dot menus in the app let you report a profile, a review, or a conversation on the spot, and every report is reviewed by the team. Use whichever route is easier; email is the right one when you want to explain context or attach screenshots.

A few notes on what support is and is not:

• Support helps with the platform. Accounts, bookings, notifications, reports, data requests.
• Disagreements about a service itself are between you and the other party first: talk it through in chat, leave an honest review, block if needed. Report to support when behavior breaks the rules.
• Privacy and data requests (access, correction, deletion, export) can go to [email protected] or through the in-app tools in Settings.
• EU consumers can additionally use the European ODR platform for disputes.

Feature ideas are welcome at the same address, marked as a suggestion. Every one is read.

Include 5 things when you write to [email protected]: the email address on your account, what you were trying to do, what actually happened, a screenshot if anything visible went wrong, and the booking ID if your question concerns a booking. With those five, the team can usually start investigating without a round of follow-up questions.

Why each one matters:

1. Your account email. Support needs to find your account, and that works by the email you registered with, even if you are writing from a different mailbox. Mention it explicitly.
2. What you were trying to do. "Book a cleaning for Saturday" tells more than "it doesn't work". The goal points to the right place to look.
3. What actually happened. The error message, the blank screen, the button that did nothing. Exact wording of any error is gold.
4. Screenshots. One picture of the screen at the moment things went wrong saves several emails of description.
5. The booking ID. Every booking's detail page shows its ID, and you can copy it from there. It takes support straight to the exact booking instead of guessing among several.

Not every point applies to every question; a quick "how do I change my photo" needs none of this. But for anything broken, confusing, or booking-related, the five items above turn a back-and-forth into a single exchange.

Email [email protected] with the steps you took and a screenshot. A bug report is actionable when someone else can reproduce the problem from your description alone, so the core of a good report is 3 parts: what you did, what you expected, and what happened instead.

Before writing, try the 30-second fixes: refresh the page, check your connection, try another browser. If the problem survives those, it is worth reporting.

What makes a report the team can act on:

• Steps, in order. "Opened my bookings, tapped the Tuesday session, tapped reschedule, picked 18:00" beats "rescheduling is broken". Numbered steps are ideal.
• Expected versus actual. One sentence each. "Expected the new time to show; instead the page went blank."
• A screenshot of the moment. Especially any error message, with its exact wording.
• Where it happened. The page you were on, and your device and browser if you know them.
• Your account email and the booking ID, when the bug involves your account or a specific booking. The ID is on the booking's detail page, copyable.

Honest expectations: you may not hear about every fix individually, and some bugs take longer than others to track down. But a report that lets the team see what you saw is the single most useful thing a user can send, and reproducible reports are the ones that get fixed first.

Send feature ideas to [email protected], the same address as everything else, and mark the message as a suggestion. Every single one is read. Being honest up front: not everything gets built. Surrounders is deliberately kept simple, and some requests will not fit, but suggestions from real users are taken seriously.

The most useful suggestions describe the problem, not just the feature. "I keep missing sessions because I plan my week on Sunday" gives the team something to design around; "add a weekly digest email" is one possible answer to it, and maybe not the best one. If you can, include:

• what you were trying to do when you felt the gap
• what you did instead, or what you gave up on
• how often it comes up for you

You can see the flip side of this process in the product itself. Some things are honest deliberate no's for now, like SMS notifications or automatic calendar sync, and the help pages say so plainly rather than pretending. Your suggestion might change one of those calls, or confirm one, and both outcomes are useful.

There is no public voting board or roadmap page today, so email is the one channel, and you will not necessarily get a reply about each idea. But if a suggestion is simple, clearly needed, and keeps the product easy to use, it has a real chance.