Kick Bot privacy policy

What we collect

Installation and workspace information

Slack supplies workspace names and IDs, installer and bot identifiers, granted permissions, and OAuth authorization tokens. We store installation records so Kick can authenticate requests and communicate with the correct Slack workspace.

Information submitted to Kick

We process and store standup answers, mood selections, blockers, kudos, virtual-coin explanations, and team-pick inputs and results. Records can include Slack member IDs, usernames, channel IDs and channel metadata, timestamps, and Slack message links. Please avoid submitting sensitive information that your team does not need.

Opt-in team rituals also store channel schedules, selected participants, question templates, check-in sessions and answers, blocker helpers and resolution status, fair-rotation history, and delivery jobs. Personal preferences include time zones, quiet hours, reminder choices, snooze times, and leave dates.

Team workspace tools store named workflow settings; action text, creators, assignees, due dates, status, and source references; check-in edit versions and late corrections; sprint goals, dates, links, and recaps; attributed retrospective topics, groups, and votes; planning-poker participants, estimates, rounds, and decisions; calendar exceptions; and configuration and delivery audit records. Retrospectives are not anonymous. Planning-poker estimates are hidden from other participants in the interface until reveal, but are stored by the service.

Message shortcuts receive the selected Slack message and its identifiers. Kick uses its text to prefill a confirmation form and stores only the text and workflow fields you confirm, plus a source message timestamp for an action. It does not copy attachments or fetch surrounding messages for these shortcuts. Cancelling the form does not create a workflow record; the incoming request is still processed transiently by the service.

Personal to-dos store your Slack workspace and member IDs, task text, due date, Open/Done status, edit version and completion timestamp. They are stored separately from channel actions. Polls store their question, choices, creator, workflow, status and closing time; ballots store the voter’s Slack ID and selected choice. Poll voting is not anonymous, although the interface shows aggregate results rather than a list of voters.

Slack API responses and technical information

Coordination tools store approval titles, details, requester and designated approver IDs, deadlines, decisions and timestamps; onboarding newcomers, buddies and assigned checklist steps; one-on-one participant IDs, dates, encrypted titles and encrypted agenda/follow-up text; leave dates, reasons and proposed cover IDs; handoff summaries and source/receiving workflows; and opt-in escalation thresholds. These records support the specific coordination activities you choose.

Optional issue-tracker connections

With a workspace administrator’s explicit consent, Kick receives GitHub, Jira or Linear access and refresh tokens and the organization/site, project/team/repository identifiers and names available to that connection. Tokens are encrypted before storage and scoped to the Slack workspace. Kick reads issue identifiers, titles, statuses, update timestamps and available transitions to preview an import or status change. On confirmed import, the title and status become a channel to-do; linked identifiers, last synchronized states and operation audit metadata are stored. Later sync changes only status in the direction the administrator confirms. There is no background sync or remote issue deletion.

Provider API responses may transiently contain additional fields, such as issue descriptions, repository metadata or user information. Those fields are not copied into Kick records or used as product features. Private to-dos, one-on-one records, approval details, leave reasons and Slack message history are never sent to these integrations. The provider receives authorized API requests and selected issue status changes under its own privacy policy.

Provider authorization uses random, single-use links and state records bound to a secure, HTTP-only browser cookie. Links, cookies and states expire after ten minutes. They are security controls, not advertising trackers. Do not share a connection link with another person.

Kick receives channel membership and member-profile information to display and select participants. These responses may include fields, such as profile images, that Kick does not use as a product feature. Kick does not request the users:read.email permission or maintain a member email directory.

Slack requests and diagnostic logs can contain command text, submitted fields, identifiers, timestamps, and error information. Our hosting services also process ordinary request information, such as IP addresses, browser details, requested URLs, and response status, to deliver and protect the website and app.

Installation cookies

After installation, Kick sets a secure, HTTP-only confirmation cookie that expires after ten minutes. It records an expiry time and whether the installation was organization-wide; it contains no Slack access token, workspace name, or member identifier and is not used for advertising. Slack’s OAuth flow also uses a temporary security cookie to validate the installation request.

Optional website analytics

Only after you allow analytics, we load Google Analytics 4 on public pages at kick.bozmoz.com to understand website visits and clicks on Add to Slack. Google receives a browser-generated identifier, public page information, event timestamps, browser/device information and network information needed to process the request. We do not deliberately send Slack identifiers, messages, team records, form contents, URL query strings or fragments, or referring URLs. Installation, authorization, confirmation and error pages are excluded. An installation-button click is not evidence of a completed installation.

Google processes this website analytics data separately from Kick’s Neon app database and may process it outside your country. Our integration disables Google signals and advertising personalization and denies advertising consent. See Google’s privacy policy. Analytics is optional and does not affect the Slack app.

