Playbooks · 6 min read
Advanced Instagram Automation: Overlaps, Grounding, Activity

Everything here assumes you are past the interesting part. You have six or ten automations running, the free tier ran out months ago, and the problems you have now are not "how do I build one" problems. They are the problems of a system that mostly works and occasionally does something you cannot explain.
Four things account for nearly all of that: automations overlapping, negative keywords never revisited, grounding tuned wrong, and Activity treated as a log rather than as an instrument.
Overlapping automations, and which one wins
The first month you have one automation per post. By month four you have automations that were built for a post, plus a broad catch-all across all posts, plus one for story replies, and a comment can now match more than one of them.
The rule to internalise is that a single inbound event produces at most one automated reply. The others do not queue behind it; they are simply not the one that fired. That is deliberate — two replies to one comment reads as broken to the person receiving them — but it means an automation can look silently dead when it is actually just losing every race.
The fix is structural, not clever. Keep exactly one broad automation, scope everything else to specific posts under Advanced, and make the broad one the least specific reply you own — the one that is fine to send when nothing better matched. Then, once a quarter, open the list and turn off the ones built for a campaign that ended. Dead automations are not harmless; they are competing.
Negative keywords as a system, not a patch
Most accounts add negative keywords reactively: something embarrassing goes out, the word gets banned, everyone moves on. After a year you have thirty words and no idea which still earn their place.
Treat them as four categories instead, and audit them as four categories.
Protect the customer
not interested, cancel, refund, worst, scam, galat. A templated cheerful reply to any of these is the single worst thing your setup can do.Protect you
The third category is the one people miss: words that are correct but too early. price under a post about a delivery delay is not a pricing question. Scoping the pricing automation to the posts where pricing is the subject does more than any negative keyword can.
The fourth is words your audience actually types, which are frequently not the words on your button. If your caption says comment GUIDE and half your commenters type guide pls, send guide, and mujhe chahiye, your trigger set needs those. Matching ignores case and punctuation, so you are collecting phrasings rather than spellings. Choosing trigger words is a whole discipline and it is where most recoverable performance actually sits.
Grounding: what a generated reply is allowed to know
A templated reply says what you wrote. A generated reply is composed fresh, which is useful when the question has variations and dangerous when the model does not know something and produces it anyway.
Grounding is the constraint that a generated reply must be traceable to a source you supplied. Not the internet, not the model's general knowledge — your material. If the model cannot ground an answer, or is unsure, or is simply slow, your template goes out instead. That fallback is the feature; the mechanics are documented separately.
The advanced work here is source hygiene, and it is unglamorous:
- Delete stale sources before you add new ones. Last season's price list is worse than no price list, because it grounds confidently.
- Write sources as answers, not as brochures. A paragraph of marketing copy grounds badly. "Shipping to metros is 2-3 days, rest of India 4-6, free above two thousand" grounds well.
- Keep one source per subject. Two documents that disagree about the same fact produce a reply that picks one, and you will not be told which.
- Re-read the sources when you change the business. Almost every wrong generated reply we see traces back to a true document that stopped being true.
The review queue is a tuning surface
Replies the system is not confident enough to send land in a queue instead of going to the customer.

Most people work the queue as an inbox — approve, approve, edit, approve — and never notice that it is a report. Three patterns are worth acting on.
The same question keeps arriving. That is not a confidence problem, it is a missing template. Write the answer once as a template and it becomes free and unlimited, and it stops spending credits.
Everything from one automation queues. The sources for that subject are thin. Add material rather than lowering your standards.
The queue is empty and you are still surprised by replies. Then your confidence bar is set where it does not catch anything, and the queue is decorative.
A review queue you never disagree with is not a safety feature. It is a rubber stamp with a loading state.
Reading Activity as a diagnostic
Activity is the only screen that tells you what happened rather than what you configured. Filtered to blocked, it names the check that stopped each send.

The gate runs in order — kill_switch, connection, takeover, window, dedupe, cooldown, quiet_hours, rate_budget, credits, content_safety — and that order is the thing advanced readers under-use. You only ever see the first failure. A run that fails on window may also have failed dedupe and cooldown; you will never know, because the gate stopped at four.
So read Activity by shape rather than by row:
- A rising share of
takeovermeans you are answering by hand faster than the automation, and the automation should be narrower or off for that surface. dedupeclimbing sharply is usually Instagram redelivering events, which is normal, or two automations chasing the same commenters, which is not.cooldownandrate_budgettogether on one post is a viral post being correctly throttled. Leave it.connectionanywhere is an emergency and everything below it in the list is untested until you fix it.content_safetyis last, so a reply that fails there passed everything else. Those are the rows worth reading individually.
The habit that separates people who have run this well for a year from people who have merely run it for a year: read blocked before you read sent. Sent tells you the setup worked. Blocked tells you where it is about to stop working. When something genuinely breaks, the crisis sequence starts with the kill switch, not with a better template.


