AI Prompts for IT Consultants

Explain a technical issue in plain English for a non-technical client.

Technical issue / root cause: [describe what happened in technical terms]
Who I'm writing to: [role, e.g. office manager, business owner]
Their likely concern: [downtime, data loss, cost, security]
What I need them to do or decide: [approve a fix, do nothing, choose an option]
How technical they are: [not at all / a little]

Write a short explanation that:
- Opens with what it means for their business in one sentence, not the technology
- Explains the cause with a plain analogy, no jargon or acronyms (spell out any term you must use)
- States the impact: what is and is not affected right now
- Gives the recommended next step and any decision you need from them
- Reassures without overpromising

Requirements:
- Under 150 words, calm and warm, not alarmist
- Use only the facts I provided; if something is still unknown, write 'still confirming' rather than guessing
- I will review the technical accuracy before sending, so do not overstate certainty

Write a support ticket response for a client, covering the fix and a plain-language resolution summary.

What the client reported: [the issue]
Client contact: [name]
What I found (root cause): [in your own words]
What I did to resolve it: [the steps you took]
Current status: [resolved / monitoring / needs client action]
Action needed from the client: [restart, change a password, nothing]

Structure:
1. A one-line status up front (Resolved / In progress / Monitoring)
2. What was happening, in plain terms
3. What I did to fix it, summarized (no raw logs or command output)
4. Anything the client needs to do, as a short numbered list
5. A friendly close inviting them to reply if it recurs

Requirements:
- Professional and reassuring, under 180 words
- No jargon unless you define it in the same sentence
- Do not invent causes or steps I did not list; mark any gap as 'to confirm'
- Treat any command, setting, or credential change as a draft for me to verify before I send it

Draft a client-facing incident update for an active or recent outage.

Service affected: [system or app, e.g. email, line-of-business app]
What clients are experiencing: [symptoms]
When it started: [time / date]
Current status: [investigating / identified / monitoring / resolved]
What we know about the cause: [known cause, or 'under investigation']
Estimated resolution: [time, or 'no ETA yet']
Workaround available: [yes, and what / none]

Write:
- A subject line stating the service and status
- A short update (4-6 sentences) covering what's affected, what we're doing, and any workaround
- A clear line on when the next update will come
- A calm, accountable close

Requirements:
- No blame and no speculation on the cause beyond what I provided; if the cause is unconfirmed, say so plainly
- Do not invent an ETA or root cause I did not give you
- Under 150 words, plain language for non-technical readers
- This is a draft I will check against the current status before sending

Write a managed IT services proposal for a prospective client.

