When the person who has managed a subscription leaves, the incoming administrator needs more than a forwarded invoice. They need a clear record of what plan is in use, which dates have actually been confirmed, what still needs checking, and who will follow up. A careful handoff avoids treating assumptions as billing facts or assuming that a particular account has a dedicated billing-role feature. Use this checklist to transfer the information you have, mark what remains unknown, and confirm that the next administrator can reach the relevant account pages.
The useful bits
- Record the workspace and plan identifiers exactly as displayed; do not infer them from a mailbox address.
- Label dates as confirmed, estimated, or unknown, and note where each confirmed date came from.
- Have the incoming administrator verify account access and unresolved items before the departing administrator steps away.
Agree on what the handoff covers
First, establish whether the change is an administrative contact change, a change in who manages the subscription, or both. These are not automatically the same thing. Do not assume that a workspace has a separate billing role, or that changing an administrator changes subscription ownership or payment arrangements.
Agree on a handoff date and identify who will check each open item. If the incoming person cannot access the account or is not authorised to view a relevant record, note that as a blocker. Use the account's available controls only when the person's role, plan, and provisioning state permit them.
Capture identifiers without guessing
Copy the workspace or domain identifier, the subscription or plan label shown in the account, and the mailbox or service scope the plan covers. Preserve spelling and punctuation. If a record displays an identifier, include it; if it does not, write “not shown” rather than creating a substitute.
For BITTU Mail, sign-in and account actions go through mail.bittuicloud.com. If the administrator needs current plan information, live pricing, term totals, taxes, availability, and renewal terms must be checked at /pricing or in authenticated checkout. Do not put a quoted price in the handoff as if it were guaranteed to remain current. A trial, if relevant, has eligibility and availability checked by the service; do not assume it can be claimed.
- Workspace/domain name and exact identifier, if displayed.
- Plan name and the account or mailbox scope it appears to cover.
- Source of each detail: account view, checkout, or an existing record.
Separate confirmed dates from estimates
Record dates with labels: confirmed, estimated, or unknown. Useful entries may include the date the current term began, its displayed end or renewal date, a trial end date if shown, and the date responsibility changes hands. Include the time zone when the source provides one. Do not calculate a renewal date from memory or infer it from an old message.
For every confirmed subscription date, note where it was checked and when. If the page does not show a date, write that plainly and assign someone to verify it through the account or authenticated checkout. Avoid recording a payment outcome or automatic charge as certain unless the account explicitly confirms it; one-time checkout does not itself imply an automatic charge or mandate.
Handoff date: [YYYY-MM-DD] — agreed by both administrators Plan label: [exact displayed label] — checked at [source] on [YYYY-MM-DD] Term end/renewal: [displayed date or “not shown”] — [confirmed / needs verification] Outstanding date question: [question] — owner: [name or role] — follow-up: [date]
Transfer the records, not just the login
Share a concise record through an approved organisational channel. Include relevant invoice or checkout references only if the incoming administrator is authorised to receive them. Do not put passwords, one-time codes, or recovery secrets in the handoff. Each person should use their own permitted sign-in and account recovery process; never share credentials as a shortcut.
If the departing administrator has saved useful correspondence, identify its date, subject, or reference so the successor can locate it. Do not claim that a forwarded email proves a payment, ownership change, or renewal. Treat it as supporting context and check account information where access allows.
Keep unresolved questions visible
A useful handoff has an explicit list of unknowns, not a polished summary that hides uncertainty. Questions might include whether the displayed plan covers every intended mailbox, which renewal terms apply, whether availability has changed, or which person is authorised to make an account action. Assign each question to a named owner or role and a follow-up date.
If an answer depends on current availability, eligibility, taxes, or renewal terms, direct the incoming administrator to verify it at /pricing or authenticated checkout rather than copying an old estimate. If the relevant account control is unavailable to them, record the access limitation and use an authorised route to resolve it.
Confirm the handoff before closing it
Ask the incoming administrator to confirm that they can sign in through mail.bittuicloud.com, locate the relevant account information permitted by their role, and understand which dates are confirmed versus pending. They should compare the identifiers in the handoff with what they can currently see and report any mismatch.
Close the transfer only when both people agree on the responsibility-change date, the record has been received, and every unresolved question has an owner. If the incoming administrator cannot verify an item, leave it marked pending rather than treating silence as confirmation. The result is a usable record of what is known, what was checked, and what still needs attention.
- Incoming administrator confirms access and receipt of the record.
- Plan identifiers and displayed dates match, or discrepancies are assigned for follow-up.
- Open questions have an owner and next check-in date.
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