How to Manage Twitter DMs

Imagine Noor runs partnerships for a small agency. Potential clients sometimes reply to her posts and then send a private project brief. Her first decision is who can begin that private conversation. In X, the Direct Messages settings determine whether requests can come from everyone, Verified users and people she follows, or only people she follows. “Everyone” gives a new client a path in but also creates more requests to inspect. Verified-only narrows that path; it is not a judgment about whether a specific client is worth answering.

On x.com, X documents the route as More → Settings and privacy → Privacy and safety → Direct Messages. Its mobile instructions start from the navigation or profile menu, then the same privacy area. Choose the current receiving option deliberately, then test it with an account you do not follow. A setting is useful only if the people you expect can actually reach you. If Noor invites prospects to DM her after a webinar, she should send one test from an ordinary attendee account before publishing that invitation.

X notes that turning off broad requests does not stop an existing conversation with someone Noor does not follow. Blocking or reporting is a separate action. This is easy to miss when changing a noisy account to a narrower setting: old conversations may keep receiving messages while new strangers cannot start one.

Write the choice down for the team that uses the account. If Noor chooses Verified-only, her colleague should know that an unverified client may need a public reply, an introduction, or another agreed channel. Otherwise the colleague may interpret silence as disinterest when the message never had a route to Noor’s inbox.

A message from a person Noor does not follow can wait in Requests rather than the main inbox. X says opening the pending request does not send a read receipt until she accepts it. She can therefore inspect a brief before deciding whether to accept, delete, report or block. Accepting moves the conversation into the inbox; deleting removes the request from her view but does not itself prevent another message from that account.

A workable routine is a daily ten-minute pass when inbound DMs matter, or a twice-weekly pass for a quieter account. Noor checks the sender, reads the text, and decides one action. A genuine inquiry asking for a proposal gets accepted and receives a specific response. A vague “hi” can wait for context. A malicious link gets reported or blocked. This is a business rule for Noor, not a claim that X sorts commercial intent for her.

X says its quality filter hides some lower-quality requests behind a view at the bottom of Requests and does not notify the account about them. The filter can be changed from Requests → Change settings → Quality filter on supported mobile apps. Noor should inspect that hidden view periodically if an important introduction might come from an unfamiliar account. She does not need to disable filtering permanently to review it.

Do not call every filtered request spam. The platform says it hides messages it thinks may be lower quality; that is a classification, not proof about a particular person. If Noor expects a brief from a new client, she can ask the client to identify the account in a separate channel and search the request views. The same applies when an invitation says “DM me” but the sender reports that no reply arrived.

As of November 2026, X documents Chat as an encrypted messaging feature alongside legacy Direct Messages. A Chat message request to someone who does not follow the sender may be unencrypted until acceptance; after acceptance the conversation can become encrypted if both people meet Chat’s eligibility conditions. Chat also places requests in Priority or Hidden views using Grok classification. The older DM help describes Requests and a Quality filter. These are related inbox jobs, but the labels and encryption state are not interchangeable.

Noor can make a simple map for her account: look in legacy Requests for a client’s ordinary DM, then look in Chat’s Priority and Hidden requests for a Chat invitation. If she only scans one view, she cannot conclude that nobody wrote. If a sender says “I sent it in Chat,” ask them which account they used and check that surface before escalating an apparent delivery failure.

The distinction matters beyond notification placement. X says encrypted Chat content is protected with keys and a PIN. X documents a separate Chat API whose client handles encryption keys, so ordinary DM permissions alone do not establish that a third-party inbox can display Chat content. Noor can still keep a private note that a proposal is due, but she should open Chat for the actual message and verify what was agreed. She should not paste sensitive content into a less appropriate tool merely to make a dashboard look complete.

Chat recovery is also operational. X says a user who forgets the PIN can change it from an already signed-in mobile device and preserve encrypted history; resetting it when that path is unavailable loses access to the encrypted history. If Noor’s account holds important client agreements in Chat, she should know which signed-in device can change the passcode before replacing a phone. That is a different precaution from requesting a legacy DM archive.

X can keep a few conversations visible. Its pinning help says up to six conversations can be pinned at the top of the DM inbox. Noor might pin an active client negotiation and a supplier quote, then remove them when those items close. A pin means “easy to find,” not “respond by Thursday.” If six pins stay there for months, the signal has gone stale.

X also supports Snooze notifications for intervals such as one hour, eight hours, one week or forever. This quiets alerts from a conversation; it is not a reminder to write back when the interval ends. If Noor snoozes a lively agency group for a week, she should put the proposal deadline in her calendar or task list separately. The same distinction applies to marking a thread unread: it may draw attention, but it lacks a named owner and date.