Prospect / company: [name, size, industry]
Their current situation and pain: [what's failing now, in their words]
What they want: [outcomes, e.g. less downtime, better security, predictable cost]
Services I'd provide: [helpdesk, monitoring, patching, backup, security, etc.]
Coverage / SLA: [support hours, response times]
Pricing model: [per-user / per-device / flat, and amount or 'to be proposed']
My relevant experience: [1-2 real proof points]

Structure:
1. Their situation restated so they feel understood
2. Objectives, the outcomes this engagement delivers
3. Scope of services, grouped clearly
4. Service levels, response times and coverage hours
5. Onboarding, how the first 30 days work
6. Investment, pricing and what it includes
7. Why us, a short credibility paragraph using only the proof points I gave

Requirements:
- Lead with their outcomes, not a feature list
- Plain business English, no vendor jargon
- Under 800 words
- Do not invent SLAs, prices, client names, or results I did not provide; use [TO CONFIRM] for any gap
- End with one clear next step

Draft a Statement of Work for an IT project.

Client: [name]
Provider: [your name / firm]
Project objective: [one-sentence goal, e.g. migrate email to Microsoft 365]
In-scope work: [list the activities]
Out of scope: [things clients often assume are included but aren't]
Deliverables: [what you hand over]
Milestones / timeline: [phases and dates]
Fees and payment schedule: [amounts and timing]
Client responsibilities: [access, approvals, downtime windows, hardware]
Assumptions the estimate depends on: [environment facts]

Sections:
1. Overview and objective
2. Scope of work (numbered activities)
3. Out of scope (explicit)
4. Deliverables with acceptance criteria
5. Timeline and milestones
6. Fees and payment schedule
7. Client responsibilities and dependencies
8. Assumptions and change-request process

Requirements:
- Precise, unambiguous language; a client should not be able to misread the scope
- Do not invent dates, fees, or environment details I did not give; mark gaps [TO CONFIRM]
- Flag any assumption that, if wrong, would change the price or timeline
- I will review scope and terms before this is signed

Create an itemized quote with scope assumptions for a client request.

Client: [name]
What they asked for: [the request in their words]
Line items I'm quoting: [list each item: hardware, licenses, labor hours, etc., with your prices]
Labor rate: [rate, or 'as listed above']
Assumptions the quote depends on: [e.g. existing cabling works, remote install, no after-hours work]
Valid until: [date]

Produce:
1. A one-paragraph summary of what the quote covers
2. An itemized table: item, quantity, unit price, line total (use only the prices I gave)
3. A subtotal, a tax placeholder [TAX], and a total
4. Assumptions and exclusions, i.e. what could change the price
5. The validity date and the next step to proceed

Requirements:
- Use only the items and prices I provided; never invent quantities, prices, or products
- If a price is missing, insert [PRICE TO CONFIRM] instead of estimating it
- Keep it plain and itemized, easy for a non-technical buyer to approve
- Note that final pricing is subject to my review before it is binding

Write a runbook or standard operating procedure for a recurring IT task, for internal or team use.

Task / procedure: [what it does, e.g. onboard a new user, restore from backup]
System / environment: [platform and tools involved]
Trigger: [when this runbook is used]
Prerequisites: [access, credentials, tools needed before starting]
Steps I follow: [list the steps in order, in your words]
Rollback / if it fails: [your recovery steps]

Format:
1. Purpose and when to use this runbook
2. Prerequisites and required access
3. Step-by-step procedure (numbered, one action per step)
4. Validation, how to confirm each key step worked
5. Rollback and failure handling
6. Escalation contact and notes

Requirements:
- Write steps a competent tech who is new to this client could follow
- Keep only the steps I provided; do not invent commands, config values, or settings
- Mark any command or value that changes per environment as [VERIFY FOR THIS CLIENT]
- Add a note that all commands must be tested in a safe context and reviewed before use in production

Write a client-facing project status report.

Project: [name / objective]
Reporting period: [dates]
Overall status: [on track / at risk / delayed]
Completed this period: [what got done]
In progress: [what's underway]
Upcoming: [next steps]
Blockers or risks: [anything slowing it, and what you need from the client]
Budget / hours status: [if applicable]

Structure:
1. A one-line status header (on track / at risk / delayed) with a sentence of context
2. Accomplishments this period (bulleted)
3. In progress and what's next
4. Risks or blockers, each with the action needed and who owns it
5. Any decision or input needed from the client

Requirements:
- Skimmable in under a minute; a busy client should get the status from the header alone
- Honest about risks without alarm; do not soften a real delay
- Use only the status facts I provided; mark anything unconfirmed as 'to confirm'
- Under 300 words

Create a new-client onboarding checklist for taking over their IT.

Client: [name, size, industry]
Environment I know so far: [devices, servers, cloud services, key apps]
What I'm taking over: [full managed IT / specific systems]
Known priorities or risks: [e.g. no backups, old firewall, prior provider leaving]
Target go-live: [date]

Produce a checklist grouped into phases:
1. Discovery, inventory, access, and documentation to gather
2. Access and security, credentials, MFA, admin handover, offboarding the prior provider
3. Core protections, backup, patching, endpoint security, and monitoring to stand up
4. Documentation, runbooks, asset list, network diagram
5. Client kickoff, contacts, support process, expectations
Write each item as a checkbox line with a short note on why it matters.

Requirements:
- Practical and specific to what I described; do not invent systems the client didn't mention
- Flag items that depend on information I still need as [NEED FROM CLIENT]
- Put backup and security verification before any optimization work
- This is a starting checklist for me to review and tailor, not a final plan

Draft a response to an IT services RFP.

Issuing organization: [name, type]
What they're requesting: [scope from the RFP]
Their stated requirements / evaluation criteria: [list the criteria]
Our relevant services: [what you offer that maps to the RFP]
Our differentiators: [real strengths, e.g. certifications, local presence, experience]
Proof points: [1-3 real, non-confidential examples or results]

Structure the response to mirror their criteria:
1. Executive summary, our understanding of their needs
2. Proposed approach, how we'd deliver, mapped to their requirements
3. Relevant experience, proof points that match their sector or scope
4. Team and coverage, who does the work, hours, response times
5. Assumptions and clarifying questions
6. Summary of why we fit their criteria

Requirements:
- Answer each stated requirement directly; do not leave a criterion unaddressed
- Use only real credentials, certifications, and results I provide; never fabricate a certification, client, or metric
- Mark any figure or claim I haven't supplied as [TO CONFIRM]
- Professional and confident, no hype; under 900 words

Write plain-language security guidance for a client's non-technical staff.

Client / audience: [e.g. small accounting firm, all staff]
Topic: [e.g. phishing, passwords and MFA, safe remote work, ransomware basics]
Their setup: [email platform, whether MFA is in place, key apps]
Recent trigger, if any: [a phishing attempt, an audit, onboarding]
Tone: [friendly reminder / required policy]

Produce:
1. A short intro on why this matters to them, in business terms
2. The 4-6 things they should actually do, as clear do and don't points
3. How to spot this specific threat, with realistic examples
4. What to do if they think something is wrong (who to contact, how fast)
5. A one-line summary they'll remember

Requirements:
- No fear-mongering and no deep jargon; write for people who are not technical
- Keep advice to general best practice; do not present specific security configurations as final
- Use only facts about their setup that I provided; mark assumptions as 'to confirm'
- Note that I will review this against their actual policy and controls before distributing it

Write a post-incident report (root cause analysis) for a client after a resolved incident.

Incident: [what happened]
Systems affected: [list]
Timeline: [key timestamps: detected, escalated, mitigated, resolved]
Root cause: [what actually caused it, in your words]
How it was resolved: [the fix]
Impact: [downtime length, users or data affected]
Preventive actions: [what you'll change so it doesn't recur]

Structure:
1. Summary, what happened and current status in 2-3 sentences
2. Timeline of events (from my timestamps)
3. Root cause, factual, no blame
4. Resolution, what was done
5. Impact, scope and duration
6. Preventive actions, concrete steps with owners
7. Follow-up items with dates

Requirements:
- Factual and accountable; describe the cause without blaming individuals
- Use only the timeline, cause, and impact details I provided; do not speculate or invent timestamps
- Mark anything still open as 'under investigation' rather than guessing
- This is a draft for me to verify for technical accuracy before it goes to the client