| name | maintenance-proposal |
| description | Create post-delivery maintenance and support contract proposals for IT systems. Use this skill when the user asks to "create a maintenance proposal", "保守運用提案", "support contract proposal", "SLA definition", "SLA定義", "maintenance plan", "保守計画", "運用設計", "operations proposal", "post-go-live support", "create a support plan", or needs to propose ongoing maintenance, monitoring, and support services after project delivery. Also trigger for "保守見積", "年間保守", "ヘルプデスク提案", "incident management plan", and any request to define post-delivery support structures, SLAs, or maintenance pricing.
|
| metadata | {"version":"0.1.0"} |
Maintenance & Support Proposal (保守運用提案)
Create comprehensive post-delivery maintenance and support contract proposals with SLA definitions, support tier structures, and pricing models.
Why This Matters
In Japanese SIer business, maintenance contracts (保守契約) are the annuity revenue that sustains the company between projects. A well-structured maintenance proposal secures 15-20% of the original project value annually, often for 3-5 years. More importantly, it ensures the system you built continues to work properly — protecting both your client and your reputation.
Workflow
Step 0: Connect to NotebookLM
If the original RFP or project documentation is in NotebookLM, query for maintenance-relevant information:
notebooklm ask "Does the RFP or contract include requirements for post-delivery maintenance, support, or warranty period?" --json
notebooklm ask "What are the system's availability requirements, RPO, and RTO targets?" --json
notebooklm ask "What is the technology stack, infrastructure, and deployment architecture?" --json
notebooklm ask "What are the business-critical functions and peak usage periods?" --json
notebooklm ask "Are there existing maintenance contracts or support structures being replaced?" --json
notebooklm ask "What regulatory or compliance requirements affect system operations?" --json
Step 1: Gather Maintenance Requirements
Ask the user:
- System overview: What was delivered, technology stack, user base
- Criticality: Business impact if the system goes down
- Support hours: Business hours only (9-18 JST) or 24/7/365
- Current state: Still in warranty? Existing support in place?
- Client expectations: Response time, resolution time, reporting
- Budget indication: Client's ballpark for annual maintenance
- Contract duration: 1 year, 3 years, 5 years
Step 2: Service Catalog (サービスカタログ)
Define the maintenance service offerings:
Category 1: Corrective Maintenance (障害対応)
- Incident reception and triage
- Root cause analysis
- Bug fixes and emergency patches
- Workaround implementation
- Post-incident reporting
Category 2: Adaptive Maintenance (環境適応)
- OS and middleware version upgrades
- Security patch application
- Browser compatibility updates
- Third-party library updates
- Infrastructure scaling adjustments
Category 3: Preventive Maintenance (予防保守)
- System health monitoring
- Performance trend analysis
- Capacity planning
- Security vulnerability scanning
- Backup verification and DR testing
Category 4: Perfective Maintenance (改善保守)
- Minor enhancements (within included hours)
- Performance optimization
- UX improvements
- Report additions/modifications
- Configuration changes
Category 5: Operations Support (運用支援)
- Batch job monitoring
- Data maintenance (master data updates)
- User account management
- Regular reporting
- Helpdesk (問い合わせ対応)
Step 3: SLA Definition (SLA定義)
Incident Severity Classification:
| Severity | Japanese | Definition | Example |
|---|
| S1 Critical | 重大障害 | System down, all users affected, no workaround | Production server crash, data corruption |
| S2 Major | 重要障害 | Major function unavailable, significant users affected | Payment processing failure, login issues |
| S3 Moderate | 中度障害 | Function degraded, workaround available | Slow performance, report formatting error |
| S4 Minor | 軽微障害 | Cosmetic or low-impact issue | UI alignment, typo in message |
SLA Targets by Support Tier:
| SLA Metric | S1 | S2 | S3 | S4 |
|---|
| Standard (9-18 JST, weekdays): | | | | |
| Response time | 30 min | 1 hour | 4 hours | Next business day |
| Status update frequency | Every 1 hour | Every 2 hours | Daily | On resolution |
| Workaround target | 2 hours | 4 hours | 2 business days | 5 business days |
| Resolution target | 8 hours | 1 business day | 5 business days | 10 business days |
| Premium (24/7/365): | | | | |
| Response time | 15 min | 30 min | 2 hours | Next business day |
| Status update frequency | Every 30 min | Every 1 hour | Every 4 hours | On resolution |
| Workaround target | 1 hour | 2 hours | 1 business day | 3 business days |
| Resolution target | 4 hours | 8 hours | 3 business days | 7 business days |
Availability SLA:
| Tier | Target | Allowed Downtime/Month | Measurement |
|---|
| Standard | 99.5% | ~3.6 hours | Business hours only |
| Enhanced | 99.9% | ~43 minutes | 24/7 |
| Premium | 99.95% | ~22 minutes | 24/7 |
Exclusions: Planned maintenance windows, force majeure, client-caused issues, third-party service outages (outside our control).
Step 4: Support Team Structure
Standard Support Team:
| Role | Allocation | Responsibility |
|---|
| Support Manager (保守責任者) | 0.1-0.2 人月 | Overall governance, escalation point, monthly reporting |
| Application Support Lead | 0.3-0.5 人月 | Incident management, change coordination, knowledge base |
| Application Engineer | 0.5-1.0 人月 | Bug fixes, minor enhancements, investigations |
| Infrastructure Engineer | 0.2-0.3 人月 | Server/network monitoring, patching, capacity management |
| Helpdesk Operator | 0.2-0.5 人月 | Tier 1 support, ticket routing, user communication |
For 24/7 support, add:
- On-call rotation (typically 3-4 engineers for continuous coverage)
- On-call allowance: ¥50,000-100,000/month per person
- After-hours incident response rate: 1.25-1.5x standard rate
Step 5: Pricing Model
Option A: Fixed Monthly Fee (月額定額)
Best for: Stable systems, predictable workload
| Item | Monthly | Annual |
|---|
| Base support fee | ¥X,XXX,XXX | ¥XX,XXX,XXX |
| Included enhancement hours | 20 hours/month | 240 hours/year |
| Additional hours rate | ¥XX,XXX/hour | — |
Option B: Tiered Service Plans
| Feature | Bronze | Silver | Gold |
|---|
| Support hours | 9-18 weekdays | 9-21 weekdays | 24/7/365 |
| Response SLA (S1) | 1 hour | 30 min | 15 min |
| Included hours | 10h/month | 20h/month | 40h/month |
| Proactive monitoring | — | Basic | Full |
| Monthly report | — | ✓ | ✓ |
| Quarterly review | — | — | ✓ |
| DR testing | — | Annual | Semi-annual |
| Monthly fee | ¥XXX,XXX | ¥X,XXX,XXX | ¥X,XXX,XXX |
Option C: Incident-Based (従量制)
Best for: Low-volume, non-critical systems
| Item | Rate |
|---|
| Retainer fee (minimum) | ¥XXX,XXX/month |
| S1 incident | ¥XXX,XXX/incident |
| S2 incident | ¥XXX,XXX/incident |
| S3/S4 incident | ¥XX,XXX/incident |
| Enhancement work | ¥XX,XXX/hour |
Pricing Guidelines:
- Annual maintenance typically 15-20% of original project cost
- 24/7 support adds 40-60% to base support cost
- Multi-year contracts: 5% discount for 3-year, 10% for 5-year commitment
- Payment: Monthly invoicing, 30-day payment terms typical
Step 6: Governance & Reporting
Regular Activities:
| Activity | Frequency | Deliverable |
|---|
| Incident report | Per incident (S1/S2) | 障害報告書 |
| Monthly report | Monthly | 月次保守報告書 |
| SLA achievement report | Monthly | SLA達成状況レポート |
| Service review meeting | Monthly or Quarterly | 保守定例会議事録 |
| System health assessment | Quarterly | システム健全性レポート |
| Annual maintenance plan | Annually | 年間保守計画書 |
Monthly Report Contents:
- Incident summary (件数, severity distribution, resolution times)
- SLA achievement rates vs. targets
- Enhancement work completed (hours used vs. included)
- System availability metrics
- Upcoming planned maintenance
- Risk and improvement recommendations
Step 7: Transition Plan (移行計画)
From Project Team to Maintenance Team:
| Phase | Duration | Activities |
|---|
| Parallel Run | 1-2 months | Project team handles incidents with maintenance team shadowing |
| Gradual Transfer | 1 month | Maintenance team takes lead, project team as backup |
| Full Transfer | — | Maintenance team fully responsible, project team disbanded |
Knowledge Transfer Requirements:
- Architecture and design document walkthrough
- Operations manual (運用手順書) review
- Incident handling procedure training
- Access credential handover
- Monitoring tool training
- Known issues and workaround documentation
Step 8: Output
Generate as .docx (using the docx skill):
- Maintenance proposal document (保守提案書)
- SLA agreement draft (SLA合意書)
- Service catalog (サービスカタログ)
- Transition plan (移行計画書)
Key Principles
- Maintenance is not an afterthought: Propose it during the project, not after go-live
- SLAs must be measurable: If you can't measure it, don't promise it
- Right-size the support: Over-provisioning erodes margins; under-provisioning destroys reputation
- Knowledge retention: The biggest risk is losing the people who built the system
- Proactive > reactive: Finding problems before clients report them is what separates good support from great
- Annual review: Adjust SLAs and pricing annually based on actual incident volumes
For SLA templates and pricing calculation worksheets, read references/maintenance-templates.md.