The analytics cookies (_ga and _ga_6EC7YHKCG9) are configured to expire after 90 days without automatic renewal. We remember your allow/reject choice in local browser storage for 180 days. Use Cookie preferences at the bottom of any public page to withdraw permission; this stops future tracking and removes this integration’s cookies from this domain. Browser Global Privacy Control keeps analytics off. Rejecting does not delete analytics already received by Google. The Google Analytics property is configured to retain user-level and event-level data for two months, without resetting retention on new activity. This does not limit Google’s standard aggregated reports. Contact us to request access, an export or deletion. For an analytics request, tell us the approximate visit date and, if available, your analytics cookie identifier; do not send Slack credentials.

Support requests

If you contact us, we receive your email address and the information you include. This is separate from Slack member information. Do not send passwords, Slack tokens, or other credentials in support email.

How we use data

We use data to operate Kick’s commands and forms, associate updates with their workspace and channel, post results in Slack, generate requested reports, maintain installations, troubleshoot errors, prevent abuse, and respond to support or data requests.

When enabled for a channel, team-ritual data supports scheduled check-ins, reminders, summaries, blocker follow-ups, recognition roundups, and aggregate team insights. App Home checks channel membership before displaying that channel’s workflow records.

Collaboration data supports assignment and completion of work, sprint recaps, facilitated retrospectives, estimates and decisions, calendar exceptions, and delivery troubleshooting. Search operates on retained Kick records within the selected workflow, not on Slack’s message archive. Late corrections, sprint recaps, and shortcut kudos may be posted to the relevant Slack channel after confirmation.

Submitted updates and recognition are shared with the relevant Slack conversation. Other people who can access that conversation may be able to read them. Kick does not sell Slack data, use it for advertising, or send it to a generative-AI service for processing or model training.

Where data is stored and who receives it

Approval and leave details are visible in Kick only to the requester and designated approver. Team coverage exposes only approved names, dates and proposed cover teammates. One-on-one titles and notes are visible only to their two participants; the viewing participant must still have channel access. Being a workflow owner or workspace admin does not confer access in the interface. This is application-level privacy, not end-to-end encryption: the service decrypts records to display them, and authorized operators may access them for support or verified data requests.

Onboarding checklists are channel-visible. Handoff summaries are visible to the source channel and named recipient; acceptance makes them visible to the receiving channel. Issue imports are channel-visible only after explicit confirmation. Administrators must ensure channel members may see a selected project’s issue titles. Escalation summaries contain counts of aging channel work, never private records. Private coordination details are excluded from shared reports and search.

Only the owner can view or change their personal to-dos through Kick’s interface; they are never included in channel lists, shared search or reports. This is application-level privacy, not end-to-end encryption: the service and authorized operator can access stored records as needed to operate the service or handle verified data requests. Channel actions, polls and aggregate reports are visible to current members of the relevant channel. Reports combine retained records for the selected workflow and date range without exposing hidden planning-poker estimates. Poll creation, poll closing and explicit report sharing queue notices in Slack; closing a report preview sends nothing.

Kick runs on Vercel, which processes incoming website and Slack requests and operational logs. App installation records and workflow data are stored in Postgres hosted by Neon. Slack installation credentials are additionally encrypted by the app before storage. Slack receives the API requests and messages needed to deliver the integration. Support correspondence is handled through our Gmail support mailbox.

Cloudflare Workers is used for the external scheduling component when activated. It calls a fixed Kick endpoint using a scheduler secret and receives aggregate processing counts, not Slack credentials or submitted team content. Scheduler operational logs may include request timing and failure status.

The original records in our previous datastore were deleted after the database migration was verified. Encrypted migration snapshots remain as recovery copies and are not used to serve normal app workflows. These snapshots have no automatic deletion schedule yet; verified data-deletion requests also cover these recovery copies.

These service providers process data to host, store, secure, and operate the service. Data may be processed outside your country according to their infrastructure and service arrangements. We do not promise a particular data-residency region.

Access to app data is limited to the operator and services needed to run and support Kick. We may disclose information when required by law. The app uses HTTPS for data in transit and service credentials for access to storage; no online system can guarantee absolute security.

How Kick uses Slack permissions

Commands permissions enable slash commands. Channel and member permissions identify the conversation and eligible participants. Messaging permissions let Kick post workflow results. Public-channel history access supports workflow context and message-related operations. The Slack installation screen shows the permissions you are being asked to grant.

The direct-message permission allows Kick to open a private conversation for an opted-in check-in reminder or assigned-blocker follow-up. It does not grant access to your existing private-message history. Delivery requires the permission to be granted to your installation and activated by the service. You can disable private reminders in your preferences. Message shortcuts use the existing commands permission; Kick does not request permission to search your Slack message history.

Kick is an independent third-party integration. Slack controls its own platform, workspace retention settings, and handling of messages stored within Slack.

