Automation contacts are the one soft quota in this product: the code has no way to refuse them. The automation keeps replying and whatever goes past the ceiling is billed at month end, one contact at a time. That ceiling only exists on the entry tier of each profile, and above it the number of contacts is not capped at all.
The billing model this category inherited
Almost every automated messaging tool charges by contact, by subscriber, or by "active contact", which is usually the same thing under a different name. From the inside the logic is obvious: every conversation costs something, so every conversation pays. From the outside it produces an awkward effect, which is that the bill goes up in exactly the month the automation works.
What that model causes is easy to recognise. Somebody switches an automation off halfway through the month because they are about to go over the plan. Somebody picks a more obscure keyword so that fewer people trigger it. Somebody deletes old contacts from a list to drop back under the next tier. All three are work spent administering a price, and none of them has anything to do with talking to people better.
The worst case never shows up on a screen. A post that does better than usual brings more comments, and under a per contact model the good day is also the expensive day. That is where our decision starts: if this exists so that a conversation can happen, it cannot be the thing that decides the conversation will not happen.
It is worth saying what we are not claiming, because the sentence sounds like a pricing trick. Volume is not free and somebody pays for it. What changes is where the cut is placed. A model that blocks moves the problem to the worst possible moment, when there is already a person waiting for an answer. A model that bills moves it to a line on next month's invoice, which is somewhere you can argue about it calmly and nobody is left hanging.
Five quotas, and only one that never blocks
A workspace has exactly five limits. Four of them are hard ceilings and the fifth is not, and the difference is not one of degree: the first four know how to say no and the fifth has no such branch written anywhere.
| Quota | What it counts | What happens at the limit |
|---|---|---|
| Members | People inside the workspace | Nobody else can be invited |
| Storage | Uploaded files | No new file lands until space is freed |
| Social accounts | Connected profiles | No further account can be connected |
| Ad accounts | Connected advertising accounts | No further account can be connected |
| Automation contacts | People an automation writes to | Nothing: sending continues and is billed later |
That asymmetry is deliberate, and it shows in who carries the consequence. Not being able to invite a sixth teammate is your inconvenience: you deal with it when you want to and nobody else finds out. An automation that stops replying is the inconvenience of a stranger who typed a word into a comment and got nothing back. You cannot deal with that one later, because they have already gone. How each limit fits into the rest of the product is covered in the seats and quotas guide.
Why the code cannot say no
The product's quota check takes a key and answers whether there is room left. For automation contacts it returns "go ahead" before it reads anything at all: it does not look up the plan, it does not look up usage, and it has no path to any other answer. This is not a generous tolerance configured somewhere. The branch that refuses does not exist.
What does exist is a meter, and it is worth knowing exactly what it counts, because that is what gets billed. One person is added for every automation run whose first outbound message actually went out. Somebody who was asked whether they follow you and never answered already counts, because the message asking them went out. Somebody two different automations write to during the month counts twice, because that is two conversations opened and not one.
And the number you watch during the month is literally the number that gets charged. The invoice is composed by reading the same sum over the closed month, not an adjusted version and not a parallel count kept by the billing system. It is a small decision that avoids the most expensive conversation a paid product can have, the one where you explain why the screen said one thing and the invoice says another.
A contact is not a send. An automation that asks whether somebody follows you, waits for the reply and then sends the link has written several messages to the same person and is still one contact, because what gets counted is the conversation opened rather than each message leaving it. It is the unit that penalises careful writing least, which was the point.
Where a contact ceiling still exists
There is one place where the ceiling is real, and saying so matters more than the flattering half: the entry tier of each profile includes a capped number of contacts. The tiers above it include no cap, and that is not a high number, it is the absence of a number. Which tier is the entry one for your case, and what it includes, lives on the pricing page, which reads the live catalogue. That is why no figure is written here.
The rest of the shape does not depend on the plan. You pay per workspace and not per seat, so adding somebody to the team does not move the bill. Prices include VAT, the Spanish value added tax, there is no minimum term and there is no charge per post. The only thing that can grow beyond what you contracted is these contacts, and it grows as one more line on the following month's invoice rather than as a cut off. Where the rest of that structure came from is told in how we set our pricing.
Everything in this article happens in one place in GoFeed.
Try it freeWhat the decision costs us
It is not free and we are not going to write it up as though it were. The first part of the cost is obvious: when a month spikes, we pay for the volume before we invoice it, and we recover it afterwards or not at all if there is no live subscription behind it by then. Each of those cases leaves a row written down with its reason, even when no money moved, because an unbilled month that left no trace is a month nobody can find later.
The second part is a defect we would rather write down than hide. The plan is read as it stands on billing day, not as it stood during the month being billed. A workspace that moved tier on the 20th is invoiced for the whole month on the tier it ends up on, up or down. The correct fix is to keep plan history, and building one for an operation that runs once a month would create a second source of truth about which plan a workspace was on. Between a known, bounded error and two versions of the same answer, we took the error, and we left it written where the code lives.
The third is that billing after the fact only works if the meter is visible while it runs. It sits on the workspace subscription screen next to the current month's usage. A model that does not block is only honest if nobody meets the number for the first time on invoice day.
What to watch instead of the contact counter
The contact count is a cost metric, not a result metric, and treating it as though it measured something good is the fastest way to make bad decisions. Three readings do say something about whether the automation is doing the job it was set up for.
- How many replied. A conversation starts when the other person answers, not when the first message goes out. The gap between those two numbers is what tells you whether the message is well written.
- What the follow gate did. It is not a platform lookup: the automation asks and reads the answer. How many people answer that question says a lot about whether you are asking it too early.
- What happened after the link. The short link that goes out is ours and it is measured, so the journey does not disappear inside a private message.
The automation runs on Instagram and Facebook, with comments, Instagram story replies and direct messages as triggers. How each piece is set up is on the Auto DM page, and the comparison with the tool that defined this category and its billing model is in GoFeed versus ManyChat.