Project Documentation Prompt Templates
AI prompt templates for project documentation. Create requirements, specifications, and project plans.
Overview
Project documentation captures decisions, requirements, and context that teams need to execute effectively. Good documentation prevents misunderstandings, reduces rework, and creates institutional knowledge. These prompts help you create documentation that's full enough to be useful but concise enough that people will actually read it.
Best Practices
1
Write for the reader who will use this document, not the process that requires it
2
Lead with the 'why' before the 'what', context helps readers apply information correctly
3
Include explicit decisions and their rationale so future team members understand tradeoffs
4
Keep documents living, outdated documentation is worse than no documentation
5
Use consistent templates so teams know where to find information
Prompt Templates
1. Project Requirements Document
Write a requirements document for [PROJECT_NAME]. Business context: [CONTEXT]. Stakeholders: [STAKEHOLDERS]. Include: problem statement, goals and success metrics, functional requirements, non-functional requirements, constraints, and out of scope items.
Project: Customer self-service portal, Context: Support team overwhelmed with basic account questions (password resets, billing inquiries), handling 500+ tickets/day that could be self-service, Stakeholders: Support team, Engineering, Product, Customers
Project Requirements Document Customer Self-Service Portal --- **Document Info** - Version: 1.0 - Last Updated: October 15, 2024 - Owner: [Product Manager Name] - Status: Draft for Review --- ## 1. Problem Statement Our support team receives 500+ tickets per day, with 60% being basic account management requests (password resets, billing questions, subscription changes). These tickets: - Cost $8 each to handle (fully loaded support cost) - Have an average resolution time of 4 hours - Create frustration for customers who want instant answers - Prevent support team from focusing on complex issues **Annual impact**: ~$875K in support costs for issues customers could resolve themselves. --- ## 2. Goals & Success Metrics | Goal | Metric | Target | Timeline | |------|--------|--------|----------| | Reduce support ticket volume | Tickets/day | 500 → 300 (-40%) | 6 months post-launch | | Improve customer satisfaction | Self-service CSAT | >4.0/5.0 | At launch | | Decrease resolution time | Avg resolution for self-service issues | 4 hrs → <5 min | At launch | | Support team efficiency | Complex tickets per agent | +25% | 6 months post-launch | --- ## 3. Stakeholder Needs | Stakeholder | Primary Need | Key Concerns | |-------------|--------------|---------------| | Customers | Quick resolution without waiting | Security, ease of use | | Support Team | Fewer repetitive tickets | Customers still need escalation path | | Engineering | Clear requirements, reasonable scope | Performance at scale | | Finance | Cost reduction | Implementation cost vs. savings | | Security | Data protection | Authentication, audit logging | --- ## 4. Functional Requirements ### 4.1 Account Management | ID | Requirement | Priority | Notes | |----|-------------|----------|-------| | F1 | Password reset via email | Must Have | Current flow exists; integrate | | F2 | Update email address | Must Have | Requires verification | | F3 | Update payment method | Must Have | PCI compliance required | | F4 | View billing history | Must Have | Last 24 months | | F5 | Download invoices | Should Have | PDF format | | F6 | Update company information | Should Have | For business accounts | ### 4.2 Subscription Management | ID | Requirement | Priority | Notes | |----|-------------|----------|-------| | F7 | View current plan details | Must Have | | | F8 | Upgrade subscription | Must Have | Immediate effect | | F9 | Downgrade subscription | Should Have | End of billing period | | F10 | Cancel subscription | Must Have | Include retention offer | | F11 | View usage vs. plan limits | Should Have | | ### 4.3 Support Integration | ID | Requirement | Priority | Notes | |----|-------------|----------|-------| | F12 | View open support tickets | Must Have | | | F13 | Submit new support ticket | Must Have | With category selection | | F14 | Escalate from self-service | Must Have | "Talk to a human" option | | F15 | Knowledge base search | Should Have | Phase 2 consideration | --- ## 5. Non-Functional Requirements | Category | Requirement | Target | |----------|-------------|--------| | Performance | Page load time | <2 seconds | | Performance | Support 10K concurrent users | 99th percentile | | Availability | Uptime | 99.9% | | Security | Authentication | SSO + MFA support | | Security | Session timeout | 30 minutes inactive | | Security | Audit logging | All account changes logged | | Compliance | PCI DSS | Level 1 for payment handling | | Accessibility | WCAG compliance | Level AA | | Mobile | Responsive design | Full functionality on mobile | --- ## 6. Constraints - **Timeline**: Must launch before Q1 support hiring decision (Dec 15) - **Budget**: $150K maximum (engineering + design) - **Technical**: Must integrate with existing authentication system - **Legal**: Privacy policy update required before launch --- ## 7. Out of Scope The following are explicitly NOT included in this project: - Live chat support (future consideration) - Phone callback scheduling - Multi-language support (English only for v1) - Admin portal for support team (separate project) - API access for customers --- ## 8. Open Questions | Question | Owner | Due Date | |----------|-------|----------| | Can we use existing SSO or need new auth flow? | Engineering | Oct 20 | | What retention offer for cancellations? | Product | Oct 22 | | Legal review of self-service terms? | Legal | Oct 25 | --- ## 9. Approval | Role | Name | Status | Date | |------|------|--------|------| | Product | | Pending | | | Engineering | | Pending | | | Support | | Pending | | | Security | | Pending | |
Starting any significant project that involves multiple stakeholders
- •Prioritize requirements clearly, 'must have' vs. 'nice to have' prevents scope creep
- •Include out-of-scope section to manage expectations proactively
2. Technical Specification
Write a technical specification for [FEATURE/SYSTEM]. Problem: [PROBLEM]. Proposed solution: [SOLUTION_OVERVIEW]. Include: technical approach, system design, data models, API contracts, security considerations, and testing strategy.
Feature: Real-time notification system, Problem: Users miss important updates because we only send email (low open rates), Solution: In-app notifications + push notifications with user preferences
Technical Specification
Real-Time Notification System
---
**Document Info**
- Version: 1.0
- Author: [Engineer Name]
- Reviewers: [Names]
- Status: RFC (Request for Comments)
---
## 1. Overview
### Problem Statement
Users miss important updates (mentions, assignments, deadlines) because our only notification channel is email, which has:
- 23% open rate (industry average)
- Average 4-hour delay before users see notifications
- No way to prioritize urgent vs. routine notifications
### Proposed Solution
Build a real-time notification system supporting:
1. In-app notifications (bell icon, notification center)
2. Push notifications (mobile + desktop)
3. User-configurable preferences per notification type
### Success Metrics
- Notification seen rate: >80% within 1 hour (vs. current 23%)
- User preference adoption: >50% of users customize settings
- System latency: <500ms from event to notification delivery
---
## 2. Technical Approach
### Architecture Overview
```
[Event Source] → [Event Bus] → [Notification Service] → [Delivery Channels]
↓
[User Preferences]
[Notification Store]
```
### Components
1. **Event Bus** (existing Kafka cluster)
- Publish notification events from various services
- Topic: `notifications.events`
2. **Notification Service** (new microservice)
- Consumes events from Kafka
- Applies user preferences and routing logic
- Dispatches to delivery channels
- Stores notification state
3. **Delivery Channels**
- WebSocket connection for in-app (existing infrastructure)
- Firebase Cloud Messaging for mobile push
- Web Push API for desktop browsers
- Email (existing, as fallback)
4. **Notification Store** (PostgreSQL)
- Stores notification history for notification center
- Tracks read/unread state
---
## 3. Data Models
### Notification Event (Kafka message)
```json
{
"event_id": "uuid",
"event_type": "mention | assignment | deadline | comment",
"timestamp": "ISO8601",
"actor_id": "user_uuid",
"recipient_id": "user_uuid",
"resource_type": "task | project | document",
"resource_id": "uuid",
"payload": {
"title": "string",
"body": "string",
"action_url": "string"
}
}
```
### Notification (Database)
```sql
CREATE TABLE notifications (
id UUID PRIMARY KEY,
user_id UUID NOT NULL,
event_type VARCHAR(50) NOT NULL,
title VARCHAR(255) NOT NULL,
body TEXT,
action_url VARCHAR(500),
read_at TIMESTAMP,
created_at TIMESTAMP DEFAULT NOW(),
INDEX idx_user_unread (user_id, read_at)
);
```
### User Preferences (Database)
```sql
CREATE TABLE notification_preferences (
user_id UUID PRIMARY KEY,
preferences JSONB NOT NULL DEFAULT '{}',
updated_at TIMESTAMP DEFAULT NOW()
);
-- Example preferences JSON:
-- {
-- "mention": {"in_app": true, "push": true, "email": false},
-- "assignment": {"in_app": true, "push": true, "email": true},
-- "deadline": {"in_app": true, "push": true, "email": true},
-- "comment": {"in_app": true, "push": false, "email": false}
-- }
```
---
## 4. API Contracts
### GET /api/v1/notifications
Fetch notifications for current user.
**Query Parameters:**
- `limit` (int, default 20, max 100)
- `offset` (int, default 0)
- `unread_only` (boolean, default false)
**Response:**
```json
{
"notifications": [
{
"id": "uuid",
"type": "mention",
"title": "John mentioned you",
"body": "in Project Alpha task",
"action_url": "/projects/123/tasks/456",
"read": false,
"created_at": "2024-10-15T10:30:00Z"
}
],
"unread_count": 5,
"total": 150
}
```
### POST /api/v1/notifications/{id}/read
Mark notification as read.
### POST /api/v1/notifications/read-all
Mark all notifications as read.
### GET /api/v1/notification-preferences
### PUT /api/v1/notification-preferences
Get/update user notification preferences.
---
## 5. Security Considerations
| Risk | Mitigation |
|------|------------|
| Notification content exposure | Encrypt sensitive data in transit and at rest |
| Push token theft | Tokens stored encrypted, rotated on logout |
| Notification spam | Rate limiting per user (max 100/hour) |
| Cross-user notification leak | Strict user_id filtering on all queries |
| WebSocket hijacking | Authenticate WebSocket connections with JWT |
---
## 6. Testing Strategy
### Unit Tests
- Preference application logic
- Notification routing decisions
- Rate limiting logic
### Integration Tests
- End-to-end notification flow (event → delivery)
- Preference updates affecting routing
- Database operations
### Load Tests
- Target: 10,000 notifications/minute
- Verify <500ms latency at load
- WebSocket connection scaling
### Manual QA
- Push notification delivery across iOS, Android, Chrome, Firefox
- Preference UI functionality
- Notification center interactions
---
## 7. Rollout Plan
1. **Phase 1**: In-app notifications only (2 weeks)
- Deploy notification service
- Add notification center UI
- Migrate existing email triggers to event bus
2. **Phase 2**: Push notifications (1 week)
- Integrate Firebase and Web Push
- Add device registration
- Enable push opt-in
3. **Phase 3**: User preferences (1 week)
- Preferences UI
- Preference-based routing
---
## 8. Open Questions
1. Do we batch notifications? (e.g. "5 new comments" vs. 5 separate notifications)
2. How long do we retain notification history?
3. Do we need notification sounds/vibration patterns?
---
## 9. Appendix
### Alternatives Considered
**Alternative 1: Third-party service (OneSignal, Pusher)**
- Pros: Faster implementation, managed infrastructure
- Cons: Cost at scale, data residency concerns, vendor lock-in
- Decision: Build in-house for control and cost
**Alternative 2: Polling instead of WebSocket**
- Pros: Simpler implementation
- Cons: Higher latency, more server load
- Decision: WebSocket for real-time experienceBefore building any significant technical feature or system
- •Include alternatives considered, it shows you evaluated options
- •Define rollout phases to reduce risk and enable early feedback
3. Project Charter
Create a project charter for [PROJECT_NAME]. Sponsor: [SPONSOR]. Objective: [OBJECTIVE]. Include: project purpose, scope, deliverables, milestones, team, risks, and success criteria. Format for executive approval.
Project: Office relocation to new headquarters, Sponsor: CFO, Objective: Move 200 employees to new building with minimal business disruption
Project Charter Headquarters Relocation --- **Project Name**: Headquarters Relocation **Sponsor**: [CFO Name] **Project Manager**: [PM Name] **Charter Date**: October 15, 2024 **Target Completion**: March 31, 2025 --- ## 1. Project Purpose Relocate 200 employees from current office (123 Main St) to new headquarters (456 Innovation Way) while: - Minimizing disruption to daily operations - Improving workspace use and collaboration - Reducing facilities cost by 15% annually ### Business Drivers - Current lease expires June 30, 2025 - New space offers 20% more square footage at lower cost/sqft - Modern facilities support hybrid work model - Consolidates two satellite offices into one location --- ## 2. Scope ### In Scope - Physical move of all furniture, equipment, and materials - IT infrastructure setup (network, phones, security) - Employee communication and change management - New office setup (furniture, signage, amenities) - Decommissioning of current office ### Out of Scope - New furniture purchases (using existing + landlord-provided) - Major IT system upgrades (separate project) - Changes to organizational structure - Satellite office closures (handled separately) --- ## 3. Deliverables | Deliverable | Description | Due Date | |-------------|-------------|----------| | Move plan | Detailed schedule, logistics, assignments | Nov 15, 2024 | | IT infrastructure | Network, phones, security operational | Feb 28, 2025 | | Employee communications | All staff informed and prepared | Ongoing | | Physical move | All employees relocated | Mar 15-16, 2025 | | Office operational | New HQ fully functional | Mar 17, 2025 | | Old office decommissioned | Lease obligations met | Mar 31, 2025 | --- ## 4. Milestones | Milestone | Target Date | Criteria | |-----------|-------------|----------| | Charter approved | Oct 25, 2024 | Sponsor sign-off | | Vendor contracts signed | Nov 15, 2024 | Movers, IT, furniture | | IT infrastructure ready | Feb 28, 2025 | Network tested, phones working | | Move weekend complete | Mar 16, 2025 | All employees have workspace | | Project closed | Apr 15, 2025 | Lessons learned documented | --- ## 5. Budget | Category | Estimate | Notes | |----------|----------|-------| | Moving company | $45,000 | 2-day move, professional packers | | IT setup | $80,000 | Network, cabling, security | | Furniture/setup | $30,000 | Reconfiguration, minor purchases | | Contingency (15%) | $23,000 | | | **Total** | **$178,000** | | Budget authority: Sponsor approval for expenditures >$10,000 --- ## 6. Team & Responsibilities | Role | Name | Responsibility | |------|------|----------------| | Sponsor | [CFO] | Final decisions, budget approval, exec communication | | Project Manager | [PM] | Day-to-day management, vendor coordination | | IT Lead | [Name] | Infrastructure, equipment, tech support | | Facilities Lead | [Name] | Physical space, furniture, building coordination | | HR Lead | [Name] | Employee communication, change management | | Department Liaisons | [TBD] | Coordinate department-specific needs | --- ## 7. Risks | Risk | Probability | Impact | Mitigation | |------|-------------|--------|------------| | IT issues on move day | Medium | High | Pre-move testing, IT on-site during move | | Move delays affect operations | Low | High | Weekend move, Monday contingency | | Employee resistance | Medium | Medium | Early communication, input sessions | | Vendor no-show | Low | High | Backup vendors identified, deposits paid | | Cost overrun | Medium | Medium | 15% contingency, weekly budget reviews | --- ## 8. Success Criteria | Criteria | Target | Measurement | |----------|--------|-------------| | Business disruption | <4 hours lost productivity | Employee survey | | Employee satisfaction | >80% positive feedback | Post-move survey | | Budget | Within approved amount | Final accounting | | Timeline | Complete by Mar 31 | Project schedule | | IT systems | 100% operational by Mar 17 | Systems checklist | --- ## 9. Constraints & Assumptions **Constraints:** - Must complete before current lease expires (June 30) - Cannot disrupt Q1 business-critical activities - Weekend move required to minimize impact **Assumptions:** - New building will be ready for occupancy by Feb 1 - Existing furniture is compatible with new space - All employees will work from new location (no remote-only exceptions) --- ## 10. Approval This charter authorizes the project to proceed with the scope, budget, and timeline defined above. | Role | Name | Signature | Date | |------|------|-----------|------| | Sponsor | [CFO] | __________ | ______ | | Project Manager | [PM] | __________ | ______ | | IT Director | [Name] | __________ | ______ | | HR Director | [Name] | __________ | ______ |
Formal project initiation requiring executive approval and budget authorization
- •Get explicit approval signatures, verbal agreement isn't enough for significant projects
- •Include assumptions so stakeholders can flag if any are invalid
4. Post-Project Review Document
Write a post-project review for [PROJECT_NAME] completed on [DATE]. Include: project summary, what went well, what didn't go well, lessons learned, and recommendations for future projects. Be honest about failures, that's where learning happens.
Project: Website redesign, Date: October 2024, Context: launched 3 weeks late, over budget by 20%, but user feedback has been very positive
Post-Project Review Website Redesign --- **Project**: Website Redesign **Completion Date**: October 15, 2024 **Original Target**: September 25, 2024 **Prepared By**: [PM Name] **Review Date**: October 22, 2024 --- ## 1. Project Summary ### Objectives - Modernize website design (achieved) - Improve mobile experience (achieved) - Increase conversion rate (pending, need 30 days of data) - Launch by Sept 25 (missed, launched Oct 15) ### Final Metrics | Metric | Target | Actual | Status | |--------|--------|--------|--------| | Launch date | Sept 25 | Oct 15 | 3 weeks late | | Budget | $75,000 | $90,000 | 20% over | | User satisfaction | 4.0/5.0 | 4.6/5.0 | Exceeded | | Mobile bounce rate | <50% | 38% | Exceeded | | Conversion rate | +15% | TBD | Measuring | --- ## 2. What Went Well ### Design Quality - Final design exceeded expectations, user feedback overwhelmingly positive - Design team collaboration with marketing was smooth - Prototyping phase caught UX issues before development ### Technical Execution - New CMS implementation went smoothly - Site performance (page speed) 40% better than target - Zero critical bugs at launch ### Stakeholder Management - Weekly demos kept stakeholders aligned - No last-minute scope surprises from leadership - Marketing team prepared launch materials on time --- ## 3. What Didn't Go Well ### Scope Creep (Root cause of delay and budget overrun) - Added e-commerce functionality mid-project (+$15K, +2 weeks) - Three rounds of design revisions instead of planned two (+1 week) - Integration with new CRM wasn't in original scope (+$5K) ### Resource Constraints - Lead developer out sick for 1 week at critical phase - No backup developer trained on the project - Design team pulled to another project for 4 days ### Communication Gaps - Engineering and design had different understandings of mobile requirements - Discovered late that legal review was required for new privacy policy --- ## 4. Lessons Learned ### Process Improvements | Lesson | Evidence | Recommendation | |--------|----------|----------------| | Scope changes need formal approval | Mid-project additions caused overrun | Implement change control board for projects >$50K | | Single points of failure are risky | Developer illness caused delays | Cross-train on critical projects | | Legal review takes time | 1-week delay for privacy policy | Include legal in kickoff for customer-facing projects | | Design iterations need limits | 3 rounds vs. 2 planned | Define revision limits in SOW | ### Team Feedback "We should have pushed back harder on the e-commerce addition.", Tech Lead "The prototyping phase saved us from bigger problems later.", Design Lead "Wish we'd known about the CRM integration earlier.", Developer --- ## 5. Recommendations for Future Projects ### Immediate Actions 1. **Create project change request template**, Formal process for scope additions 2. **Add legal review to project kickoff checklist**, Don't discover requirements late 3. **Document cross-training requirement**, No single points of failure on critical path ### Process Changes 4. **Buffer for unknowns**, Add 15% schedule buffer for projects with new technology 5. **Design revision cap**, Contractually limit design iterations; additional rounds require approval 6. **Integration inventory**, Early discovery of all system integrations ### For Next Website Project 7. **Reuse component library**, This project created reusable components; maintain them 8. **Keep vendor relationship**, Design agency performed well; preferred vendor for future --- ## 6. Stakeholder Acknowledgment This review has been shared with: - [x] Project Sponsor - [x] Project Team - [x] PMO for lessons learned database - [x] Department heads for awareness --- ## 7. Appendix ### Timeline Comparison [Include Gantt chart showing planned vs. actual] ### Budget Breakdown [Include detailed budget variance analysis] ### User Feedback Highlights [Include sample quotes from user testing and post-launch feedback]
After completing any significant project, especially projects that had challenges
- •Conduct the review while memories are fresh, within 2 weeks of completion
- •Failures are more valuable than successes for learning, don't sanitize them
5. Decision Log Entry
Document a project decision for [DECISION_TOPIC]. Options considered: [OPTIONS]. Decision made: [DECISION]. Include: context, alternatives evaluated, rationale, implications, and who made the decision.
Decision Topic: Which payment processor to use, Options: Stripe, Braintree, Adyen, Decision: Stripe
Decision Log Entry --- **Decision ID**: DEC-2024-047 **Date**: October 15, 2024 **Project**: E-commerce Platform **Decision Maker**: [Tech Lead] with [Product Manager] approval **Status**: Final --- ## Decision Topic Select a payment processor for the new e-commerce platform. ## Context We're building a new e-commerce platform launching in Q1 2025. We need a payment processor that: - Supports credit cards, Apple Pay, Google Pay - Handles subscriptions and one-time payments - Works in US, Canada, and UK (our launch markets) - Integrates with our React frontend and Node.js backend - Scales to projected volume (10,000 transactions/month at launch) --- ## Options Considered ### Option A: Stripe | Factor | Assessment | |--------|------------| | Features | Full featured: cards, wallets, subscriptions, invoicing | | Pricing | 2.9% + $0.30 per transaction | | Developer experience | Excellent documentation, SDKs, sandbox | | Geographic coverage | All target markets supported | | Integration effort | Estimated 2 weeks | ### Option B: Braintree (PayPal) | Factor | Assessment | |--------|------------| | Features | Full featured, includes PayPal natively | | Pricing | 2.59% + $0.49 per transaction | | Developer experience | Good, but documentation less full | | Geographic coverage | All target markets supported | | Integration effort | Estimated 3 weeks | ### Option C: Adyen | Factor | Assessment | |--------|------------| | Features | Enterprise-grade, excellent for high volume | | Pricing | Interchange++ (lower at scale, higher initially) | | Developer experience | Steeper learning curve | | Geographic coverage | Excellent global coverage | | Integration effort | Estimated 4 weeks | --- ## Decision **Selected: Stripe** --- ## Rationale 1. **Developer velocity** (Primary factor) - Stripe's developer experience is best-in-class - 2-week integration estimate vs. 3-4 weeks for alternatives - Our team has prior Stripe experience 2. **Feature completeness for our needs** - All required payment methods supported - Subscriptions handled natively (important for membership tier) - Excellent fraud detection included 3. **Acceptable pricing** - Slightly higher than Braintree per transaction - At our volume (10K transactions/month), difference is ~$400/month - Time savings from faster integration > cost difference 4. **Why not Braintree** - PayPal integration isn't a priority for us - Less full documentation - Longer integration timeline 5. **Why not Adyen** - Overkill for our initial volume - Steeper learning curve doesn't fit timeline - Would reconsider at 100K+ transactions/month --- ## Implications ### Technical - Frontend: Use Stripe Elements for PCI compliance - Backend: Integrate Stripe SDK, set up webhooks - Infrastructure: No additional requirements ### Financial - Processing cost: ~$3,200/month at launch volume - No setup fees - Monthly fee: $0 (pay-as-you-go) ### Operational - Finance team needs Stripe dashboard access - Reconciliation process to be documented ### Reversibility - Medium difficulty to switch later - Would require frontend and backend changes - Customer payment methods would need re-collection --- ## Risks Accepted 1. Stripe pricing may be less competitive at high volume - Mitigation: Revisit at 50K transactions/month 2. Single vendor dependency - Mitigation: Abstract payment layer to ease future switching --- ## Approval - [x] Tech Lead: Approved (technical fit) - [x] Product Manager: Approved (feature requirements) - [x] Finance: Acknowledged (cost implications) - [x] Security: Approved (PCI compliance approach)
Any significant decision that future team members might question or need to revisit
- •Document decisions when you make them, not later when you've forgotten the context
- •Include 'reversibility', it helps future teams know if they can change this
Common Mistakes to Avoid
•
Writing documentation that satisfies a process requirement but doesn't actually help anyone
•
Not keeping documentation updated, outdated docs cause more confusion than no docs
•
Burying important information in lengthy documents, lead with what readers need most
Frequently Asked Questions
Project documentation captures decisions, requirements, and context that teams need to execute effectively. Good documentation prevents misunderstandings, reduces rework, and creates institutional knowledge. These prompts help you create documentation that's full enough to be useful but concise enough that people will actually read it.
Related Templates
Sales Email Prompt Templates
AI prompt templates for sales emails. Create compelling cold outreach, follow-ups, and closing messages.
Business Proposal Prompt Templates
AI prompt templates for business proposals. Create persuasive proposals that win clients and projects.
Business Report Prompt Templates
AI prompt templates for business reports. Create clear, actionable reports for stakeholders.
Have your own prompt to optimize?