Use the DM search bar to retrieve a phrase or person. Noor can search “renewal scope” and jump to the message where a client asked for a revised quote. X says images and GIFs are not searchable this way, so she might annotate “latest diagram sent as image” in the work record. Search is excellent for evidence; a dated task is better for the next action.

The table is a quick rule for busy operators. When Noor asks “where is the quote?” she should use search. When she asks “what do I owe?” she should open her task record. When she asks “why did I not see this?” she should inspect Requests, Chat and notification settings before concluding that X dropped the conversation.

A good DM habit has a short handoff from message to work. For each real opportunity, Noor records the person or account, the date and gist of the last meaningful message, the commitment, the owner and the due date. “Aster Agency asked for a revised launch scope; Noor to send two options by Friday” is actionable. “Aster Agency, warm lead” is only a label. If there is a thread link, keep it with the note so the next person can verify the summary.

This is especially useful when a conversation jumps to a call. A client may DM “Thursday works,” then discuss budget on a video call. Noor should record which statement came from the DM and which came from the call. Otherwise a later teammate may search X for a budget number that was never written there. The record should preserve provenance, not just a plausible story.

A solo operator can do this in a task manager and spreadsheet. An agency with several client groups may need a shared contact and deal record, but the data fields are the same. The point is to give the next action a place that will surface when due. Do not use a pile of pinned threads as an invisible task queue.

Make a weekly review short and specific: inspect open commitments, search the source thread for any new reply, close tasks that were completed, and change dates that were renegotiated. If a client writes from a different X handle, X says handles can change, so confirm the account or person before moving notes. A similar display name is not sufficient evidence.

X says Show read receipts is enabled by default for legacy DMs and can be turned off in Direct Messages privacy settings. Turning it off also prevents Noor from seeing other people’s read receipts. That is a tradeoff, not a productivity hack. If her agency promises a same-day response to clients, she should meet that promise with an owner and deadline rather than relying on whether a read marker appeared.

Requests have a different rule: X says the sender cannot see that Noor viewed a pending request until it is accepted. That gives her time to triage, but it also means a sender has no confirmation that a business inquiry reached the right person. When Noor accepts a genuine request, a short acknowledgment such as “I have the brief; I will send availability tomorrow” closes that ambiguity and creates a clear next step.

Deleting and blocking also need care. X says deleting a legacy DM or conversation removes it from your account only; others in the conversation can still see it. Deleting a group conversation also leaves that group. If Noor is archiving an agency account before a staffing handoff, she should not treat a local delete as a deletion of the other participants’ copies.

For an inappropriate message, use the platform’s report and block controls. For a legitimate client whose alerts are distracting, use Snooze notifications and keep the task date elsewhere. The correct tool depends on whether Noor wants fewer alerts, a closed conversation, or a preserved business commitment.

Suppose Noor is away and a colleague must answer Aster Agency. The colleague needs to know which account wrote, what question was asked, whether it was already answered, and what Noor promised next. A forwarded screenshot may show the words but lose the date, thread context and later replies. A contact record can keep those pieces together, provided it points back to the original conversation and the teammate has appropriate access.

If the agency also speaks to Aster on Telegram, avoid merging the X and Telegram identities from a matching name alone. Ask Aster to confirm the handle or use a known introduction. Then record the second channel against the same person, with the basis for the match. This is not an instruction to move Aster away from X; answer in the channel Aster chose and keep the business record coherent behind it.

Before selecting a shared inbox, test a real request, a legacy thread, an encrypted Chat thread, a group conversation and an attachment. X’s DM API description says applications receive nonpublic DM access only with explicit account permission. That permission is a necessary condition for an integration, not proof that every message type or request state is represented. Make the vendor show the exact coverage on the account the agency will use.

Where Pantheon fits: its invite-only alpha places supported, API-visible X DMs beside contacts, notes and deals, alongside Telegram, WhatsApp and iMessage. The X DM connection is a paid add-on. Encrypted X Chat is outside that X connection. WhatsApp and iMessage require the Mac app, with iMessage messages present on the Mac; Instagram DMs are not captured. Suggested cross-channel matches require your approval. For Noor, the useful test is whether Aster’s X request and confirmed Telegram identity produce one accurate working record.

Do not assume “Verified-only” means all valuable prospects can reach the account. Noor’s unverified but qualified buyer may be unable to start a request. Test the setting with a real outside account. Do not assume the Quality filter deletes messages; X says it hides lower-quality requests behind a view. Check it when an expected introduction seems absent.

Do not mistake a pinned conversation or snoozed notification for a reminder. Neither records the date Noor promised a revised scope. Do not treat Chat’s Priority and Hidden views as labels for the older Requests folder; X documents them separately. Finally, do not treat a downloaded archive as a live team queue. It preserves a snapshot, while the follow-up record must be maintained as the relationship continues.