1 Writing Customer Emails
Customer communication is extremely important in technical support, consultancy, professional services and vendor roles. A customer email should usually answer: what do we know, what do we need, what happens next, and who owns the next action. A useful structure is: greeting, acknowledgement, current understanding, technical findings, required action, next steps, closing.
Compare these two requests for logs. Which one will actually get you useful information back?
A) "Hi, Please send logs. Regards"
B) A message asking for application logs covering ~10 minutes before/after a failed login, with the timestamp, affected username, and error shown to the user, and a note not to include passwords or tokens.
Reveal the answer
B. Message A leaves the customer guessing which logs, from which server, over what time range, and how to collect them — you'll likely get the wrong thing back and have to ask again. A good request makes it easy for the customer to provide exactly what you need in one round trip:
Hello,
Thank you for the information provided.
From the symptoms described, the authentication request appears to be
reaching the application server, but the authentication process is
failing before the session is created.
Could you please provide the application logs covering approximately
10 minutes before and after the failed login attempt?
If possible, please reproduce the issue once and provide:
- timestamp of the test
- affected username
- application server logs
- authentication service logs
- any error shown to the user
Please avoid sending passwords, access tokens or other sensitive
credentials.
Once we receive the logs, we can correlate the request across the
different components and continue the investigation.
Kind regards,
Technical Support2 Avoid Blaming the Customer or Other Teams
Never unnecessarily write "Your configuration is wrong." Instead: "The current configuration does not appear to match the documented requirement," or "We identified a configuration mismatch between the application and the identity provider." This keeps the discussion technical rather than personal — the goal is to solve the problem.
The same applies to other teams and vendors. Avoid statements such as "Networking broke it," "Development caused the outage," or "The customer's firewall is blocking everything," unless the evidence is extremely clear. Prefer neutral language: "The current evidence indicates that the connection is being interrupted between the application and the authentication service. The network team is reviewing the firewall path."
3 Writing Incident Updates
During major incidents, communication becomes extremely structured. A good incident update contains: incident, severity, start time, affected service, impact, current status, actions completed, actions in progress, and next update.
Incident: Authentication failure affecting customer portal
Severity: P1
Start time: 08:42 UTC
Impact:
Approximately 70% of customer login attempts are failing.
Current status:
Authentication servers are operational, but requests from the
application tier are intermittently timing out.
Actions completed:
- confirmed database availability
- validated DNS resolution
- checked load balancer health
- reviewed authentication server logs
Actions in progress:
- network team reviewing firewall connections
- application team capturing failed requests
- IAM team correlating authentication logs
Next update: 10:00 UTCThis format allows someone joining the incident late to quickly understand the situation without having to ask.
4 Executive Communication
Senior management usually wants to know: what is affected, how many users, how severe is the business impact, when did it start, what are we doing, is there a workaround, is customer data at risk, is the issue contained, and when is the next update. They usually do not need packet sequence numbers, stack traces, registry paths, SQL query plans, or TLS handshake details — unless those become directly relevant.
A production authentication issue is currently preventing
approximately 35% of users from accessing the online banking portal.
The incident began at 11:20 UTC.
Customer data is not believed to be affected.
Technical teams have isolated the issue to communication between the
application platform and authentication service.
A temporary workaround is being evaluated.
The next update will be provided at 12:30 UTC.Short. Clear. Useful. Notice it answers the same five questions from Lesson 1 — what happened, who's affected, when, what we know, what's next — just without any implementation detail.
5 Handling Angry Customers & Not Overpromising
Customers under pressure may sound frustrated. Do not become defensive. Avoid "We already told you this isn't our problem." Instead: "Based on the current evidence, our service appears to be operating normally. We are continuing to help isolate where the failure occurs." You can remain firm without being confrontational.
A useful approach: acknowledge, clarify, focus, act. For example: "I understand the impact this outage is having. We have confirmed that authentication requests are reaching the gateway. We are now working with the network team to determine why they are not reaching the authentication service. I will keep the case updated as we progress." Do not argue — focus on facts and actions.
Never promise something you cannot control. Avoid "Engineering will definitely fix this today" — prefer "Engineering is reviewing the issue as a priority." Avoid "We guarantee this will never happen again" — prefer "We are reviewing the root cause and preventative actions." This is the same resolution-ETA-vs-communication-ETA distinction from Lesson 1, applied under pressure.