More than once, clients have exported their subscribers and compiled their own lists (in a way that cannot be done using segments), and imported that new list again to send a campaign, only to find out that their monthly fee had doubled (from $250 to $500 a month), even though there were no new addresses in the list.
That's a result of two things: the fact that a single address counts more than once when it's being used in multiple lists, and the fact that there's no way to limit the monthly billing amount. Since clients have no direct way to see in which range they sit, we only notice when they've gone over the limit when it's too late and the creditcard has already been charged.
Since this has cost us hundreds of dollars so far, we're thinking of switching everything back to the 'normal' billing system, even though monthly billing would be a lot more interesting if there was some sort of way to prevent those situations.
That made me wonder about two things:
- What's the idea behind counting an email address twice if it's in two lists?
- Is there a specific reason why there's no way of putting a limit on monthly billing? Is this yet to come?
Thanks for your answer!
Thanks for your feedback, I can definitely see how that is not ideal in your situation.
We looked at how to measure the list totals, and in the end it was much less complicated from a technical and a customer understanding perspective to keep things really simple, and add up each list.
That way you and your clients can very easily see and check the totals just by scanning the table of lists, and there aren't any complications with trying to work out which unique addresses are in which list.
Putting a limit on monthly billing isn't something we're planning, just because it hasn't been requested much and we'd rather give people the most straightforward option of paying more if they want to send to or import more.
However there are definitely ways we could make that a much clearer process, and make it clearer when taking an action will mean an increased monthly cost, so thanks for your feedback.
We'll discuss this internally as something to look at for a future release. In the meantime, perhaps you can explain to your clients that they are much better off not importing duplicates into different lists, and instead just updating their main list.
It makes reporting much nicer because you have just one subscriber history for each address as well as reducing the monthly cost. We do try to encourage that as the best way to use lists, when you can. We do realise it is not always feasible.
I too have a client that uploads a new list for each campaign because their communication segmentation depends on more data than can be efficiently maintained in their CM list(s). So they assemble a custom import most of the time.
It just doesn't make sense why if the email address is the "unique identifier" within each account, it can't be used to calculate the size of the account. Every time a list is imported, CM is comparing those addresses against a suppression list, so why can't CM simply maintain a DB that is appended every time a list is added? The system is already set up to prevent duplicates, so you'd immediately have a "master list" of unique addresses started.
It gets a little more complicated when you consider the possibility of unsubscribes from one list but not another, but not much. This could be addressed by tracking what lists each address belongs to. When an address doesn't have any lists assigned to it in the master DB, it's considered completely unsubscribed, deleted or suppressed. Then you'd have an accurate list if unique addresses for the account. This way clients can continue to enjoy the benefits of maintaining different lists perhaps to track a wider variety of unique custom fields or perhaps more importantly, maintain different autoresponders for different lists, etc.
Looking forward to hearing CM's response regarding why it would be so hard to count unique subscribers in each account.
Thanks for the additional feedback. There are obviously some ways that a unique count would be better, but as I mentioned before it is not as simple as it sounds either technically or for usability of the system in showing how that is determined.
So we made the decision to go for the clearest approach, though that does make it less useful for some people. We do want to encourage customers generally to keep the number of lists down because that makes the reporting more valuable to.
I know some customers just can't do that, but many more will get the benefits of reduced cost and better reporting by moving in that direction.
In the case of your client, do they need to keep the old lists around? If they can remove the list before importing the replacement one, their total size will not grow into the next tier, so the costs will not increase.
The way this seems to work is really a large flaw in the system. I don't really know how you can have a charging system based on the number of people you are communicating with, and then count a recipient more than once because you might want to manage seperate lists.
How do you justify the increased cost (which can multiply very quickly) without any increase in the service being provided? The way the costs are advertised are quite misleading.
We're just charging based on the list total - that makes it far easier for most customers because they can look at their lists, add them up and work out what price that is.
In some cases, people want to have duplication, and yes, that does cost more, but we'd encourage everyone who can do so not to just import duplicates, but to work the way Campaign Monitor is designed for, using fewer lists and smarter segmenting.
That gives you a better experience because the reporting, subscriber history and list management are all better. We understand that might not work in every case.
I second the frustrations voiced here. We recently moved from a pay as you go plan to a monthly plan, because the client is sending out more and more emails and can't pay the high single campaign costs. I was shocked to see that my customer would be paying an additional $180 a month because they've created a separate, re-organized list that grouped many of their smaller lists together and pushed them over the 10k subscriber limit. I don't know why the control panel says "unique" subscribers because close to half of them are duplicates. This also makes it impossible for my client to use separate lists to organize subscribers unless they want to pay nearly double what they are currently paying.
This is going to lead to either:
a. An uncomfortable conversation between my client and I where I have to explain that they must do a considerable amount of work to consolidate these lists and can't use their subscriber lists to organize things the way they used to. Does anyone know of a tool that you can use to export and remove any duplicate email addresses?
b. The client using another email provider (and my company losing revenue), which they've already expressed interest in doing. Also makes me look bad because the client feels they are being price gouged.
Do you have plans to change this in the future?
A serious issue, that I became aware of yesterday.
This is how a normal user would expect your service to work:
1) Lists should ONLY be a function to organize your existing recipients into groups - like in an adress book.
2) Pricing should be based on number of subscribers (= unique email adresses).
Since november we're now paying 195 usd (10,001 - 25,000) for a client who have far less email adresses registered. There is no way we can get this money back from the client, and it is simply not possible for us to extend the newsletter service to new client's.
We pay on behalf of all our clients, and must be able to control costs.
Looking forward to some feedback.
Hi individual, welcome to the forums and thanks for explaining your scenario - I'm really sorry for any misunderstanding here. We are quite explicit about how monthly billing works in our documentation on monthly pricing - our model is similar to that of other ESPs. Nonetheless, we're open to suggestions as to how we can improve our pricing, so we'll certainly consider this for the future.
In the interim, you may want to encourage a review of your client's lists, as effective use of segments and custom fields can often reduce the need to create multiple lists.
I'm sorry again for the confusion - hopefully we can still be of value to you and your clients in the future.
Just some quick feedback/update regarding our scenario: The client ditched our newsletter service last month and chose another provider, after getting our instructions on using segments.
We're really sorry to hear that, individual - we're still keen to look into how we can make our pricing more competitive and offer better value-for-money to our customers. If there's anything we can do to help out, we'd be keen to look into it.
The only other thing I'd like to add is that because CM is positioned for end users that want a clean, easy to use, relatively fool proof interface, they're also likely to be on the less sophisticated side... I know there are plenty of sophisticated CM users... but when I sell a white label CM account, the more sophisticated the client, the more likely they are to be more price savvy and want features that can only be found elsewhere. So when less sophisticated users are on the system, they're more likely to be using lists to segment subscribers instead of taking the time to set up segments within one list. This is especially true when a client is managing information in another system like a CRM, and they are exporting into CM for every campaign. To limit monthly pricing, they'd have to delete those lists all the time, which could also mean losing reporting detail.
Is it that hard to bill based on unique email addresses across multiple lists?
Hi BraceRosso, in so much as we appreciate that it may be easier to create multiple lists in some situations, we'd really like to encourage customers to use custom fields/segments to organize subscribers. As an alternative, there's always removing inactive lists, or PAYG pricing.
That said, we're keen to look into making monthly pricing more flexible, so I'll certainly add your vote for this and keep you posted if its an option we offer in the future. :D