Not every user should get the same notification flow. A new user needs a different experience than a power user. A free user should get different messages than a paying customer. Before SuprSend we could not do this without asking engineering to add conditions in the code for each case.

The workflow builder has branching built in. I set conditions based on user properties or event data and the flow splits accordingly. For our onboarding sequence new users get a welcome flow with helpful tips while returning users get a shorter reminder. Free users see upgrade nudges at the right moment while paid users get feature updates instead.

Setting up these branches is straightforward. I pick the condition, define the paths and each path can have its own channels, templates and timing. The visual builder makes it easy to see all the branches at a glance and understand what each type of user will experience.

This level of personalization used to require engineering work for every new condition. Now I manage it all from the dashboard and I can add or change conditions whenever I want. It has made our notifications feel more relevant to each user instead of one-size-fits-all. Review collected by and hosted on G2.com.

Being able to test each branch separately with a preview user would make it easier to verify flows before pushing them live. Review collected by and hosted on G2.com.

The way SuprSend works is that our backend fires an event and SuprSend takes care of everything else. Which channels to send on, what template to use, whether to batch or delay, what the user's preferences are. All of that is configured outside our code.

This event-driven approach keeps our notification logic minimal. We just need to send the right event with the right data and SuprSend does the rest. If product wants to change the email template or add a push notification to an existing flow they do it in the dashboard. Our code does not change at all.

We started with a few event types and have been adding more as we build new features. Each time it takes a few minutes to set up a new workflow for the event in the dashboard. The API accepts the event and the workflow handles the logic. It is clean and predictable.

For developers who want to keep their backend simple and not clutter it with notification logic this approach works well. Our notification code is basically a few API calls that fire events. Everything else is managed outside the codebase. Review collected by and hosted on G2.com.

A way to validate event payloads against expected schemas before they trigger workflows would be a nice safety feature. Review collected by and hosted on G2.com.

I run marketing at a small company and we do not have a dedicated product team. Before SuprSend I had to ask our one developer every time I wanted to change an email notification or set up a new message flow. It slowed things down and I felt bad constantly asking for help on something that should be simple.

Now I do it myself. I log into the dashboard, open the template editor, make my changes and push them live. For new notification flows I use the workflow builder. It is visual and I can see the steps in order. I do not need to understand code to use it. When we launched a new feature last month I had the announcement notification set up and sent within an hour.

The learning curve was not steep. I figured out the basics in a day and have been comfortable using it since. For a marketing person who wants to move fast without creating work for others this has been a good experience. Review collected by and hosted on G2.com.

A few ready-made email layout templates in the editor would save time when starting from scratch. Review collected by and hosted on G2.com.

The support experience has been consistently good. We communicate through Slack and whenever we have a question someone gets back to us fairly quickly. What sets it apart from other tools is that the people responding actually understand the technical context. We do not have to explain our architecture or repeat ourselves. They get it and give us specific answers.

During our initial integration they helped us plan how to structure our workflows and templates for our use case. It was not just answering questions but actually thinking through the best approach with us. That kind of support is rare. Even after the initial setup we have continued to get good responses whenever something comes up. There was one time we had a question about an edge case in our workflow logic and the team looked into it, confirmed the behavior, and suggested how to handle it. All within the same day.

For a small team that does not have a large engineering department to fall back on having reliable support makes a big difference. It gives us confidence that we are not going to get stuck with no help. Review collected by and hosted on G2.com.

A community forum or shared space where teams can share tips and learn from each other would be a good addition. Review collected by and hosted on G2.com.

In my role I often get questions from customers about notifications they did or did not receive. Before SuprSend answering those questions meant asking engineering to dig through logs and that could take hours or sometimes a full day. Now I open the SuprSend dashboard, search by user, and see everything. What was sent, when it was sent, which channel it went through and whether it was delivered.

The logs are organized in a way that makes sense even if you are not a developer. I can see the status of each notification at every step. If something failed I can see where it failed. This lets me respond to customers quickly with accurate information.

I also use the dashboard to review notification templates before they go live. The preview feature shows how things will look to the user which helps me catch anything that might confuse a customer. For someone in a customer facing role having this kind of visibility without depending on the dev team has made a real difference in how fast I can help people. Review collected by and hosted on G2.com.

