A business email support brief should describe the problem clearly without handing over passwords or unnecessary message contents. When the first report says only email is not working, the person helping still needs to establish which mailbox, device and action are affected. A short, organised report gives that investigation a better starting point.
This guide helps Kenyan businesses prepare an email-support request and keep a useful record until the issue is resolved. It covers the information to collect, not a universal technical fix. For help with a business mailbox or hosting arrangement, visit Mocky's business email services and explain the symptoms before requesting changes to your account or domain.
Describe the failed action instead of guessing the cause
Start with what the user was trying to do. Could they not sign in, send a message, receive an expected reply or open an attachment? Was a message rejected, delayed or found in another folder? These observations are more useful than deciding immediately that the whole server or domain is broken.
Write the exact wording of an error if one appears, including any code. Record where it appeared: a phone app, a browser, a desktop program or a delivery-failure message. If the wording is long, retain the original privately and provide the relevant part through the support channel you agree with the technician.
Separate the observation from your interpretation. For an illustrative report, write that Outlook showed a particular sign-in error at a named time, rather than stating that the supplier deleted the mailbox. The investigation can then check the symptom without first undoing an unsupported assumption.
Establish the affected scope
Identify the business domain and the affected mailbox or shared address. Explain whether one person or several staff members report the same problem. If a shared inbox is involved, identify it as shared rather than presenting it as an ordinary personal mailbox with several unrelated users.
Note the device and application involved. Include the application name and version where you can find it, the device type and whether the same action works in an already-approved alternative such as the provider's webmail. Report the comparison as an observation. It helps narrow the investigation but does not by itself prove which component failed.
Explain the business impact without attaching confidential material to demonstrate urgency. For example, state that the accounts team cannot send supplier correspondence, or that a shared sales address has not received expected messages. Give the technician enough context to prioritise and scope the work without circulating invoices or customer files unnecessarily.
Put the timing in a form another person can use
Record when the issue was first noticed and when the relevant action was last known to work. Include the date, time and time zone. Nairobi time is a useful reference for a local team, but say so explicitly if a supplier or staff member is elsewhere.
List recent changes that might be relevant. These could include a new device, a changed account setting, a hosting move, a domain change or an update to the software used for email. Do not assume the most recent change caused the problem; provide it as part of the timeline for the technician to assess.
Keep one incident reference if several people are reporting the same issue. Ask staff to add observations to that record rather than sending contradictory instructions to different providers. A coordinated history makes it easier to compare what happened before and after a proposed correction.
Capture screenshots without exposing the whole inbox
Show the error and enough surrounding context to identify the application. Before sharing, check the screenshot for message previews, private addresses, recovery information, meeting details and attachments that are unrelated to the request. Crop or redact unnecessary content while leaving the error readable.
Avoid editing the error wording itself. If you cover part of an image, make it clear that material has been removed. The aim is a faithful record with less irrelevant information, not an attractive screenshot that hides the technical detail the recipient needs.
Choose the support channel deliberately. Ask how files should be supplied and who needs to see them. Do not post a full inbox screenshot in a public comment because a provider has not yet answered an enquiry. Begin with a concise description and share additional evidence privately when it is needed.
Use message headers only when they help the investigation
For a delivery or routing investigation, the technician may request the original message headers. Google's Gmail header instructions describe opening the received message and using More, then Show original, to view the full header. Follow the instructions for the actual mail service you use rather than assuming every app has that menu.
Headers are diagnostic material, not a substitute for explaining the problem. Identify the relevant message and the symptom it demonstrates. Ask which portion the technician needs and use the agreed private channel. Check for personal addresses and other identifying details before distributing diagnostic information beyond the support team.
If the problem concerns a delivery-failure message, retain that message and the associated sending time. Do not send the technician an unrelated successful message simply because it is easier to find. The useful evidence is the item connected to the specific failure being investigated.
Keep account access separate from the first enquiry
Do not put mailbox passwords, one-time codes or recovery codes into a general enquiry form. Explain who administers the account and ask what access is needed for the agreed support task. An initial diagnosis may need less information than a later, authorised configuration change.
Where the service supports named administrative access, ask for an appropriate role rather than casually sharing a staff member's sign-in. Establish who approves access and when it should be reviewed afterward. If a supervised session is proposed, agree the scope and retain control of the business's own authentication steps.
Record access arrangements without recording the credentials themselves. A support note can state that an authorised administrator will make an agreed change or provide a supervised review. It should not become a permanent password list shared with every person copied into the incident.
Avoid uncoordinated changes while evidence is collected
Ask one responsible person to coordinate any proposed account, hosting or domain changes. If several staff members simultaneously remove accounts from devices or change settings, it becomes harder to establish which action affected the result. Tell the technician what has already been attempted, including unsuccessful attempts.
Before a proposed change, ask what it affects, what interruption may occur and how the result will be checked. For a domain or provider move, request a separate plan rather than treating a support ticket as permission for an unplanned migration. Our business email migration guide covers that broader project.
Keep relevant existing messages available according to your business's normal records process. Do not delete evidence or reset a device simply to start fresh unless the responsible support person has assessed the situation and the authorised business owner agrees to the scope.
Confirm the actual business task after a fix
Return to the action that failed. Ask the affected user to confirm that it now works on the relevant device or shared mailbox. A successful technician login does not necessarily demonstrate that the staff member's original sending, receiving or shared-access task has been restored.
Agree any test communication before sending it. Use approved recipients and harmless content, and identify it as a test. Do not repeatedly send quotations, customer records or automated notifications simply to check whether the system responds. The test should demonstrate the required path without creating unnecessary business activity.
Document what was changed, what was verified and what remains unresolved. If only one device has been checked, say so. Retain the support reference and any follow-up responsibility. That gives the business a usable record if the symptom returns and avoids describing a limited check as a complete service audit.
A short support request you can adapt
Use the following as a structure, filling in your own observations rather than copying the illustrative situation as a diagnosis:
Business domain and affected mailbox or shared address.
Action attempted and exact error wording.
Device, application and relevant version.
Date, time and time zone of a recent example.
Number of people affected and known working alternatives.
Relevant recent changes and actions already attempted.
Business impact and the authorised coordination contact.
Add an appropriately redacted screenshot if it is useful. Keep credentials and unrelated message contents out of the request. The technician can then ask for a specific header, log or supervised check instead of receiving a large bundle of private material without context.
Frequently asked questions
Should I send my password so support can start faster?
Keep passwords out of the initial enquiry. Describe the problem and agree a suitable access method with the responsible provider if access becomes necessary. Never treat a general contact form as a secure credential handover process.
Does working webmail prove the phone app is faulty?
It is a useful comparison to report, but let the technician assess the cause. Provide the application, device and error details rather than turning one successful observation into a final diagnosis.
Is every delivery problem a spam-filter problem?
No. State whether the message was rejected, delayed, missing or found in a particular folder. That distinction helps establish the next investigation. Do not change domain records based only on the broad description that email is not working.
How do I request email help from Mocky?
Send your business email support brief through the project enquiry page, with the affected domain, symptoms and a coordination contact. Ask for the investigation scope and any required access arrangement to be confirmed before changes begin.
