> ## Documentation Index > Fetch the complete documentation index at: https://docs.parable.work/llms.txt > Use this file to discover all available pages before exploring further. # Pings > Ask a person to answer a question or stay informed from a Problem, and follow the answer back into the work. # Pings A Ping asks a specific person to weigh in on a Problem, or tells them something they should know. A Problem is a thread several people read at different times, so a question put to it must outlast the moment it was asked. A Ping is a durable record with recipients, an inbox item for each of them, and their responses. Someone who was not in the conversation can still answer it later. A Ping has one of two purposes. A Consult Ping asks one or more questions. Each question can offer Possibilities: named options, each with a summary of what choosing it means, its pros and cons, and who should decide. A question is answered with one choice, several choices, or a ranked order. A person can always answer in their own words, attach a picture, add a note to a choice, or say they need more information. An Inform Ping says its news once and asks nothing. Each recipient gets their own item in their Ping inbox, which carries minimal content. Delivery, reading, responding, and closing are tracked separately. When Ponder needs a decision from the people in a conversation, it asks a question, and that question becomes a Ping on the Problem. The question card appears in the reply that asked it. The answers arrive as a new Message, so Ponder ends its turn after asking instead of guessing an answer or asking again. A Ping creates attention, not authority. It does not grant Workspace membership, open the source Problem or Parable, assign a responsibility, or widen an audience. When the Problem belongs to a Parable, answering needs Pinging participation or higher on it; a person with only Peeking sees the questions but cannot answer. A permitted person who was not addressed becomes a recipient by answering, which is how a colleague joins a question already asked of someone else. Only the sender closes a Ping, and closing leaves what recipients already received, read, or answered as it was. Put only information the recipient is allowed to see into a Ping. Never paste restricted content, hidden identifiers, or customer data into it. 1. Name the decision or fact you need, and why it matters to the Problem. 2. Choose the right purpose. Ask Ponder to consult when you need an answer, a review, or a choice. Ask it to inform when someone only needs to know. 3. Choose the intended people, not a broad audience. Ponder can search the Workspace for the person to address. 4. For a consult, split distinct decisions into separate clear questions. Offer Possibilities with honest pros and cons when the options are known, pick single choice, several choices, or ranked order, and leave a question open when they are not. 5. State when a response is needed and what happens with the answer. 6. Read the responses as they arrive. Ask Ponder to list the Pings sent about a Problem, read one you sent, or show your own Ping inbox. Close a Ping you sent once it has served its purpose. A good Ping names one clear purpose, reaches the few people who can answer, and carries enough safe context for them to answer without opening anything they cannot access. Check the result by reading the Ping back: its recipients, each recipient's response state (awaiting response, responded, or closed without response), and whether the answers arrived in the Problem as a Message. If a long discussion is needed, bring the authorized people into the Problem instead of turning the Ping into a parallel conversation. If a recipient cannot open the source context, give them access through the ordinary Workspace and Participants flows or send a safe summary. Related Powers: Problems, Participants, Policies, Workspaces. Find each by its title; do not guess stored names. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.