IT Support Documentation Portfolio

Write C1-level IT support docs: tickets, SOPs, and escalation emails.

Introduction

30 Second Summary

When you contact a company for technical help, the quality of their written response tells you everything about that company. In IT support, every ticket response and email you write is a direct reflection of your professionalism.

In this project, you will create a professional IT support documentation portfolio containing four polished documents. Each document targets a different IT support skill while practicing the advanced English writing patterns that hiring managers test for in interviews and written assessments.

What You'll Build

A 4-document IT support portfolio in Google Docs that demonstrates professional writing across four core documentation formats used by help desk teams worldwide.

By the end of this project, you'll have:

A structured troubleshooting guide with step-by-step diagnostic procedures and escalation criteria for Wi-Fi connectivity issues.
Three professional ticket responses covering the full support lifecycle from initial acknowledgment to resolution and closure.
A formal escalation email to a senior engineer and a complete Standard Operating Procedure for new employee laptop onboarding.
A professionally crafted response to a frustrated customer's repeated complaint, balancing empathy with a concrete action plan.

Do I need IT support experience?

No prior IT support experience is required. This project teaches you the documentation formats and writing patterns from scratch. All you need is a Google Account.

Set Up Your Portfolio Workspace

In IT support, organization matters just as much as technical skill. When a hiring manager reviews your portfolio, the first thing they notice is structure.

In this step, you will create a dedicated folder in Google Drive and set up four blank documents using Google Docs. Each document maps to a core IT support writing skill you will practice throughout this project.

In this step, get ready to:

Create a portfolio folder in Google Drive.
Create and format a troubleshooting guide document.
Create three more documents for ticket responses, an escalation email, and an SOP.

Create the portfolio folder

Your portfolio needs a single folder to keep all four documents together. This folder is what you will share or reference during job interviews.

Open Google Drive by navigating to drive.google.com in your browser.
Click New in the top left corner.
Click New folder.
Type IT Support Portfolio - followed by your actual name as the folder name.
Click Create.

Your new folder appears in Google Drive.

Double-click the folder to open it.

Don't see the New button?

Make sure you are on drive.google.com, not docs.google.com. The New button only appears on the main Google Drive page.

If you are signed into multiple Google accounts, check that you are using the correct one by clicking your profile icon in the top right corner.

Help me find the New button in Google Drive.

Create the first document

Professional IT documentation follows consistent formatting. Arial at size 11 with 1.15 line spacing is the standard across most IT support teams.

Inside your portfolio folder, click New in the top left corner.
Click Google Docs.
Click Blank document.
Click on Untitled document at the top left of the page.
Replace it with Troubleshooting Guide - Wi-Fi Connectivity.
Check that the font dropdown in the toolbar shows Arial. If it shows a different font, click the dropdown and select Arial.
Check that the font size box next to it shows 11. If it does not, click the box and type 11.
Click Format in the menu bar.
Hover over Line & paragraph spacing.
Select 1.15 if it is not already selected.

Why these formatting choices?

Arial 11pt with 1.15 line spacing is clean, easy to read on screens, and prints well. IT support teams use these settings because their documentation gets read quickly during live troubleshooting.

Applying consistent formatting across all four of your documents shows attention to detail. Hiring managers notice these small professional choices.

Your document title should read Troubleshooting Guide - Wi-Fi Connectivity at the top left of the page. The toolbar should show Arial and 11 in the font settings.

Create the remaining three documents

You need three more documents to complete your workspace. Each one will hold a different type of IT support writing.

Navigate back to your portfolio folder in Google Drive by clicking the folder icon or folder name link near the top of the Google Docs page.
Click New in the top left corner.
Click Google Docs.
Click Blank document.
Title this document Ticket Responses - Wi-Fi Issue.
Navigate back to your portfolio folder.
Create another blank Google Doc using the same steps as before.
Title it Escalation Email - Network Issue.
Navigate back to your portfolio folder.
Create one more blank Google Doc.
Title it SOP - New Employee Laptop Onboarding.

What is an SOP?

A Standard Operating Procedure is a step-by-step document that describes how to complete a specific task. IT support teams use SOPs to make sure every technician follows the same process, regardless of experience level.

