Most messages to a busy Instagram account repeat themselves: sizes, delivery, opening hours, whether something is in stock. Each one deserves an answer and few of them deserve the owner’s evening. That makes automation tempting, and it is also where a small business can do itself lasting harm, in its own voice.
We ran an agent on our own account before building one for a client. The rules below come from that run, and every figure in them carries a footnote pointing to the system’s own log.
Where DM automation goes wrong
The damaging cases are seldom a system that breaks. They are a system that works: it replies fast and in a confident tone, about something it had no business answering.
- An invented figure. Ask a general-purpose model what delivery costs and it produces a believable number. Your business never set it, yet it now sits in a screenshot under your name.
- A refund handled by software. Money questions carry emotion and legal weight. A reply that admits fault, or quotes a policy slightly wrong, turns a complaint into a dispute and hands the customer the transcript.
- A bot that talks over the owner. Without a clean override, the owner replies and the automation replies again straight after. The customer sees a business arguing with itself.
- A bot that hides what it is. Customers accept an assistant that says it is one. Finding out later that the “person” they thanked was software costs trust, and platform policy asks more and more for disclosure.
Rule 1: the agent knows your answers and nothing else
Everything the agent may say comes from one document, the answer list. It holds the questions your customers send, answered the way you answer them, usually between twenty and fifty entries. Our own list is in lowercase because the account owner writes that way, and the agent took on the voice along with the facts.
The edge of the list matters more than what is on it. A question with no entry gets no answer from the agent; it goes to a person. During our run a customer asked about shipping abroad, which the list did not cover. The agent said a person would confirm, flagged the gap, and the owner wrote the missing answer into the list. Real gaps, filled in your own words, are how the list should grow.
Writing the list in one evening
Open your sent messages from the past month and copy each answer you have typed more than twice. Keep your own phrasing, greeting and all. Give each question one answer with the facts a customer needs: the delivery charge and the cut-off time, not the reasoning behind them.
Then write two shorter lists. One names what always goes to a person: money, complaints, cancellations, account access and whatever is sensitive in your trade. The other names what the agent must never discuss. A clinic rules out clinical advice; a restaurant rules out allergen promises. These two lists carry your professional liability, so they are yours to write.
Rule 2: money and complaints are stopped in code
Telling a model not to discuss refunds is a request, and a persistent customer or an odd turn of phrase can talk a model past a request. The safer design puts the rule where the model has no reach: in the code that sends the reply.
When a message is classed as money, a complaint or account access, the sending step transmits only a fixed acknowledgement, whatever the model drafted. The customer is told a person will reply in the same thread. The owner receives an email with the customer’s words, the exact acknowledgement already sent and the details gathered so far, so nothing the customer was told gets contradicted later. The inbox agent case study shows this happening on a live refund request.
Rule 3: your own reply switches the agent off in that thread
An override that needs a dashboard fails on a Saturday night. What does work is something the owner already does without thinking about it: replying. When you answer a thread yourself, the agent sees a human reply and stays silent in that conversation from then on.
It also means the agent adds no new inbox. Customers keep writing in Instagram, and the owner keeps working from Instagram and email. A product that asks your staff to learn another console adds to their work instead of taking it away.
Rule 4: every message handled once, and logged
This rule was paid for with our own mistake. During testing, a file permission failed without any error, and the worker re-read the same messages on every cycle: each decision made twice and duplicate handover emails. In front of real customers, one person would have received the same greeting again and again.
Platforms deliver messages “at least once”, so the same event can arrive twice by design. The automation therefore has to be exactly-once by construction: before any work starts, the event is claimed in a record that can only be written once. Every outcome, whether answered, handed over, refused or skipped, becomes a row in the log. The log is where the owner’s reports get their figures, and it is how a claim such as a 61-second first reply1 can be checked.
Rule 5: messages it cannot read go to you
Point an agent at a real inbox and much of it turns out not to be text. When we checked the latest nine threads on our own account, only three contained words; the rest were pictures or reshared posts2. An agent that works from an answer list has nothing to stand on there. Praising the picture or guessing the intent teaches customers that the account replies without reading.
Ours hands those threads to the owner, and its report lists them as threads for a person. The share will differ from one business to the next; the rule does not.
Platform rules you take on
| Rule | What it means for you |
|---|---|
| The reply window | A business may reply within 24 hours of the customer’s last message. The handover email shows how much of that window is left. |
| Official connection only | You authorise the agent on the platform’s own consent screen and can withdraw it at any time. Unofficial tools put the account itself at risk. |
Week one: treat it like a new hire on probation
- Days 1 and 2
Drafts only
Real messages come in and the agent writes a reply to each, but nothing is sent. Each evening you read the drafts: does it sound like you, and which handovers would one more list entry prevent? Change the list, not the agent.
- Days 3 to 5
Live on routine questions
Known questions are answered within about a minute. Everything on your always-a-person list still reaches your inbox with the full context. Read the line showing what the agent already said before you reply.
- Day 7
Read the summary
The report has a section for questions it could not answer. That section is the system working: add those answers in your words and it shrinks the following week.
By the end of the week your own inbox and your own figures show whether it pays its way. A week on your real messages tells you more than any demo, ours included.
Seven questions to ask whoever builds it, us included
- Where do the answers come from? The one good answer: from content you approved. If the reply is about what the system learned in training, expect made-up facts under your name.
- What does it do with a refund request? Listen for code that refuses to send, rather than a bot that has been told not to.
- What happens to a photo with no text? Anything other than “it comes to you” deserves a request to see the reply it sends instead.
- How do I take over? The right answer: you reply and it stops. If the answer involves a dashboard, picture a busy weekend.
- Is it disclosed as automated? Only yes will do, for platform policy and for trust.
- Can one message be answered twice? Notice whether the question is understood. Repeat delivery is how platforms work; handling each message once is the builder’s job.
- Can I read its replies before it goes live? A builder who trusts the work lets it draft against your actual messages first, and lets those drafts make the case.
The last question sums up the approach. A new member of staff does not handle customers alone on day one; someone checks their replies for the first week. Software earns the same probation.
Weighing the cost against the time
The cost has a build part and a monthly part. The build turns your answer list into a working agent and checks it against questions your customers sent before. The monthly part covers two things: keeping the answers current and reading the reports, and the use of the underlying AI service. We run that usage on accounts you own, so it shows on your own bill rather than inside ours. Both parts are set out with a fixed price in the written proposal.
To see whether it pays, count last week’s messages and set aside the ones that needed you. Every message left over costs about two minutes to read and answer, so add those minutes up. Set that against the one outcome it must never produce: an invented answer about money.
What our own agent measured
1. Worker log, first live day. 2. Live inbox read with skip counters. 3. Enforced in the send step; the model cannot override it. The full sequence, with the two bugs we caught, is in the case study.
Measured once, on our own account. A record of that run, not a promise for yours.