TL;DR — recommendation for discussion
Our knowledge lives only in Slack messages — we have no docs or FAQs to load
into an off-the-shelf tool. That single fact points us toward building a small
bot (Option B) rather than buying one:
- Build small, on GCP (Option B). A lightweight bot reads our channels
directly (Slack's API works on the free plan, within the 90-day window),
captures resolved Q&A — e.g. a lead reacts ✅ to a good answer — into a
permanent store, and surfaces the closest past answer when a question repeats.
Pennies a month, and it's the only approach that actually uses the messages
we already have before the 90-day clock erases them.
- Buying first won't help us yet. The off-the-shelf tools (AnswerHub, etc.)
answer only from a knowledge base we hand-curate; none can read our existing
channel messages. With no docs to seed them, they'd start empty.
- The unavoidable cost is human effort, not software — someone has to own
keeping the knowledge current. No tool removes that.
Everything below is the detail behind this.
Problem / why now
Volunteers in our Slack tech-support channels answer a lot of the same
questions and have to constantly monitor threads. That's an ongoing,
unrewarded burden.
There's also a clock running: our free Slack plan only keeps messages for 90
days. Every good answer our volunteers write quietly disappears after three
months. So even before we talk about AI, there's value in simply capturing
those answers somewhere permanent.
This issue is a proposal to discuss at standup — not a finished design. Goal: pick
a direction.
Goal & non-goals
- Goal: reduce volunteer load by automatically suggesting (or drafting)
answers to common tech-support questions, using answers we've already given.
- Non-goal (for v1): fully autonomous posting with no human in the loop, or
replacing volunteers. We want to assist, not auto-pilot.
The common backbone (true for almost any version we build)
New question in Slack
│
▼
1. Look up similar past answers ← cheap, no AI needed
│
▼
2. (optional) Ask a small AI model to phrase a reply from those answers
│
▼
3. Bot drafts into a private "leads" channel → [Approve] / [Reject]
Two ideas do most of the work:
- Capture knowledge before Slack deletes it. A small listener saves resolved
Q&A pairs — e.g. when a lead reacts ✅ to a good answer — into permanent
storage (a simple database). This solves the 90-day problem regardless of
which option below we pick.
- Human-in-the-loop by default. The bot proposes a draft to leads for one
click to approve, rather than posting directly to members. This caps cost and
prevents the bot from confidently posting something wrong.
A couple of terms, since they show up below:
- Retrieval / search = finding the closest past answer. Cheap.
- LLM = the AI model that writes a fresh reply. The optional, paid part.
- Embeddings = turning text into numbers so "similar questions" can be found.
Very cheap, but not literally free.
Options (roughly even trade-offs)
| Option |
Build effort |
Deploy & maintain |
Monthly cost (ballpark) |
| A. Buy / no-code — an existing Slack AI app, or Slack's own built-in AI search |
Low |
Low — vendor hosts it |
$0 on free tiers, rising to roughly $10–30+/mo if it scales; some need a paid Slack plan |
| B. Light build — search only, no AI writing — capture knowledge + a bot that surfaces the closest past answer |
Medium |
Low–medium — runs on GCP, scales to zero when idle |
roughly $0–5/mo (GCP free tier; no AI tokens) |
| C. Full build — search + AI-drafted reply + human approval (the backbone above) |
Medium–high |
Medium |
roughly $0–10/mo (GCP free tier + a few cents of cheap-model tokens at our volume) |
Option A (buy). Fastest path, least to maintain. We trade money and some
control for not writing/operating code. Good for a cheap pilot to see if this is
even worth it.
What's actually on the market (June 2026 search):
- Slack's own AI — paid Slack plans only. Out for us (we're staying free).
- AnswerHub — best free-tier fit on paper. Has a real $0 plan that's
per-workspace, not per-user (unlimited FAQs, 3 knowledge-base files, 1
website), with flat paid tiers above ($62 / $110 a month — still not per-seat).
On the Slack Marketplace. But its knowledge base is hand-curated only —
confirmed from its own site, it answers from uploaded FAQs/files/websites and
cannot import or learn from our existing Slack messages. With no docs to
seed it, it starts empty. Its only "growing" mechanism is forwarding a new
unanswered question to an expert and saving that reply — useful going forward,
but it never mines the history we already have.
- Question Base — older write-ups mention a free tier, but its current pricing
starts at $1,000 for a 2-month trial, then about $6,000/yr per seat. Effectively
enterprise pricing. Out.
- Perfect Wiki — $9 per editor/month, 5-editor minimum, 3-year billing,
and Microsoft-Teams-first. Poor fit.
Why this matters for us specifically: every bought tool answers from a
knowledge base we curate (uploaded FAQs/docs) — none can read our existing
channel messages. Since our knowledge lives only in those messages, a bought
tool would start empty and need us to hand-write FAQs to seed it. A custom
bot can read the channels directly via Slack's API (works on the free plan,
limited to the 90-day window), which is exactly why building fits our situation
better than buying. Also note the free Slack plan caps us at 10 app
integrations total.
Option B (light build). No AI writing at all — it just finds and links the
most relevant answer we've already given. Surprisingly effective for FAQ-style
support, and essentially free to run on GCP (Cloud Run scales to zero, so an idle
bot costs nothing). Lowest risk of "the AI made something up."
Option C (full build). Adds a small AI model that phrases a real reply from
the past answers, with a lead approving before it posts. B is a strict subset of
C — we can ship B first and layer the AI on later only if plain search isn't
good enough. Cost stays in the pennies because we'd use a cheapest-tier model and
only call it when needed.
On model choice: the key is to use a cheap, fast model, not the flagship. The
top-end models (e.g. GPT-5.5 at about $5 in / $30 out per million tokens)
are overkill and pricey for this. The right tier is the fast/cheap class —
Gemini 3.5 Flash ("less than half the cost of other frontier models") or
GPT-5.4 mini/nano (about $0.20–0.75 input per million). At our volume that's
pennies a month. Exact pick is a later detail, not something to lock in now.
Trade-offs worth knowing before we commit
- The hard part isn't the AI — it's getting clean Q&A out of messy threads.
Real support threads wander ("nvm, fixed it"). The ✅-react-to-save approach
works but depends on volunteers tagging good answers.
- "Free" search still has a tiny cost (embeddings). Pennies, but not zero.
- Secrets & permissions: we'd manage Slack tokens and decide who can
approve drafts.
- Ownership: for a volunteer team, "who maintains this" matters more than the
bill. The upside: scale-to-zero means an unused bot costs next to nothing.
Suggested direction for discussion (not a mandate)
Because our knowledge lives only in messages (no docs to load into a bought tool):
- Build Option B small — a bot that reads the channels, captures resolved
Q&A before the 90-day deletion, and surfaces the closest past answer. This both
stops the knowledge bleed and starts deflecting repeat questions, for pennies a
month.
- Add Option C later (AI-phrased replies with lead approval) only if plain
search proves not good enough — it's a strict add-on to B, not a redo.
- Buying (Option A) stays a fallback, worth it only if we'd rather hand-write
FAQs than write code — but it can't leverage the messages we already have.
Open questions for standup
- Is there any budget, or must this stay essentially $0?
- Which channels? Just tech-support, or others?
- Auto-post vs. approve-first — comfort level?
- Who owns/maintains it?
- How fast does a response need to be (minutes? same-day?)?
TL;DR — recommendation for discussion
Our knowledge lives only in Slack messages — we have no docs or FAQs to load
into an off-the-shelf tool. That single fact points us toward building a small
bot (Option B) rather than buying one:
directly (Slack's API works on the free plan, within the 90-day window),
captures resolved Q&A — e.g. a lead reacts ✅ to a good answer — into a
permanent store, and surfaces the closest past answer when a question repeats.
Pennies a month, and it's the only approach that actually uses the messages
we already have before the 90-day clock erases them.
answer only from a knowledge base we hand-curate; none can read our existing
channel messages. With no docs to seed them, they'd start empty.
keeping the knowledge current. No tool removes that.
Everything below is the detail behind this.
Problem / why now
Volunteers in our Slack tech-support channels answer a lot of the same
questions and have to constantly monitor threads. That's an ongoing,
unrewarded burden.
There's also a clock running: our free Slack plan only keeps messages for 90
days. Every good answer our volunteers write quietly disappears after three
months. So even before we talk about AI, there's value in simply capturing
those answers somewhere permanent.
This issue is a proposal to discuss at standup — not a finished design. Goal: pick
a direction.
Goal & non-goals
answers to common tech-support questions, using answers we've already given.
replacing volunteers. We want to assist, not auto-pilot.
The common backbone (true for almost any version we build)
Two ideas do most of the work:
Q&A pairs — e.g. when a lead reacts ✅ to a good answer — into permanent
storage (a simple database). This solves the 90-day problem regardless of
which option below we pick.
click to approve, rather than posting directly to members. This caps cost and
prevents the bot from confidently posting something wrong.
A couple of terms, since they show up below:
Very cheap, but not literally free.
Options (roughly even trade-offs)
Option A (buy). Fastest path, least to maintain. We trade money and some
control for not writing/operating code. Good for a cheap pilot to see if this is
even worth it.
What's actually on the market (June 2026 search):
per-workspace, not per-user (unlimited FAQs, 3 knowledge-base files, 1
website), with flat paid tiers above ($62 / $110 a month — still not per-seat).
On the Slack Marketplace. But its knowledge base is hand-curated only —
confirmed from its own site, it answers from uploaded FAQs/files/websites and
cannot import or learn from our existing Slack messages. With no docs to
seed it, it starts empty. Its only "growing" mechanism is forwarding a new
unanswered question to an expert and saving that reply — useful going forward,
but it never mines the history we already have.
starts at $1,000 for a 2-month trial, then about $6,000/yr per seat. Effectively
enterprise pricing. Out.
and Microsoft-Teams-first. Poor fit.
Option B (light build). No AI writing at all — it just finds and links the
most relevant answer we've already given. Surprisingly effective for FAQ-style
support, and essentially free to run on GCP (Cloud Run scales to zero, so an idle
bot costs nothing). Lowest risk of "the AI made something up."
Option C (full build). Adds a small AI model that phrases a real reply from
the past answers, with a lead approving before it posts. B is a strict subset of
C — we can ship B first and layer the AI on later only if plain search isn't
good enough. Cost stays in the pennies because we'd use a cheapest-tier model and
only call it when needed.
Trade-offs worth knowing before we commit
Real support threads wander ("nvm, fixed it"). The ✅-react-to-save approach
works but depends on volunteers tagging good answers.
approve drafts.
bill. The upside: scale-to-zero means an unused bot costs next to nothing.
Suggested direction for discussion (not a mandate)
Because our knowledge lives only in messages (no docs to load into a bought tool):
Q&A before the 90-day deletion, and surfaces the closest past answer. This both
stops the knowledge bleed and starts deflecting repeat questions, for pennies a
month.
search proves not good enough — it's a strict add-on to B, not a redo.
FAQs than write code — but it can't leverage the messages we already have.
Open questions for standup