How long data is kept

Team planning

Team planning stores self-declared weekly task limits; decision titles, text, rationale, owners, review dates and status; objective titles, owners, dates and status; and key-result baselines, current values, targets and units. These records help channel members plan work and track outcomes. They are visible to current channel members, not used to infer individual productivity scores, and expire after the workflow’s 7-, 30-, or 90-day retention from creation. Editing does not extend retention; key results expire no later than their objective. Shortening workflow retention shortens existing planning records. Expired records are hidden immediately and removed in bounded scheduler batches.

Only the individual can set their capacity in Kick. Creators, assigned owners and workflow owners can edit decisions, objectives and results. Planning audit entries record the actor and operation, not copies of the decision text or metric values. Shared reports include aggregate counts of decisions, objectives and key results, not capacity limits or individual metric values. Saving a planning record does not post a Slack message.

Other workflow and service records

Approvals, leave requests, onboarding, one-on-ones, checklist items, handoffs and escalation settings expire under the workflow’s 7-, 30-, or 90-day retention from creation. Children expire no later than their parent; handoffs use the shorter of the two workflows’ retention periods. Editing or completing a record does not extend retention. Expired records are immediately inaccessible and physically removed in bounded scheduler batches.

Issue-tracker connections and their encrypted tokens expire after 90 days from authorization, even if tokens are refreshed. Disconnect deletes Kick’s credentials and associated mappings and links immediately, but does not delete imported channel tasks or external issues and does not revoke the provider-side grant; you can revoke that separately in the provider’s app settings. Mappings, links and sync audit records follow workflow retention and cannot outlive their connection. Authorization states expire after ten minutes and are cleaned by the scheduler. Uninstalling Slack does not automatically revoke a separate provider grant; disconnect or request deletion as well.

Personal to-dos expire 30 days after creation, whether open or complete. Editing does not extend that lifetime. Owners can also delete an individual task immediately from its edit form. Polls and ballots follow their workflow’s 7-, 30-, or 90-day retention, with ballots expiring no later than the poll. Reports are calculated when requested; a shared report is saved as a delivery job for the workflow’s retention period and a message in Slack after delivery. Expired records are hidden immediately and physically removed in bounded scheduler batches.

Core command history, cached channel/member information, and installation records currently have no automatic age-based deletion schedule. They remain stored until removed through a verified deletion request or service maintenance. This includes records created by the original version of Kick.

New team-ritual sessions, responses, blockers, recognition copies, rotation state, and delivery jobs expire after the channel’s selected 7, 30, or 90 days. Expired records are hidden from workflow views and deleted in bounded batches by the scheduler; physical deletion may be delayed during downtime or a backlog. Setup previews expire after 15 minutes. Channel settings and personal preferences remain until removed by a verified deletion request or service maintenance. This retention does not shorten core command history or Slack’s own message retention.

Actions, corrections, sprints and recaps, retrospective topics and votes, poker sessions and estimates, calendar exceptions, and audit entries follow their workflow’s selected 7-, 30-, or 90-day retention. Child records may expire earlier when their parent expires. Shortening the setting also shortens existing workflow records; editing does not extend the lifetime of an existing action or response. Named workflow settings remain until removed through a verified deletion request or service maintenance. Calendar exceptions cannot be scheduled beyond the current retention window.

Tokens are used while an installation is authorized. Uninstalling the app revokes its Slack access, but does not automatically erase all stored workflow data, installation archives, or logs. Request deletion separately using the contact details below.

Operational logs are retained according to the hosting provider’s configured log-retention period. Support correspondence is kept until the request is resolved and as needed to document its handling; you can request its deletion. Contact us if you need information about a specific record or retention period.

Deleting data from Kick does not delete messages already posted to Slack or copies retained by other workspace members. Slack workspace retention and deletion controls apply to those copies.

Request access, an export, or deletion

Any individual may request access to, correction of, an export of, or deletion of their personal data held by Kick. Workspace owners may also request an export or deletion of their workspace’s Kick records. You do not need a separate Kick account or to uninstall first to contact us.

Email kick.bot.help@gmail.com with the subject “Kick data request.” Tell us which action you want, your Slack workspace name or ID, and your Slack member ID if the request concerns your own data. We will verify your identity and authority before providing or deleting records, and will not disclose other members’ data to an unauthorized requester.

We aim to provide requested access or an export within 14 days and confirm deletion within 30 days after verification. If a request requires more time, or specific information must be retained for a legal reason, we will explain this when responding. Exports can be provided in a machine-readable format so you can transfer your data.

Contact and policy changes

For questions about this policy or how your data is handled, contact the Kick Bot team at kick.bot.help@gmail.com. Our support page is also available without signing in.

We will publish policy changes on this page and update the date above. Review this policy before installing the app or sharing information through it.