Foothold

What happens when you install Foothold

You are considering handing a tool access to your paid Slack community. This page is the full picture of what that means — before you click install, not after. Every OAuth scope we request and why. What we read and what we don't. What stays on our servers and what passes through. What uninstall does.

Three principles behind the design:

  • Least privilege. We request the narrowest scopes that let the three-touch flow work. Nothing extra "in case we build it later."
  • Operator-owned. The data is yours. We store the minimum needed to run the flow, plus what you need to audit that it's running correctly.
  • Exit-friendly. Uninstall is one click. Full export ships within an hour. We delete on a published timeline.

1. The 30-second install

The workspace owner (or any admin with app-install permission) visits foothold.community, clicks “Connect your Slack,” and is redirected to Slack's standard OAuth consent screen. That page is rendered by Slack, not by us — it lists every scope we request, in Slack's own descriptions, and asks for an explicit Allow.

The admin sees three things on that screen: the workspace name, the app name (Foothold), and the full scope list. Clicking Allow redirects back to us; we store the workspace tokens in an encrypted column keyed to your workspace ID. Declining cancels the install cleanly — nothing is partially written, no orphaned row. There is no middle state.

After the redirect, Foothold shows the operator a one-screen config page: pick three to five goal-track options, write one welcome line, pick the intro channel, opt in or out of the optional admin-channel summary. Save, and the install is done. On average the whole flow takes the operator about thirty seconds plus however long they spend writing the welcome line.

2. The scopes we request, and why each one