Navigate back to your portfolio folder in Google Drive.

You should see all four documents listed inside your folder:

Troubleshooting Guide - Wi-Fi Connectivity.
Ticket Responses - Wi-Fi Issue.
Escalation Email - Network Issue.
SOP - New Employee Laptop Onboarding.

Missing a document from the folder?

If a document is not inside your portfolio folder, you may have created it outside the folder by accident. Check the main page of Google Drive for any stray documents.

If you find one outside the folder, right-click it and select Organize, then Move. Select your portfolio folder as the destination.

Help me move a document into my portfolio folder.

Your workspace is ready. Next up, you will write your first document: a structured troubleshooting guide for one of the most common Tier 1 support issues.

Write a Troubleshooting Guide

Your portfolio workspace is set up with four empty documents ready to fill. Now it is time to write the first and most foundational one.

A troubleshooting guide is the document that Tier 1 support technicians reach for during live calls. Writing one well requires both technical clarity and professional-level English, so this is the perfect place to start practicing C1 writing patterns.

In this step, get ready to:

Write the header and overview section with C1 hedging language.
Create a 5-step diagnostic procedure using formal register.
Add escalation criteria and a document footer.

Write the header and overview section

Every professional troubleshooting guide starts with a header section. The header identifies the document, tracks its version, and tells the reader exactly what the guide covers.

Open your Troubleshooting Guide - Wi-Fi Connectivity document in Google Docs.
Type the following title at the top of the document:

Troubleshooting Guide: Laptop Cannot Connect to Wi-Fi

Below the title, add these four metadata fields on separate lines:

