> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gettap.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Feature requests

> Ask for something you need in Tap, and upvote what other people have asked for.

Feature requests are how you tell us what Tap should do next. Anyone using the app can submit one, see what everyone else has asked for, and upvote the requests they want too.

The votes matter. A request with a hundred upvotes is a different signal from one person's idea, and it's the clearest evidence we have of what to build.

## Finding it

Open **Settings** and choose **Request A Feature**.

## Submitting a request

<Steps>
  <Step title="Choose Submit A Request">
    From the feature requests list.
  </Step>

  <Step title="Give it a short title">
    This is what everyone else sees in the list, and what they decide to vote on. "Export leads to CSV" beats "improvement to the leads screen".
  </Step>

  <Step title="Describe what you need">
    Say what you're trying to do and why the current app makes it hard. The problem is more useful to us than a proposed solution — there's often a better fix than the one you'd have asked for.
  </Step>
</Steps>

<Tip>
  **Search the list before you submit.** If someone has already asked for your feature, upvoting theirs counts for more than a second copy of it — split votes make a popular request look like two unpopular ones.
</Tip>

## Voting

Every request shows its upvote count and who submitted it. Tap the upvote to add your vote, and tap it again to take it back if you change your mind.

Vote for anything you'd genuinely use. There's no limit and no cost to you, and an honest vote is what makes the ranking worth reading.

## Where a request stands

Each request carries a status, so you can see whether anything happened to it:

| Status | What it means |
| - | - |
| Pending | Submitted and waiting to be reviewed. Most requests sit here. |
| Planned | We've decided to build it. No date attached. |
| In Progress | Being built now. |
| Shipped | It's in the app — update to the latest version if you don't see it. |

<Note>
  **Pending is not a rejection.** It's the default state, and a request can sit there for a long time while still being read. A high vote count on a pending request is exactly the thing that moves it.
</Note>

## What makes a request likely to get built

<AccordionGroup>
  <Accordion title="Describe the situation, not just the feature" icon="location-dot">
    "I need this at trade shows, where I capture forty leads in a day and have no signal" tells us far more than "add bulk edit". The constraint is usually the part that changes the design.
  </Accordion>

  <Accordion title="One request, one idea" icon="list-ol">
    A request bundling five things can't be voted on coherently — people who want the third item have to vote for the other four. Split them.
  </Accordion>

  <Accordion title="Say what you do today instead" icon="arrow-right-arrow-left">
    The workaround you've built tells us how bad the gap really is. If you're exporting to a spreadsheet every evening, say so.
  </Accordion>

  <Accordion title="Small and specific beats big and vague" icon="crosshairs">
    "Remember my last-used meeting type" is a request we can act on. "Make meetings better" isn't, however strongly you mean it.
  </Accordion>
</AccordionGroup>

<Warning>
  Feature requests are visible to other people using Tap, along with your name. Don't put customer names, deal details, or anything confidential in one.
</Warning>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.