Playbooks · 5 min read
Instagram Support for SaaS Teams That Already Have Users
Every SaaS marketing team sets up Instagram expecting prospects. Then the product ships, a few thousand people sign up, and the inbox quietly changes hands. Open it now and it is mostly your own users: someone locked out, someone asking whether the invoice can have a GST number on it, someone reporting that a page is blank, someone who wants a feature and has decided Instagram is where you ask for features.
None of those people came from your content strategy. They came from your product, and they picked Instagram because it was open on their phone.
This post is about that inbox. If you are pre-launch and your DMs are strangers rather than users, the pre-product-market-fit version is a different argument and the advice genuinely inverts.
What is actually in there
Sort a fortnight of your own Instagram DMs into buckets and the shape is usually consistent: access problems, billing questions, "is it down", feature requests, and a minority of genuine prospects who have not read the pricing page.
The first two buckets are the ones worth automating, and only the parts of them that are already written down somewhere.
Your docs are the knowledge base, and they need editing first
Most SaaS teams already have the answers. They are in the help centre, in a Notion page, in a canned Intercom macro. The work is not writing them; it is noticing that they were written for a different medium.
A help article can be four hundred words with three screenshots. A DM answer cannot. The reply that works in an Instagram thread is two sentences and one link, and the two sentences have to make sense to someone reading them on a phone between other things.
- Take your five most common tickets. Not the five you think are most common — the five your support tool says are.
- Write each as a DM, not as an article. Two sentences. If it needs more, the answer is a link and the two sentences are what makes them click it.
- Cut anything that references your UI by exact label. Labels change, the reply does not, and a reply that names a button that no longer exists is worse than a vague one.
- Decide which ones must never be automated. Anything touching a specific account's data, a refund, or a security question. You cannot look up an account from here and neither can the model.
The things this cannot do, which matter more for SaaS than for anyone else
There is no account lookup. The automation cannot see whether the person messaging is on a trial, on a paid plan, or churned last March. There is no CRM sync and no one-click integration into your stack. Leads leave as a CSV export and somebody imports them somewhere by hand, or nobody does.
This has a practical consequence people miss: the automation cannot tell a paying customer from a stranger, so every automated reply has to read acceptably to both. "Thanks for your interest in our product" is a fine reply to a prospect and an insulting one to someone who has paid you for two years.
Escalation is the feature, not a fallback
Takeover stands the automation down the moment a human replies to a thread by hand. For a support inbox that is the primary workflow rather than an exception, and you should design around it.
The pattern that works: automate acknowledgement and the known answers, escalate everything else, and make escalation fast rather than graceful. A user who gets "let me get someone to look at this" within a minute and a real answer within the hour has had a good experience. A user who gets a smooth, confident, wrong answer instantly has had a bad one and will tell people.
The window problem, and why global users make it worse
A DM can only be sent within twenty-four hours of that person's last message, and only their next message restarts the clock. You cannot follow up on Thursday about Tuesday's bug.
Layer quiet hours on top of that and there is a real tension for any SaaS with users outside one timezone. Quiet hours exist so you do not send a chirpy automated message at 2am local; that is right for a consumer brand. For a product with users across several timezones, quiet hours set in your own timezone will silence exactly the hours when a chunk of your base is awake. Set them against your users' clock, or accept that some overnight questions wait until morning and say so in the reply that eventually goes out.
For a support inbox the measure of an automation is not how many replies it sent. It is how few of them a human had to apologise for afterwards.
Where to start, concretely
One automation, on the single question support answers most. Test on myself first, which runs the real pipeline and delivers to your own account. Live on one post. Then open the blocked activity list at the end of the day and read the reasons.
You are looking for one thing in particular: a large count of takeovers. That means your team is answering by hand faster than the automation, which means the automation is either too slow to matter or aimed at questions your team wanted to answer personally. Either way it should be narrower.
The broader case for automating support rather than growth is made in the always-on support post, and how grounding actually decides what gets sent is the piece to read before you point this at a knowledge base.
