1. Service Scope
Web Services provides comprehensive support for UNA.edu's digital presence through content management, technical maintenance, and strategic guidance. This document defines what falls within and outside our service boundaries to ensure clear expectations and efficient resource allocation.
Core Services Provided
- Content publishing: Adding, editing, and removing content within approved templates
- Technical support: Troubleshooting website issues, broken links, and functionality problems
- Template management: Maintaining and updating standard page templates
- Accessibility compliance: Ensuring WCAG 2.1 Level AA standards across all content
- Platform maintenance: WordPress core updates, security patches, and performance optimization
- Training and documentation: Providing resources and guidance for content contributors
- Analytics and reporting: Monthly site performance reports and data-driven recommendations
- Standards enforcement: Monitoring and maintaining compliance with digital standards
Services Requiring Approval
The following services require prior approval from appropriate leadership (see Customization Requests):
- Custom page layouts outside standard templates
- Third-party integrations and external tools
- Custom functionality or interactive components
- Alternative navigation structures
- Non-standard design treatments
Out of Scope Services
The following services are not provided by Web Services:
- Content creation: Writing copy, creating graphics, or producing media (content creation is the responsibility of requesting departments)
- External platforms: Management of social media, third-party websites, or non-UNA.edu domains
- Custom development: Building unique applications or features without proper approval and resource allocation
- 24/7 emergency support: Outside business hours except for critical site outages
- Individual department IT support: Computer troubleshooting, software installation, or network issues (contact IT Services)
- Marketing strategy: Campaign planning, market research, or advertising placement (contact Enrollment Marketing)
2. Service Level Agreements (SLAs)
The following SLAs define expected response and resolution times for web-related requests. SLAs are measured during business hours (Monday-Friday, 8:00 AM - 5:00 PM CST, excluding university holidays).
Request Priority Definitions
Critical (Priority 1)
Definition: Complete site outage, security breach, or issue preventing access to essential services affecting majority of users.
Examples: Una.edu completely down, admissions application not accessible, security vulnerability exposed
- Response time: 1 hour
- Resolution target: 4 hours
- Communication frequency: Every 2 hours until resolved
High (Priority 2)
Definition: Significant functionality issue affecting specific department or user group, broken critical page elements, or time-sensitive content needs.
Examples: Department homepage showing errors, broken form submissions, urgent event information needed
- Response time: 4 business hours
- Resolution target: 1-2 business days
- Communication frequency: Daily updates
Medium (Priority 3)
Definition: Non-critical content updates, minor functionality issues, or standard maintenance requests.
Examples: Content updates, broken links on secondary pages, image replacements, routine edits
- Response time: 1 business day
- Resolution target: 3-5 business days
- Communication frequency: Update upon completion
Low (Priority 4)
Definition: Enhancement requests, template modifications, new page creation, or non-urgent improvements.
Examples: Requesting new page sections, template enhancements, cosmetic improvements, informational questions
- Response time: 2 business days
- Resolution target: 7-14 business days (or as resources permit)
- Communication frequency: Initial assessment, then update upon completion
SLA Exclusions and Adjustments
SLAs may be adjusted or extended in the following circumstances:
- Incomplete requests: Requests lacking necessary information or materials will be placed on hold until requester provides complete details
- Approval dependencies: Timeline begins after all required approvals are obtained
- Resource constraints: During peak periods (enrollment cycles, university events), lower priority requests may experience delays
- External dependencies: Issues requiring third-party vendor support or outside technical resources
- Complex customizations: Approved custom development projects follow separate project timelines
- Force majeure: Circumstances beyond reasonable control (natural disasters, system-wide outages)
3. Support Boundaries and Escalation
Primary Support Channel
All web-related requests should be submitted through the official Web Services request system:
- Email: web@una.edu
- Request portal: [System link if available]
- Phone (urgent only): [Phone number if applicable]
Escalation Path
If a request is not being addressed according to SLA expectations, follow this escalation path:
- Web Services Manager - Initial escalation point for unresolved issues
- EMDC Director - For unresolved departmental concerns or policy questions
- University leadership - For strategic or cross-divisional issues requiring senior decision-making
After-Hours Emergency Protocol
For critical issues outside business hours (Priority 1 only):
- Contact University Communications emergency line
- Issues will be assessed and escalated if they meet critical criteria
- Non-critical requests will be addressed during next business day
4. Request Best Practices
Submitting Effective Requests
To ensure efficient processing and meet SLA targets, please include:
- Clear description: Specific details about what needs to be done
- Page URLs: Direct links to pages requiring updates
- Required approvals: Documentation if customization or integration is requested
- Deadline context: Explanation if time-sensitive (event dates, compliance requirements)
- Supporting materials: Images, copy, documents, or examples attached to request
- Contact information: Best method to reach you for questions or clarification
Batching Requests
For better efficiency, consider batching multiple related updates into a single request when possible. This reduces overhead and often results in faster overall completion.