Being able to bookmark or save frequent log searches would be convenient for users like me who look up the same types of things regularly. Review collected by and hosted on G2.com.

We needed a notification inbox that works on both our web app and our React Native mobile app. Building that ourselves with real-time syncing, read state management and cross-device consistency would have been a big project. The SuprSend inbox component handled it. I set it up on web first and then added it to our mobile app using their React Native SDK. Both use the same backend so the state stays in sync. If a user reads a notification on mobile it shows as read on web too.

The theming options are flexible enough that I could match our design system on both platforms. The real-time delivery works smoothly and new notifications appear without any delay. I also like that they offer a headless option for teams that want full control over the UI. We did not need it but it is good to know it is there if our design requirements change later. The SDK coverage across frameworks is broad which means it works for most tech stacks without workarounds. Review collected by and hosted on G2.com.

A few more animation presets for notification toasts on mobile would save some custom styling work. Review collected by and hosted on G2.com.

I manage our notification flows and the workflow builder is where I spend most of my time. It is visual so I can see the full flow from trigger to delivery. I can add delays, set conditions, choose which channels to use and set up branching logic. All of this without touching code.

We use it for onboarding emails, activity alerts, reminders and scheduled summaries. Each one has a different flow and I set them all up from the dashboard. When I want to try something different like adding a delay before a follow-up or switching the channel order I just update the workflow and it goes live. No tickets, no deployments.

The version history on workflows is useful too. I can see what changed and when which helps when multiple people on the team are making updates. If something is not working as expected I can compare with the previous version and figure out what happened.

What I appreciate is that it does not try to be more than it needs to be. It is not overloaded with options that make it confusing. It covers the use cases we need and does them well Review collected by and hosted on G2.com.

Being able to clone a workflow and use it as a starting point for a new one would save some time. Review collected by and hosted on G2.com.

My team was spending a decent chunk of every sprint dealing with notification stuff. Fixing delivery issues, updating templates in code, handling provider API changes. Nobody enjoyed that work. After moving to SuprSend that is all on their end now.

The fallback routing works as expected. We had a situation where our email provider had issues and things just routed through the backup. We only found out when we checked the logs later. The support team also uses the logs to look up notification issues on their own now instead of coming to engineering every time. Review collected by and hosted on G2.com.

Some SDK error messages could be a bit clearer. We worked through it with their support but better messages would save some back and forth. Review collected by and hosted on G2.com.

One of the main reasons we chose SuprSend was the observability. Our previous system was a black box. When a notification did not arrive we had no easy way to figure out where it broke. Now every notification has a step-by-step trace from the API call through workflow execution to the provider delivery response. Engineering can debug issues quickly and our support team can look up notification status for specific users without asking engineering.

The logs are searchable by user which is important when you are dealing with customer complaints about missing notifications. Instead of opening a ticket and waiting for someone to investigate the support team checks it themselves and responds right away.

We also pipe notification events to our data warehouse using the webhook integration. Our analytics team uses that data to track delivery rates and engagement across different notification types. It gives us a level of insight into our notification performance that we never had before and it has helped us make better decisions about what to send and when. Review collected by and hosted on G2.com.

Setting up custom alerts for delivery failures directly in the dashboard would be a nice feature. We built our own alerting on top of the webhook data.

Setting up custom alerts for delivery failures directly in the dashboard would be a nice feature. We built our own alerting on top of the webhook data. Review collected by and hosted on G2.com.

We serve users in multiple countries so our notifications need to go out in different languages. Before SuprSend we had separate template files for each language stored in the codebase. Updating a single notification meant changing files in multiple places and hoping nothing got out of sync. It was messy and error prone.

Now all our templates live in SuprSend and the multi-language support is built into the editor. I can switch between languages within the same template and see how each version looks. When I need to update the copy for a notification I do it for all languages in one session. The version control means if something goes wrong I can roll back without asking engineering. I also use the preview feature to check how templates render across email, push and in-app before pushing anything live. It catches formatting issues that would have gone unnoticed before.

The whole experience of managing notification content has become much more organized and I do not need to depend on anyone else to make changes. Review collected by and hosted on G2.com.

An option to flag incomplete translations within the editor would help keep track of what still needs to be done across languages. Review collected by and hosted on G2.com.