Smart Auto-Reply: Beyond Simple Responses

"Auto-reply" makes people think of one canned line fired at every message. That was never our ambition. We wanted something that feels attended even at 2 a.m., and steps aside the moment a human should take over. This is how we think about it, and why the word "smart" in our docs means routing, not magic.

Layer one: the dialog tree

The tree handles the bulk of volume. Menu choices, FAQ answers, and catalog browsing all live here. It is deterministic, fast, and editable by non-engineers. Most support teams recover sixty percent of their time just by wiring this up, because the same five questions stop reaching inboxes entirely.

Layer two: the webhook brain

When the answer needs your data, we call your webhook. Order status, wallet balance, appointment times, anything dynamic. You return plain text and we deliver it. Your logic stays in your system; we stay out of your database. Returning null tells us to stay quiet, which is often the right move when we have nothing useful to say.

app.post("/wa-webhook", async (req, res) => {
  const order = await orders.find(req.body.text);
  res.json({ reply: order ? "Order " + order.id + " ships tomorrow" : null });
});

Layer three: the human handoff

A "talk to staff" node stops the bot and notifies your team. We keep the conversation in the same thread so the customer never repeats themselves. This handoff is the feature customers remember, because it proves a real person was always one tap away.

Groups are a different animal

In groups we only act on mentions and quotes, never on every line. A bot that replies to a group chat unprompted gets the group muted, and rightfully so. We default to silence unless called, which keeps the bot welcome instead of tolerated.

What good routing looks like

The pattern we recommend: tree for the top questions, one webhook for the one data lookup that matters, and a clear human handoff. That trio covers most small teams better than any single giant bot, and it is easy to reason about when something goes wrong.

The honest caveat

Smart routing is not free intelligence. If your webhook is slow or your tree is a maze, customers feel it. We recommend tight timeouts, a fallback message, and a weekly look at where conversations die. The system is only as smart as the paths you draw, and a confused path is worse than a slow human.

Metrics that actually matter

When a smart reply is live, we watch three numbers: how many conversations reach a human, how long the bot held before that handoff, and where in the tree people give up. The first tells you if the bot is trusted. The second tells you if it is fast. The third tells you which branch is broken. A healthy setup trends toward fewer handoffs, shorter holds, and fewer dead ends, and we treat any movement the other way as a bug to fix that week.

When the bot should stay quiet

Just as important as what to answer is when not to. If a webhook returns null, we say nothing, because a forced reply to an unknown question is how bots sound dumb in screenshots. We also throttle so one chatty customer cannot trigger twenty replies in a minute. Silence, used deliberately, reads as restraint rather than failure, and customers respect a bot that knows the edge of its knowledge.

What we ship first

Tree for the top questions, one webhook for the one data lookup that matters, and a clear human handoff. Start there, measure, and add intelligence only where the data proves it is needed.