When Foothold ships, these are the OAuth scopes that appear on the Slack consent screen. Each one is on the list because the three-touch flow cannot run without it — not because it might be useful later.

  • im:write Send direct messages. Used for the day-0 welcome DM and the day-3 goal-keyed nudge. This is the core of the product; without it Foothold cannot ship any message.
  • im:history Read direct-message threads the bot is part of. Used to detect whether a new member replied to the day-0 DM (reply → no day-3 nudge fires). We do not read DMs the bot is not a participant in — Slack's permission model makes that impossible with this scope.
  • users:read  +  users:read.email List workspace members and read names, profiles, join dates, and email addresses. Used to detect new joins (the trigger for day-0), to personalise the DM with the member's first name, and to send the day-7 scorecard email to the workspace owner. The email address read is the workspace owner's — that's the only email we send. We do not email new members.
  • channels:read  +  groups:read Read channel names and IDs. Used at install time to present you with a dropdown when picking the "introduce yourself" channel for the day-0 DM. We do not read channel contents — there is no channels:history scope on our list.
  • team:read Read workspace name and domain. Used for the scorecard email subject line (“Foothold · $WORKSPACE · week ending $DATE”) and the dashboard header. That's it.
  • chat:write Optional, off by default. If you opt in at install, Foothold can post a weekly summary to one channel of your choice (typically #foothold-log or #admin) so your team sees the scorecard. If you don't opt in, this scope is not used and no channel messages are sent. You can flip it off at any time in the settings page.

What is deliberately not on the list: channels:history, groups:history, mpim:history, search:read, admin.*, files:read, reactions:read. The bot cannot read messages in your community's channels, cannot search your workspace, cannot see administrator settings, cannot download files, and cannot read reactions. A Foothold install is read-only on channel contents and write-limited to direct messages plus (optionally) one admin channel.

3. The first week inside your workspace

Once the install completes, Foothold polls users.list once per hour looking for new joins. If you add the Slack Events API URL to your Slack app config (a post-install setting, not required for v1), the poll drops to an event-driven team_join webhook and the lag goes from up-to-an-hour to roughly instant.

When a new member is detected, we queue the day-0 DM to fire within six hours — the window is intentional. Firing within seconds reads as a bot pattern and depresses reply rates; firing within six hours reads as “a human saw I joined” and is where the target 50–70% reply-within-24h rate comes from. The DM goes from your own workspace handle, not a generic “foothold-bot” account — the reply rate on DMs from the workspace owner is roughly double the rate on DMs from a clearly-named bot account.

On day three, for members who have neither replied to the day-0 DM nor posted in the intro channel, Foothold fires a single goal-keyed nudge. Just one. If the member replies to the day-0, posts in channel, uses Slack's “stop messaging me” on the bot, or deactivates their account, the day-3 does not fire. There is no day-3-if-they-don't-reply-to-the-day-3 — we do not nag, ever.

On day seven, Foothold computes the scorecard for the week and emails it to the workspace owner. That email is the weekly cadence the playbook prescribes; nothing else lands in your inbox on a recurring schedule. You can see the rendered email here.

4. What Foothold reads, and what it doesn't

Reads

  • The member list of your workspace (once per hour, or event-driven if you wire up the Events API).
  • Direct-message replies sent to the bot from the members the bot DMed.
  • Channel names and IDs, at install time only.
  • Workspace name, member count, and billable-seat count — for the scorecard header.
  • Member first names and join dates — for DM personalisation and cohort assembly.

Does not read

  • Any message in any channel. The bot does not have channels:history.
  • Any DM conversation the bot is not part of.
  • Any file, attachment, image, or huddle transcript.
  • Admin settings, SSO configuration, or billing info.
  • Any other workspace in your Slack Enterprise Grid (the token is workspace-scoped).
  • Reactions, pinned messages, channel topic history.

If any of the “does not read” items later become a feature you want, we will request the scope explicitly in a future app-update consent and you'll get to Allow or Decline. No quiet scope expansion — every change requires a fresh consent screen on your side.

5. What Foothold stores, and what passes through

Per workspace, our database holds exactly this:

Stored

  • Encrypted OAuth access & refresh tokens (required to call Slack on your behalf).
  • One row per new member: Slack user ID, first name, join date, picked goal-track, and three flow-state flags (day-0 sent / day-3 sent / included in scorecard). No message bodies.
  • One row per DM we send: timestamp, recipient user ID, which of the three touches, delivery status (delivered / bounced / opted-out). No message bodies.
  • Your configured goal-track list, welcome line, and intro channel ID — the settings you set at install.
  • Workspace owner email address (for scorecard delivery).
  • Per-week scorecard snapshot: the four numbers, the three stalled names, the week-range. This is what makes the four-week trend line in the email possible.

Not stored

  • Bodies of the DMs Foothold sent.
  • Bodies of the DM replies Foothold received.
  • Any channel content, anywhere, ever.
  • Files, images, voice notes.
  • The Slack access token in plaintext — it is AES-256 encrypted at rest, decrypted only in memory when we call the Slack API.
  • Any data from workspaces that uninstalled more than 37 days ago (30-day restore buffer + 7-day deletion-propagation window).

Infrastructure: data lives in a single SQLite database on one VPS, encrypted at rest, daily off-site encrypted backups, 37-day backup retention. No third-party analytics pixels on operator dashboards. No Mixpanel, Segment, Amplitude, or similar. Product telemetry we do collect is aggregated server-side counts (total DMs sent this week, total workspaces active this week) — not per-workspace events.

6. What uninstall does

Two ways to uninstall: from your Slack workspace's app-management page (same pattern as any Slack app), or by emailing hello@foothold.community. Either triggers the same four-step flow:

  1. Within one minute: Foothold stops firing DMs to your workspace. Any queued day-0 or day-3 messages are cancelled, not paused.
  2. Within one hour: we email the workspace owner a full export — every flow that fired, every reply we logged, every weekly scorecard we sent. CSV plus JSON. The export is yours; it is not gated behind a final invoice.
  3. 30 days: your data sits in a restore window. Changed your mind, or uninstalled by mistake? One click and it continues from where you left off, no data loss.
  4. Day 31–37: row-level data is deleted from the live database and then propagated through the backup system. On day 37 we verify the final backup and the workspace is gone from every Foothold system.

Cross-reference: the full data-on-cancel policy, including the “is this gated behind the final invoice” question, is question 6 in the pricing FAQ.

7. Two things we haven't built and won't

Foothold does not have a “community analytics” feature. No network graph, no sentiment score, no top-contributor leaderboard, no engagement heatmap, no cohort-by-cohort dashboard. The four-number day-7 scorecard is the whole telemetry surface, deliberately. If you need those features, Common Room is a better tool — we'll say so directly rather than pretend to offer everything.

Foothold does not sell, share, aggregate, or syndicate your data. No “industry benchmarks” newsletter built from customer scorecards. No ad-targeting pixels on operator dashboards. No reselling of the member list to recruiter SaaS. Your numbers are your numbers. We earn revenue from the $49/$99/$199 plans — that is the entire business model, and it's what lets us make the two promises on this page (least privilege, data is yours) without flinching.

8. If you find a security issue

We publish a disclosure policy at /.well-known/security.txt (with a legacy copy at /security.txt) in the RFC 9116 format your security tooling already understands. Report channel: hello@foothold.community, or DM @bitinvestigator on X if email isn't an option.

The short version: 48-hour acknowledgement from a real human, 90-day coordinated disclosure window (extendable by mutual agreement), public credit on the site once the fix ships, and written safe-harbour for good-faith research. No bug bounty at this stage — we're pre-revenue and we'd rather be honest about that up front than hint at a reward pool that doesn't yet exist. If you'd like the full rules-of-engagement (scope, rate limits, what not to touch), read the file; it's about 4 KB of plain text.

If any scope, data-handling rule, or retention window on this page changes, we will email every workspace owner before the change ships. No quiet scope expansion, no surprise clause in a 12-page ToS update.

Have a question this page didn't answer? Email hello@foothold.community. We'll add your question to this page — named after you, if you give permission, anonymous otherwise.

Back to the main landing page · see the day-7 scorecard email · read the six-step playbook · pricing FAQ