Volume 4 · Chapter 4 — Service Delivery Organization, 16×5 Operations & Enterprise Support Model
How Kamiti Runs the Service
The operational blueprint behind every engagement — org structure, the 16×5 support model, ticket lifecycle, incident severity and SLAs, escalation paths, communication standards, governance cadence, and the KPIs that prove it is working.
Executive Summary
The service delivery vision
Technology alone does not deliver reliable services. Successful managed services depend on the combination of skilled people, standardized processes, enterprise tooling, governance, automation, and continuous improvement.
Kamiti Labs’ operating model is built around ITIL, SRE, and DevOps principles to provide predictable, measurable, and scalable operations.
Service delivery objectives
- Maintain high application availability.
- Detect and resolve incidents rapidly.
- Minimize business disruption.
- Provide consistent communication.
- Deliver measurable SLA performance.
- Improve reliability through continuous optimization.
- Build long-term operational maturity.
Enterprise operating model
- 1
Business users
- 2
Service desk
- 3
L1 operations
- 4
L2 technical specialists
- 5
L3 platform / application experts
- 6
OEM / vendor support
Standards & Best Practices
The 16×5 support model
A 16×5 support model provides operational coverage for 16 hours per day, Monday through Friday, typically aligned with the customer’s business hours and time zone. For a Singapore-based customer, shift timings are agreed during contract finalization — many organizations adopt an early shift and a late shift to cover the full business day.
Sample shift schedule
| Shift | Time | Team |
|---|---|---|
| Shift A | Morning | L1 + L2 |
| Shift B | Afternoon / evening | L1 + L2 |
| On-call | Outside support window | L3 / Duty Manager (if contracted) |
Coverage during support hours
- Incident monitoring
- Alert triage
- Ticket management
- Dashboard monitoring
- Service restoration
- Stakeholder communication
- Routine operational activities
Architecture
Organization structure
Every engagement is staffed against the same recommended structure, so customers know exactly who owns what from day one.
Key roles
Service Delivery Manager (SDM)
- Customer relationship
- SLA management
- Escalation ownership
- Governance meetings
- Service reporting
- Continuous improvement
Technical Account Manager (TAM)
- Technical roadmap
- Architecture guidance
- Capacity planning
- Customer technical advisor
- Major incident reviews
SRE Lead
- Reliability engineering
- SLO compliance
- Monitoring strategy
- Automation roadmap
- Operational excellence
L1 Operations Engineers
- Monitor alerts
- Create incidents
- First-level diagnosis
- Execute SOPs
- Escalate as required
- Update ticket status
L2 Support Engineers
- Technical troubleshooting
- Log analysis
- Configuration review
- Deployment validation
- Root cause assistance
- Coordination with application teams
L3 Specialists
- Platform engineering
- Code-level troubleshooting (where applicable)
- Vendor coordination
- Permanent fixes
- Architecture improvements
Database Administrator (DBA)
- Database health
- Backup validation
- Performance tuning
- Replication monitoring
- Capacity planning
Cloud & Platform Engineer
- Cloud infrastructure
- Kubernetes
- Networking
- Storage
- Infrastructure automation
KPI & SLA Examples
Responsibility matrix
Every operational function has one clearly accountable tier — this is what gets audited when a customer asks “who is actually responsible for this?”
| Function | L1 | L2 | L3 | SDM |
|---|---|---|---|---|
| Alert monitoring | ✓ | |||
| Ticket creation | ✓ | |||
| Incident investigation | ✓ | ✓ | ||
| Vendor coordination | ✓ | |||
| SLA reporting | ✓ | |||
| Executive communication | ✓ | |||
| Capacity planning | ✓ | ✓ | ||
| RCA preparation | ✓ | ✓ | ||
| Automation | ✓ | ✓ |
Implementation Guidance
Ticket lifecycle
Every alert follows the same consistent workflow, so nothing is resolved — or escalated — informally.
- 1
Alert generated
- 2
Incident created
- 3
L1 investigation
If resolved, close and update the knowledge base. If not, escalate to L2.
- 4
L2 technical analysis
If resolved, close and update the knowledge base. If not, escalate to L3.
- 5
L3 / vendor & OEM support
Engaged for platform-level or vendor-owned issues.
- 6
Service restored
- 7
RCA & knowledge update
Common Challenges
Incident severity model
Every incident is classified on arrival — severity determines how fast the organization moves, not how the engineer feels about it.
P1 — Critical
- Complete production outage
- ERP unavailable
- Dealer portal inaccessible nationwide
- Payment failures affecting all users
Target: immediate acknowledgment, rapid engagement of all required teams, and continuous stakeholder communication until restoration.
P2 — High
- Major feature unavailable
- Performance degradation affecting multiple users
- Database replication issue without immediate outage
P3 — Medium
- Non-critical functionality impacted
- Individual application errors with a workaround
P4 — Low
- Cosmetic UI issues
- Minor reports
- Documentation updates
- Enhancement requests
KPI & SLA Examples
SLA framework
Final SLA values are always agreed with the customer and documented in the contract — the table below is the typical starting point for negotiation.
| KPI | Example target |
|---|---|
| Service availability | Customer-defined (e.g. ≥99.9%) |
| P1 acknowledgement | ≤15 minutes |
| P2 acknowledgement | ≤30 minutes |
| P3 acknowledgement | ≤1 hour |
| Monthly SLA report | 100% delivery |
| Dashboard availability | 99.9% |
Deliverables
Escalation matrix
Two escalation paths run in parallel — one technical, one managerial — so a stuck incident always has somewhere to go.
Technical escalation
- 1
L1 engineer
- 2
L2 engineer
- 3
SRE Lead
- 4
Technical Account Manager
- 5
Vendor / OEM
Management escalation
- 1
Operations Manager
- 2
Service Delivery Manager
- 3
Customer IT Manager
- 4
Customer CIO
Standards & Best Practices
Communication standards
Communication is timely, accurate, business-focused, action-oriented, and consistent — every message type follows the same template, regardless of who is writing it.
Incident notification
- Incident ID
- Affected service
- Business impact
- Current status
- Next update time
- Assigned team
Major incident update
- Current situation
- Investigation summary
- Workaround (if any)
- Estimated next update
- Customer actions (if required)
Service restoration notice
- Service restored
- Validation complete
- Monitoring active
- RCA to follow
Implementation Guidance
Daily operations checklist
Every shift runs through the same three-part checklist — nothing is left to memory.
Morning
- Review previous shift handover
- Verify monitoring platform health
- Check backup status
- Review overnight alerts
- Validate critical dashboards
During shift
- Monitor alerts
- Investigate incidents
- Update tickets
- Execute runbooks
- Coordinate with customer teams
End of shift
- Complete shift report
- Handover unresolved incidents
- Update knowledge base
- Confirm customer communications
Kamiti Recommendations
Governance meetings
Governance runs on a fixed cadence, from daily stand-ups to quarterly strategic reviews, so nothing important only gets discussed when something has already broken.
Daily — Operations stand-up
- Open incidents
- Major risks
- Planned changes
- Resource availability
Weekly — Service review
- Incident trends
- SLA compliance
- Capacity concerns
- Improvement actions
Monthly — Executive governance
- SLA performance
- Availability
- RCA summary
- Automation progress
- Customer satisfaction
- CSI initiatives
Quarterly — Strategic review
- Roadmap
- Architecture improvements
- Technology upgrades
- Cost optimization
- Innovation proposals
KPI & SLA Examples
Key performance indicators
Kamiti measures both operational execution and the business outcomes it exists to protect.
Operational KPIs
- SLA achievement
- MTTD
- MTTR
- Ticket aging
- First contact resolution
- Alert noise reduction
Reliability KPIs
- Availability
- SLO compliance
- Error budget consumption
- Change success rate
Customer KPIs
- Customer satisfaction
- Executive report timeliness
- Governance attendance
- Action item closure
Kamiti Recommendations
Continuous Service Improvement (CSI)
Continuous improvement never stops after go-live. Every improvement is tracked through a CSI register with an owner, priority, target date, and measurable benefit.
- Runbook optimization
- Alert tuning
- Dashboard refinement
- Automation opportunities
- Capacity optimization
- Security enhancements
- Cost optimization
- Technical debt reduction
Deliverables
What Volume 4 produces
Organization
- Service organization chart
- Contact directory
- RACI matrix
- Escalation matrix
Operations
- Shift schedule
- Ticket workflow
- Incident classification
- Communication templates
Governance
- Meeting calendar
- Reporting calendar
- SLA catalogue
- KPI catalogue
- CSI register
Consultant Tips
Consultant’s note
Discipline is the differentiator
Enterprise customers evaluate managed service providers not only on technical skills but also on operational discipline. A well-defined organization, clear responsibilities, structured governance, measurable KPIs, and consistent communication often distinguish successful providers from competitors.
Demonstrating a mature operating model builds confidence that Kamiti Labs can manage critical business applications reliably over the long term.