Document ID: TG-WIFI-001
Last Updated: [today's date]
Author: [Your Name]
Applies to: Windows 10/11, macOS

What are these metadata fields for?

Document IDs like TG-WIFI-001 let teams quickly reference guides in tickets and emails without typing long titles.
The "Last Updated" date tells technicians whether the guide is still current or needs review.
"Applies to" scopes the guide so technicians know which operating systems the steps cover.

Now for the interesting part. Below the metadata, you will write an "Overview" paragraph that explains what this guide covers and who should use it.

This is where you practice your first C1 writing pattern: hedging language.

What is hedging language?

Hedging softens statements using modal verbs like "may," "might," and "could," or hedging verbs like "seem," "appear," and "tend to." In IT support, you rarely diagnose with 100% certainty. Hedging reflects that reality while maintaining confidence.

A B2-level writer would say: "This guide fixes Wi-Fi problems." A C1-level writer hedges: "This guide is intended to assist Tier 1 support technicians in diagnosing and resolving the most commonly reported Wi-Fi connectivity issues."

Notice how "is intended to assist" and "most commonly reported" sound confident without making an absolute claim.

Below the metadata, type the heading Overview.
Under the heading, write 2-3 sentences explaining what this guide covers and who should use it.
Include at least two hedging phrases. Use modal verbs like "may" or "should" and hedging verbs like "is intended to" or "may also serve as."

Pro tip: model overview

Here is an example of a strong Overview paragraph you can use as a reference:

"This guide is intended to assist Tier 1 support technicians in diagnosing and resolving the most commonly reported Wi-Fi connectivity issues. It may also serve as a reference for Tier 2 engineers who require additional context before conducting advanced network diagnostics."

Write your own version. You can follow a similar structure, but use your own phrasing.

Save your document after writing the Overview.

Your document now has a professional header that matches what you would find in a real IT team's knowledge base.

Write the step-by-step troubleshooting procedure

The diagnostic procedure is the core of any troubleshooting guide. Each step gives the technician a clear action, the expected result, and what to do if things go differently.

Below your Overview section, type the heading Diagnostic Procedure.
Write 5 numbered steps covering these checks in this exact order:

Verify Wi-Fi is enabled on the device.
Restart the network adapter.
Forget and reconnect to the network.
Run the built-in network troubleshooter.
Check if other devices can connect to the same network.

For each step, include three parts: the action instruction, the expected result, and what to do if the expected result does not occur.

What should each diagnostic step look like?

Here is an example of a well-written diagnostic step:

"Step 1: Verify Wi-Fi is enabled on the device.

Action: Navigate to Settings, then select Network & Internet. Confirm that the Wi-Fi toggle is set to On.

Expected Result: The Wi-Fi toggle is enabled and the device displays available networks.

If Unsuccessful: If the toggle appears greyed out, proceed to Step 2 to restart the network adapter."

This is also where you practice your second C1 writing pattern: formal register.

What is formal register?

Register is the level of formality in your writing. Formal register avoids contractions, slang, and casual phrasing. In IT documentation, it signals precision and professionalism.

Instead of "just click on Settings," write "Navigate to Settings, then select Network & Internet."
Instead of "go to the adapter settings," write "Proceed to the network adapter settings."
Instead of "check if it's on," write "Confirm that the toggle is set to On."

Write all 5 diagnostic steps following the three-part format (action, expected result, if unsuccessful).
Use formal register in every step. Write "Navigate to" instead of "go to." Write "Confirm that" instead of "check if." Write "Proceed to" instead of "move on to."
Avoid contractions entirely. Write "does not" instead of "doesn't" and "cannot" instead of "can't."
Save your document.

Read through your 5 steps from start to finish. Each step should flow logically into the next, moving from the simplest check (is Wi-Fi even turned on?) to the most revealing one (can other devices connect?).

Not sure if your steps sound formal enough?

Scan each step for these red flags: contractions ("don't," "it's," "won't"), casual verbs ("just," "simply," "go ahead and"), and vague instructions ("check it," "look at the settings"). If you find any, replace them with their formal equivalents.

help me rewrite my diagnostic steps in formal register

Write the escalation criteria and document footer

Not every Wi-Fi issue can be solved at Tier 1. The escalation criteria section tells technicians exactly when to stop troubleshooting and hand the ticket to a senior team.

Below your Diagnostic Procedure section, type the heading Escalation Criteria.
Write 3-4 bullet points describing specific situations when a Tier 1 technician should escalate to Tier 2.
Use hedging language with modal verbs in every bullet point. Write "should be escalated" instead of "must be escalated." Write "this may indicate" instead of "this means."

Pro tip: model escalation bullets

Here are two examples of well-written escalation criteria:

"Should the issue persist after all diagnostic steps have been completed, the ticket should be escalated to the Network Infrastructure team."
"If the problem appears to affect multiple users on the same network segment, this may indicate a broader infrastructure issue that warrants immediate escalation."

Notice the inverted conditional in the first example: "Should the issue persist" instead of "If the issue persists." This is another C1 pattern that signals professional-level writing.

What is an inverted conditional?

An inverted conditional removes "if" and flips the subject and auxiliary verb. "If the issue persists" becomes "Should the issue persist." "If the user were to report" becomes "Were the user to report."

This pattern is common in formal business and technical writing. Try using it in at least one of your escalation bullets.

Write your 3-4 escalation criteria bullets. Include at least one inverted conditional.

The last piece of a professional troubleshooting guide is a "Related Documents" section. This helps technicians find connected guides without searching.

Below the Escalation Criteria section, type the heading Related Documents.
Add 2-3 placeholder references to other guides. These do not need to be real documents. They show that you understand how documentation links together.

Related Documents:
- TG-VPN-001: VPN Connectivity Guide
- SOP-NET-002: Network Equipment Restart Procedure
- TG-WIFI-002: Wireless Access Point Diagnostics

Why include related documents?

In a real IT team, troubleshooting guides are part of a larger knowledge base. Linking related documents saves technicians time and shows hiring managers that you understand how documentation systems work in practice.

Save your completed document.
Read through the entire troubleshooting guide from top to bottom. Confirm it has all five sections: title and metadata, Overview, Diagnostic Procedure (5 steps), Escalation Criteria, and Related Documents.

Guide feeling too short or too long?

Your Overview should be 2-3 sentences. Each diagnostic step should be 3-4 sentences (action, expected result, if unsuccessful). The escalation criteria should have 3-4 bullet points. If any section feels significantly shorter than this, add more detail.

help me review my troubleshooting guide for completeness

Your first portfolio document is complete. You now have a troubleshooting guide that any IT team would recognize as professional-quality work. Next up, you will write three ticket responses that cover the full lifecycle of a support ticket.

Write Professional Ticket Responses

Your troubleshooting guide is complete with structured diagnostic steps and clear escalation criteria. Now you move to the writing skill IT support technicians use the most: ticket responses.

IT support teams handle 30-50 tickets per day. Every response you send represents the company to the person reading it.

In this step, get ready to:

Write an initial acknowledgment response for a Wi-Fi issue ticket.
Write a follow-up response requesting more information from the user.
Write a resolution response that closes the ticket professionally.

Write the initial acknowledgment response

A ticket response lifecycle moves from acknowledgment through follow-up to resolution. Your first response sets the tone for the entire interaction.

Here is your scenario for this step. Employee Raj Patel from the Marketing department reports that his laptop cannot connect to the office Wi-Fi since this morning.

Open your Ticket Responses - Wi-Fi Issue document in Google Docs.
At the top of the document, type a scenario header in bold with these details: Scenario: Employee Raj Patel from the Marketing department reports that his laptop cannot connect to the office Wi-Fi since this morning. Ticket #INC-2847.
Below the scenario, add a heading titled Response 1: Initial Acknowledgment.

Write 4-6 sentences for this response. Include these four elements:

A professional greeting using the employee's name (Raj).
Acknowledgment of the specific issue they reported.
A clear statement of what you will do next to investigate.
An estimated timeframe for your next update.

What are discourse markers?

Discourse markers are words and phrases that connect ideas and guide the reader through your text. C1 writers use markers like "In the meantime," "Furthermore," and "Should you require any assistance."

Compare these two versions of the same message:

B2 pattern: I got your ticket. I will look into it. Please wait.
C1 pattern: Thank you for bringing this to our attention. We will begin investigating the issue immediately. In the meantime, should you require any assistance, please do not hesitate to reach out.

The C1 version flows naturally and sounds professional because the discourse markers connect each sentence to the next.

Pro tip: drop the contractions

In formal IT support writing, never use contractions. Write "do not" instead of "don't," "cannot" instead of "can't," and "we will" instead of "we'll." This single change immediately elevates your register from casual to professional.

Write the follow-up response requesting information

In this scenario, you have attempted basic troubleshooting remotely but need more details from Raj to narrow down the root cause. Your follow-up response combines a status update with a polite request for information.

Add a new heading in your document: Response 2: Information Request and Status Update.
Start by updating Raj on what you have already tried so far (for example, verifying the network access point in his area).
Request the exact error message displayed when he attempts to connect.
Ask whether the issue started after any recent changes such as software updates or an office relocation.
Ask whether the laptop can connect to a mobile hotspot.

How do you use polite hedging?

Polite hedging softens your requests while maintaining professionalism. Instead of a direct command like "Tell me the error message," a C1 writer uses modal verbs and polite phrases.

"Could you kindly confirm whether an error message is displayed when attempting to connect?"
"It would be helpful if you could advise whether any recent changes were made to the device."

These patterns show respect for the reader's time and position. Use at least two hedging phrases in your response.

The key challenge in this response is connecting your status update and your information request into one cohesive message. Use cohesive devices to link the two parts so the response reads as a single logical flow.

What does a cohesive response look like?

Notice how this example connects the update and the request: "Following our initial assessment, we have verified that the network access point in your area appears to be functioning correctly. However, to narrow down the root cause, we would appreciate your assistance with the following details."

The word "Following" connects to previous work. "However" signals a pivot from what you found to what you still need. "To narrow down the root cause" explains why you need help. Each cohesive device moves the reader forward.

Write the resolution and closure response

The issue turned out to be a corrupted Wi-Fi driver that you reinstalled remotely. Your final response closes the loop with Raj and leaves him confident that the problem is fully resolved.

Add a heading: Response 3: Resolution and Ticket Closure.
Write 5-8 sentences covering five elements: a summary of the root cause, the action you took to fix it, confirmation that the issue is now resolved, a brief preventive tip, and an invitation to reopen the ticket if the issue recurs.
Use varied sentence lengths throughout the response. Mix shorter confirmation sentences with longer explanatory ones.
Close with a professional sign-off that includes your name and title.

What is less common lexis?

Less common lexis means precise, professional vocabulary that replaces everyday words. At C1 level, you choose words that are more concise and more specific.

Use "rectified" instead of "fixed."
Use "intermittent" instead of "sometimes stops."
Use "subsequent" instead of "next."
Use "pertaining to" instead of "about."

These words are standard in IT support documentation and signal expertise. Try to use at least three of them in your resolution response.

What should a resolution response sound like?

Your resolution response should read like a mini-report. Start with the root cause: "Following a thorough investigation, the issue was identified as a corrupted wireless network driver." Then explain the fix, confirm the result, and offer a preventive tip.

End by inviting the user to reach out again. A strong closing sounds like: "Should you experience any subsequent connectivity issues pertaining to this matter, please do not hesitate to reopen this ticket."

Review all three responses from top to bottom.
Check that you have zero contractions across all three responses.
Verify that each response uses at least one discourse marker and one hedging phrase.

Your three ticket responses cover the full support lifecycle from first contact to resolution. Next up, you write a formal escalation email to a senior network engineer.

Write a Formal Escalation Email

In the previous step, you wrote three ticket responses covering the full support lifecycle. Your portfolio is taking shape with real examples of professional IT communication.

Now you'll write a formal escalation email to a senior network engineer. When a Tier 1 technician exhausts their troubleshooting options, they need to hand the issue off with all the relevant context so the senior engineer can act immediately.

In this step, get ready to:

Set up the email format with header fields and a clear, descriptive subject line.
Write a four-section email body using formal register and C1 writing patterns.
Add a professional closing and review the full email for C1-level language.

Set up the email structure

Escalation emails follow a predictable format that senior engineers expect. Setting up the header fields first helps you frame the entire message before writing the body.

Open your Escalation Email - Network Issue document in Google Docs.
At the top of the document, type To: Ankit Sharma, Senior Network Engineer on the first line.
On the next line, type Cc: Priya Mehta, IT Support Manager.
On the third line, type Subject: Escalation: Recurring Wi-Fi Connectivity Failures - Building 3, Floor 2 [Ticket #INC-2847].
Leave a blank line after the subject, then begin the email body below.

Why does the subject line matter?

Senior engineers receive dozens of emails each day. A vague subject line like "Wi-Fi problem" or "Need help" forces them to open and read the full email just to understand the context.

Your subject line does three things in one glance: it labels this as an escalation, summarizes the issue, and includes the ticket number for tracking. The engineer can prioritize it without opening the email.

Write the email body

Your email body needs four distinct sections. Each section serves a specific purpose in the escalation, moving from context to action.

The first section is your Opening. This is where you state why you are writing and convey the urgency level.

Start with a professional greeting using the engineer's name.
Write 1-2 sentences explaining that you are escalating Ticket #INC-2847 due to recurring Wi-Fi connectivity failures that your Tier 1 troubleshooting has not resolved.
Include an inverted conditional to convey formality and urgency, such as: "Should this issue remain unresolved, it is likely to affect the productivity of the entire Marketing department."

What is an inverted conditional?

An inverted conditional removes "if" and flips the subject and auxiliary verb. Instead of writing "If the issue persists," you write "Should the issue persist." This is a C1-level grammar pattern that signals professional, formal writing.

Other examples include "Were the issue to affect additional departments..." and "Had the troubleshooting resolved the issue, escalation would not have been necessary."

Show me more examples of inverted conditionals in professional emails.

The second section is your Issue Summary. This is a factual description of the problem with no opinions or guesses.

State when the issue first started.
Note how many users are affected.
Describe the specific symptoms users are reporting, such as intermittent disconnections or inability to obtain an IP address.
Explain the business impact clearly, for example: "This has resulted in repeated disruptions to client-facing video conferences conducted by the Marketing team."
Use hedging language to describe possible causes without overstating: "The pattern of failures appears to be localised to Building 3, Floor 2, which may suggest an issue with the access point serving that area."

The third section is Actions Taken. List the troubleshooting steps you already completed and their results so the senior engineer does not repeat your work.

Write 3-4 sentences describing the specific troubleshooting steps you performed.
Use past tense and passive voice where appropriate: "The network adapter was reinstalled, and the device was reconnected to the access point. However, the issue recurred within approximately 30 minutes."
Include the outcome of each step so the engineer can see what has already been eliminated.
Use cohesive devices to connect your sentences: "Following these steps," "Despite the above measures," "Consequently."

Why use passive voice in the Actions Taken section?

Passive voice shifts the focus from who did the work to what was done. "The network adapter was reinstalled" emphasizes the action and its result. "I reinstalled the network adapter" emphasizes you.

In escalation emails, the engineer cares about the facts and outcomes, not about who performed each step. Passive voice keeps the tone objective and professional.

The fourth section is your Requested Action. This is the most important part. Tell the senior engineer exactly what you need from them.

Write a specific, actionable request. Avoid vague phrases like "please look into this."
Use polite hedging to frame your request: "I would appreciate it if you could investigate the access point configuration for AP-B3-F2 and verify whether the DHCP lease pool has been exhausted."
Name the specific equipment, configuration, or system you want them to examine.
If there is a deadline or urgency, state it with a cohesive device: "In light of the ongoing disruptions to client-facing meetings, a timely resolution would be greatly appreciated."

Pro tip: Be specific in your request

Compare "Can you check the network?" with "Could you investigate the access point configuration for AP-B3-F2 and verify whether the DHCP lease pool has been exhausted?" The second version tells the engineer exactly where to start, saving everyone time.

Write the closing and review the full email

The closing is your last impression. It should communicate your availability and willingness to support the senior engineer's investigation.

Write a closing paragraph offering your availability for follow-up: "I am available to provide additional information or assist with on-site diagnostics at your convenience. Please do not hesitate to reach out should you require any further details."
Add a professional sign-off such as "Kind regards" or "Best regards" followed by a comma.
Below the sign-off, type your full name on one line.
On the next line, type your title: IT Support Technician, Tier 1.
Add a contact line with a placeholder email address and phone number.

Now read through the entire email from top to bottom. Check each section against the C1 patterns you have been practicing.

Verify that you used hedging language in at least two places, such as "it appears that" or "this may indicate."
Check that the email contains no contractions ("don't", "can't", "won't") and no slang or casual phrases.
Confirm that you used cohesive devices to connect ideas across sections, such as "consequently," "in light of," or "with regard to."
Look for at least one inverted conditional ("Should the issue...") in your opening section.
Make sure the Actions Taken section uses passive voice to keep the focus on the work, not on you.

What should I see?

Your completed email should be roughly 15-25 lines long, with a clear header (To, Cc, Subject), four body sections (Opening, Issue Summary, Actions Taken, Requested Action), and a professional sign-off with your name and title.

The tone should feel factual and respectful throughout. A senior engineer reading it should be able to understand the problem, see what has been tried, and know exactly what you need from them within 60 seconds.

Your escalation email is complete. You now have three polished documents in your portfolio. Next up, you'll write a Standard Operating Procedure for onboarding a new employee's laptop, the kind of document that keeps an entire IT team consistent.

Write a Standard Operating Procedure (SOP)

Your escalation email is complete. You now have three polished documents covering troubleshooting, ticket responses, and formal escalation.

The final piece of your portfolio is a Standard Operating Procedure for onboarding a new employee's laptop. Without an SOP, two technicians setting up the same laptop model could end up with completely different configurations.

In this step, get ready to:

Write the SOP header with metadata fields and a scope definition.
Create a 6-step onboarding procedure with verification checkpoints.
Build a validation checklist and compliance section.

Write the SOP header and scope

Every SOP starts with a structured header. This header tells anyone reading the document exactly what it covers, who owns it, and when it was last reviewed.

Open your SOP - New Employee Laptop Onboarding document in Google Docs.
Type the SOP title at the top of the document: New Employee Laptop Onboarding Procedure.
Below the title, add each of the following metadata fields on its own line:

SOP ID: SOP-ONB-001
Version: 1.0
Effective Date: followed by today's date.
Owner: IT Support Team Lead
Next Review Date: followed by the date 6 months from today.

Why does an SOP need all these fields?

The SOP ID lets teams reference documents quickly in tickets and emails. The version number and review date ensure outdated procedures get flagged and updated. In real IT teams, SOPs without review dates quietly become obsolete and cause inconsistencies.

Now add two sections below the header: Purpose and Scope.

Add a heading called Purpose.
Write 2-3 sentences explaining why this SOP exists. Focus on what problem it solves: ensuring every new employee laptop is configured consistently and securely.
Add a second heading called Scope.
Write 2-3 sentences describing who this SOP applies to (Tier 1 support technicians) and what it covers (the full laptop onboarding process from hardware receipt to employee handover).

In your Scope section, use the C1 writing pattern called fronting in at least one sentence. Fronting moves an important element to the beginning of a sentence for emphasis.

Pro tip: fronting for emphasis

A normal sentence puts the subject first: "The verification of security configurations is particularly important." A fronted sentence pulls the key phrase forward: "Of particular importance is the verification of security configurations, as any oversight at this stage could compromise the organization's network integrity."

Fronting signals professional-level writing. It draws the reader's eye to exactly the point you want to emphasize.

Review your Purpose and Scope sections. Confirm that your fronted sentence reads naturally and places the most important information at the beginning.

Fronted sentence sounds awkward?

Fronting works best with phrases like "Of particular importance is..." or "Especially critical at this stage is..." Avoid forcing every sentence into this pattern. One well-placed fronted sentence per section is enough.

If your sentence feels unnatural, try starting with "Of particular importance" or "Central to this procedure" and building from there.

Help me rewrite my Scope section with a fronted sentence.

Write the step-by-step procedure

The procedure section is the core of any SOP. Each step must be specific enough that a technician with no prior experience can follow it and produce the same result every time.

Add a heading called Procedure.
Write 6 numbered steps covering the full laptop onboarding process. For each step, write 2-3 sentences that describe the action, the expected outcome, and a verification checkpoint.

Your 6 steps should cover the following tasks in this order:

Receive and verify the hardware. Check the serial number and confirm that the specifications match the original request.
Install the operating system and apply the latest updates.
Join the device to the company domain and configure the user account.
Install required software. Include 4-5 specific examples such as an email client, VPN client, office suite, antivirus, and collaboration tool.
Configure security settings. Enable disk encryption, set the screen lock timeout, and enable the firewall.
Perform handover to the employee. Verify the login works, demonstrate key applications, and obtain a signature on the asset receipt form.

What makes this C1-level writing?

Two things separate B2 procedure writing from C1. First, use formal register throughout. Write "Navigate to the network settings and configure the domain join parameters" instead of "Go to settings and join the domain." Second, vary your sentence structures. Mix short action sentences ("Enable disk encryption.") with longer conditional ones ("Should the device fail to join the domain on the first attempt, verify that the DNS settings point to the correct domain controller.").

Avoid casual language like "just click," "simply do," or "go ahead and." Use formal alternatives like "proceed to," "navigate to," and "verify that."
After each numbered step, include a sentence that states the expected outcome. For example: "Upon completion, the device should appear in the Active Directory organizational unit designated for new employee workstations."

Pro tip: hedging in procedures

Even in procedures, hedging shows professionalism. Write "The device should appear in Active Directory within approximately five minutes" instead of "The device will appear in Active Directory in five minutes." The word "should" acknowledges that real systems sometimes behave unpredictably.

Review all 6 steps in your Procedure section. Confirm that each step has an action, an expected outcome, and a verification point.

Steps feel too short or too vague?

If your steps are only one sentence each, add the expected outcome ("The operating system installation should complete within approximately 30 minutes") and a decision point ("Should the installation fail, verify that the boot order in the BIOS is set to prioritize the USB installer").

Each step should be 2-3 sentences. Fewer than that leaves too much room for interpretation. More than that means you should split the step into two.

Help me expand my SOP procedure steps with expected outcomes and verification points.

Write the validation and compliance sections

A procedure without a validation checklist is incomplete. The checklist gives technicians a final verification step before handing the laptop to the new employee.

Add a heading called Validation Checklist.
Write 8-10 checkbox items that a technician must verify before handover. Use the format: a checkbox symbol or dash followed by a clear, specific verification statement.

Your checklist items should cover verifications like these:

All Windows/macOS updates installed and verified.
Disk encryption enabled and recovery key stored.
VPN connection tested and confirmed functional.
User account configured with correct permissions and group memberships.
Antivirus software installed and definitions updated.
Email client configured and test email sent successfully.
Screen lock timeout set to the company standard (e.g., 5 minutes).
Asset receipt form signed by the employee.

Why a checklist instead of just the procedure?

The procedure tells technicians what to do. The checklist confirms they did it. In real IT teams, a technician might follow all 6 steps but forget to store the disk encryption recovery key. The checklist catches that gap before the laptop reaches the employee.

Add a final heading called Compliance and Review.
Write 2-3 sentences stating that this SOP will be reviewed every 6 months or whenever a significant change occurs in the onboarding process.
Include at least one cleft sentence in this section. A cleft sentence uses "It is..." or "It was..." to spotlight important information.

Pro tip: cleft sentences

A normal sentence: "The IT Support Team Lead must ensure that all technicians are trained on revisions." A cleft sentence: "It is the responsibility of the IT Support Team Lead to ensure that all technicians are trained on any revisions to this procedure."

The cleft version puts a spotlight on exactly who is responsible. This is a C1 pattern that appears frequently in compliance documentation and formal policies.

Review your complete SOP document from top to bottom.
Confirm that the header fields are all filled in.
Check that your Purpose and Scope sections use at least one fronted sentence.
Verify that all 6 procedure steps include an action, an expected outcome, and a verification checkpoint.
Confirm that your Compliance and Review section includes a cleft sentence.

Not sure if your writing is C1 level?

Read your SOP out loud. If it sounds like a casual email to a friend, the register is too informal. If every sentence starts with the same structure ("Install the software. Configure the settings. Enable the firewall."), your sentence variety needs work.

Check for three things: no contractions (write "do not" instead of "don't"), at least two hedging phrases ("should," "may," "it appears that"), and at least one example each of fronting and a cleft sentence.

Review my SOP and suggest improvements for C1-level writing.

Secret mission

Handle a Frustrated Customer Complaint

A frustrated employee has submitted her fourth ticket in two weeks about VPN disconnections during important client calls. Can you write a response that calms her down and presents a concrete action plan? You will need empathy, professionalism, and every C1 writing pattern you have practiced so far.

Before you go

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely in Google Docs, so there are no ongoing costs.

Resources you used:

Google Drive folder: "IT Support Portfolio - [Your Name]".
Google Doc: "Troubleshooting Guide - Wi-Fi Connectivity".
Google Doc: "Ticket Responses - Wi-Fi Issue".
Google Doc: "Escalation Email - Network Issue".
Google Doc: "SOP - New Employee Laptop Onboarding".
Google Doc: "Customer Complaint Response - VPN Issue" (Secret Mission).

Keep everything running

No action needed. Choose this if you plan to refine your documents further or want to reference them during job applications.

Your portfolio folder and all documents remain in Google Drive at no cost.
Consider sharing the folder link with mentors or interviewers when asked about your writing skills.

Pause - I'll come back to this later

Google Docs saves everything automatically, so there is nothing to shut down or pause. Your documents will be exactly where you left them when you come back.

Bookmark your portfolio folder in Google Drive for easy access later.
If you want to keep your Drive tidy, right-click the folder and select Organize to move it to a specific location.

Delete - I don't want to use this again

Remove all project documents and the portfolio folder from your Google Drive.

Open Google Drive and navigate to your "IT Support Portfolio - [Your Name]" folder.
Right-click the folder and select Move to trash. This deletes the folder and all four documents inside it.
To permanently delete, open Trash in the left sidebar, right-click the folder, and select Delete forever.

Mission accomplished

Nice Work!

You have built a complete IT support documentation portfolio that proves two things employers care about: you understand IT support workflows, and you can communicate professionally in English at a C1 level.

Here is what you accomplished:

Created a structured troubleshooting guide with diagnostic steps, escalation criteria, and C1 hedging language that mirrors real Tier 1 knowledge base articles.
Wrote three professional ticket responses covering the full support lifecycle, and a formal escalation email with clear structure and specific action requests.
Authored a Standard Operating Procedure with proper formatting, a step-by-step procedure, and a validation checklist that follows real SOP standards.
Handled a frustrated customer complaint about repeated VPN disconnections using professional empathy, hedging language, and a concrete action plan.

Ready to quiz yourself?