4 ms·

Disclaimer: I don't know the emails. I am immensely curious how you're achieving better delivery rates - I'm browsing through the site now trying to understand

Disclaimer: I don't know the emails. I am immensely curious how you're achieving better delivery rates - I'm browsing through the site now trying to understand this. I say this because at the end of the day, I thought any failures reflected poorly on the provider (SendGrid/etc) which puts the provider and the customer at a sort of war. > The business model I’m experimenting with is to offer all of these features for free to developers and small teams, because I know what a pain it can be to choose a good email API. I plan to monetize this service by charging bigger volume users. These plans scare me, fwiw. I appreciate trying to offer an affordable service to small teams where money is tight, but to small businesses like mine, our needs are often too big for the small tiers but too small to get value out of the next bigger plans. Many online services are expensive for us, despite us having revenue. Our margins our thin, I guess. This isn't a critique, I'm just trying to I guess advocate for a pricing model that fairly distributes the pricing load. Since we _(my company)_ always seem to get caught in the middle. Appreciate your work here, and I hope I find better understanding to eventually use the product!

igammarays 8y ago
It's not as adversarial as it seems. I should clarify, we achieve better deliverability through a combination of 3 techniques: 1. Making it easier to properly segment different kinds of emails (this is the #1 tip you'll find on all authoritative sources about email performance, including GMail's official guidelines for bulk senders) 2. Allowing you to dynamically adjust FROM's and sender IP's to isolate domain/reputation issues. 3. Catching provider failures, and retrying (Smart Failover). Only #3 reflects badly on the provider, "putting them at war" as you say. But the majority of our deliverability benefits actually come from the first 2 techniques, which is not really fighting with the provider, just using better tools on top of them. And thanks for the feedback about pricing. To be honest, my current pricing is a shot in the dark. We're going to have to figure out a better model as we go. Do you have any specific suggestions? Perhaps tying pricing to number of contacts/users instead of sheer volume?
- notheguyouthink 8y ago
  > Do you have any specific suggestions? Perhaps tying pricing to number of contacts/users instead of sheer volume? No specific suggestions, unfortunately. In our experience, I at least preferred when a service was $X/unit for all tiers.. that is to say, we could either afford to use the service or not. I love those services, it's clear and on paper. So to your comment, I actually like sheer volume. I'm paying for units of your service, and I like that. However the services I complained about above, were not $X/unit, it was $X/unit until Y units and then $Z/unit. A non-linear approach to payment. They also can feel more expensive, as the paying users prop up the free users. Though this may purely speculation. Sometimes this meant better bulk rates, where it got cheaper the more you spent. Other times it got worse, where we were seen as a bigger business because our needs were greater, and so we effectively pay more for less. Technically you usually get more features when you pay more, but in unit services like email, messages, w/e, we weren't upgrading because we wanted more features, we were upgrading because we wanted more units. So the pricing per unit got worse. I'm not advocating you change anything to be clear, you do what's best for your company - obviously. My comment was simply giving our side of the story on payment, and how non-linear models often put us in weird positions. Also, our story is probably atypical.
  - igammarays 8y ago
    That makes sense. I'm leaning towards segmenting my plans in a hybrid way that restricts advanced features to higher plans, but charges a fixed $X/unit for all tiers. That way you can pick a plan based on the features you need, while still being able to easily calculate whether $X/unit makes sense for your margin. Like you said, if you upgrade a plan, you rightfully expect more features. The reason we can't do a flat $X/unit alone is because we are not an email API, but rather we see ourselves as a booster-pack for email APIs. We don't sell emails, we sell email delivery optimization tools. Yet still, the volume of emails that flow through our infrastructure really matters. Plus, some of our features, like an Elasticsearch integration, are really expensive for us to support, so it makes sense that we should restrict those features to higher tier customers. Thanks again, super helpful comments.

igammarays 8y ago

It's not as adversarial as it seems. I should clarify, we achieve better deliverability through a combination of 3 techniques: 1. Making it easier to properly segment different kinds of emails (this is the #1 tip you'll find on all authoritative sources about email performance, including GMail's official guidelines for bulk senders) 2. Allowing you to dynamically adjust FROM's and sender IP's to isolate domain/reputation issues. 3. Catching provider failures, and retrying (Smart Failover). Only #3 reflects badly on the provider, "putting them at war" as you say. But the majority of our deliverability benefits actually come from the first 2 techniques, which is not really fighting with the provider, just using better tools on top of them. And thanks for the feedback about pricing. To be honest, my current pricing is a shot in the dark. We're going to have to figure out a better model as we go. Do you have any specific suggestions? Perhaps tying pricing to number of contacts/users instead of sheer volume?

notheguyouthink 8y ago
> Do you have any specific suggestions? Perhaps tying pricing to number of contacts/users instead of sheer volume? No specific suggestions, unfortunately. In our experience, I at least preferred when a service was $X/unit for all tiers.. that is to say, we could either afford to use the service or not. I love those services, it's clear and on paper. So to your comment, I actually like sheer volume. I'm paying for units of your service, and I like that. However the services I complained about above, were not $X/unit, it was $X/unit until Y units and then $Z/unit. A non-linear approach to payment. They also can feel more expensive, as the paying users prop up the free users. Though this may purely speculation. Sometimes this meant better bulk rates, where it got cheaper the more you spent. Other times it got worse, where we were seen as a bigger business because our needs were greater, and so we effectively pay more for less. Technically you usually get more features when you pay more, but in unit services like email, messages, w/e, we weren't upgrading because we wanted more features, we were upgrading because we wanted more units. So the pricing per unit got worse. I'm not advocating you change anything to be clear, you do what's best for your company - obviously. My comment was simply giving our side of the story on payment, and how non-linear models often put us in weird positions. Also, our story is probably atypical.
- igammarays 8y ago
  That makes sense. I'm leaning towards segmenting my plans in a hybrid way that restricts advanced features to higher plans, but charges a fixed $X/unit for all tiers. That way you can pick a plan based on the features you need, while still being able to easily calculate whether $X/unit makes sense for your margin. Like you said, if you upgrade a plan, you rightfully expect more features. The reason we can't do a flat $X/unit alone is because we are not an email API, but rather we see ourselves as a booster-pack for email APIs. We don't sell emails, we sell email delivery optimization tools. Yet still, the volume of emails that flow through our infrastructure really matters. Plus, some of our features, like an Elasticsearch integration, are really expensive for us to support, so it makes sense that we should restrict those features to higher tier customers. Thanks again, super helpful comments.