A customer may ask whether another person has an account, what plan they use, or whether a message or payment reached them. Even a well-intentioned request can involve information that belongs to someone else. The useful response is not simply “no”: acknowledge the concern, explain the boundary without revealing or confirming anything, then offer a practical next step for the customer’s own account or workspace. This keeps the conversation respectful and gives the person something constructive to do, while avoiding promises about what support can disclose or resolve.
The useful bits
- Do not confirm or deny another person’s account details.
- Explain the privacy boundary briefly and without blame.
- Redirect the customer to a next step for their own account or authorised workspace.
Set the boundary without confirming anything
Avoid sharing another customer’s account status, mailbox address, plan, activity, contact details, or support history. Also avoid confirming that the person or organisation has an account at all. A yes-or-no answer can disclose information just as readily as a detailed explanation.
Keep the wording calm and neutral. You do not need to accuse the requester of bad intent or provide a long explanation of internal procedures. State that you cannot discuss another customer’s account, then turn to what you can help with.
“I understand why you’re asking. I can’t confirm or share information about another person’s or organisation’s account. I can help you look at the issue affecting your own account.”
Acknowledge the reason behind the request
A privacy boundary can feel abrupt if the customer is worried about a missing message, a shared project, or an unfamiliar charge. Recognise the problem they describe without accepting an unverified claim about another account. For example, say, “I can see why a missing project email would be frustrating,” rather than, “I’ll check what happened in their mailbox.”
This distinction matters: you can respond to the customer’s experience while keeping the other person’s information private. If the issue involves a colleague or business partner, suggest that the account holder contact support directly or share relevant information with the customer themselves, if they choose.
Offer a route that stays within their own account
Ask what the customer is trying to accomplish, then guide them toward a next step that concerns their own account. If they cannot sign in, all sign-in, registration, and account recovery actions go through https://mail.bittuicloud.com. Do not ask them to send a password or one-time code in a support message or to an assistant.
If the question concerns a business workspace, distinguish the requester’s own access from another person’s mailbox. Workspace domain and mailbox administration is for authorised admins, and permissions are enforced server-side. Controls depend on the person’s role, plan, and provisioning state; do not imply that every user can inspect or change every mailbox.
Make the response specific to the actual problem
A useful redirect names a concrete next step instead of ending at the privacy refusal. For a message the customer expected, ask them to describe the issue from their side: which address they used, approximately when they sent it, and what they can see in their own mailbox. Ask only for information needed to understand their own case; do not request another customer’s credentials or private account records.
If the customer is an authorised workspace or domain admin, they can review their own domain in /workspace, subject to role, plan, and provisioning. Public DNS diagnostics are not offered. Do not suggest that an admin can inspect an unrelated customer’s domain or mailbox.
“I can’t check or confirm another organisation’s mailbox. If a message you sent is missing from your side, tell me the sending address and an approximate time, and I can help you consider the next step for your own account.”
Use a short checklist before sending
Before replying, check that the message is both respectful and limited to information the requester is entitled to discuss. A brief review can prevent accidental disclosure through a seemingly harmless confirmation.
- Did I avoid confirming whether the other person or organisation has an account?
- Did I avoid sharing their address, plan, activity, or support history?
- Did I acknowledge the requester’s concern without endorsing an unverified assumption?
- Did I offer one next step involving the requester’s own account or authorised role?
- Did I avoid asking for passwords, one-time codes, or unnecessary private details?
Confirm the next step, not the other customer’s status
Close by making clear what the customer should do next and what information would help with their own issue. If they follow that step, confirm that you have received their reply or can continue addressing the issue they described. Do not imply that you checked the other account, that the other person will be contacted, or that a particular outcome is guaranteed.
A successful response is one that leaves the requester understanding the boundary and knowing how to proceed. If they repeat the request, restate the limit briefly and return to the available help for their own account. Consistency is more useful than adding speculative reasons or details that could reveal information.
“I can’t confirm details about another customer’s account. Please reply with what you can see in your own account and the issue you’re trying to resolve. I’ll use that information to guide the next step for you.”
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction