Service Level Agreement

1. SLA Overview

This Service Level Agreement ("SLA") defines the availability commitments, performance targets, incident response expectations, and remedies that Momo Pulse provides to its customers (Tenants). This SLA is part of and governed by our Terms & Conditions.

We understand that communications infrastructure is business-critical. Missed calls, undelivered messages, and platform downtime directly impact your operations, customer satisfaction, and revenue. This SLA formalizes our commitment to reliability and outlines the process for remediation when we fall short.

2. Definitions

• "Uptime": The percentage of time the Momo Pulse platform is operational and accessible during a given calendar month, excluding Scheduled Maintenance windows.
• "Downtime": Any period during which the platform's core services are unavailable or materially degraded, as measured by our monitoring systems. Downtime begins when the issue is detected or reported (whichever is earlier) and ends when the service is restored.
• "Scheduled Maintenance": Planned maintenance activities communicated in advance that may temporarily affect service availability.
• "Incident": An unplanned event that causes service disruption or degradation beyond acceptable performance thresholds.
• "Service Credit": A credit applied to your Momo Pulse wallet as compensation for SLA breaches, calculated as a percentage of charges incurred during the affected period.
• "Core Services": The primary platform capabilities including the web dashboard, API endpoints, voice call handling, SMS delivery, WhatsApp messaging, AI agent execution, and IVR flow processing.
• "Measurement Period": A single calendar month (00:00 UTC on the first day through 23:59:59 UTC on the last day).

3. Uptime Commitment

Momo Pulse commits to maintaining the following monthly uptime targets for its core services:

• Standard Tier: Applies to all Tenants by default. Provides a 99.5% monthly uptime guarantee for core platform services.
• Enterprise Tier: Available to Tenants with a custom enterprise agreement. Provides a 99.9% monthly uptime guarantee with enhanced support and faster incident response times.

Uptime Calculation

Monthly uptime is calculated using the following formula:

Uptime % = ((Total Minutes in Month − Downtime Minutes − Scheduled Maintenance Minutes) / (Total Minutes in Month − Scheduled Maintenance Minutes)) × 100

Scheduled Maintenance windows are excluded from the uptime calculation. Only unplanned downtime counts against the SLA target.

4. Service Availability Targets

In addition to the overall platform uptime commitment, we maintain availability targets for individual service components:

Service components that depend on third-party providers (WhatsApp via Meta, AI models via external providers) carry lower availability targets to account for dependencies outside our direct control. We actively monitor these dependencies and work with providers to maintain the highest possible availability.

5. Scheduled Maintenance

To ensure platform reliability, security, and performance, we perform scheduled maintenance as needed:

Maintenance Windows

• Preferred Window: Scheduled maintenance is typically performed during low-traffic hours: Tuesday and Thursday, 02:00 – 06:00 EAT (East Africa Time, UTC+3).
• Duration: Routine maintenance windows typically last no longer than 2 hours. Extended maintenance (over 2 hours) is rare and scheduled only when necessary for major infrastructure upgrades.
• Frequency: We aim to limit scheduled maintenance to no more than 4 hours per month across all maintenance windows.

Advance Notice

• Routine Maintenance: At least 72 hours (3 days) advance notice via email to the primary contact on each Tenant account and a banner on the platform dashboard.
• Emergency Maintenance: In rare cases where an urgent security patch or critical fix is required, we may perform emergency maintenance with less than 72 hours notice. We will provide as much advance notice as circumstances allow and communicate the urgency and scope of the work.

Impact Minimization

• We use rolling deployments and zero-downtime deployment strategies where technically feasible to minimize service interruption during maintenance.
• Database migrations are designed to be backward-compatible to avoid requiring full service shutdowns.
• If maintenance is expected to cause a full service interruption, we will clearly state the expected downtime duration and affected services in the maintenance notification.

6. Incident Response Times

When an incident occurs, our response time depends on the severity level:

• Response Time: The time from when the incident is detected or reported to when a member of our engineering or operations team begins actively investigating.
• Resolution Target: The target time to restore service to normal operation. Resolution targets are best-effort goals, not guaranteed timelines. Complex incidents may require longer resolution, in which case regular status updates will be provided.

7. Incident Communication

Transparent and timely communication during incidents is essential. Our incident communication protocol includes:

During an Active Incident

• Initial Notification: Within the response time for the incident severity, we will publish an initial status update acknowledging the issue and providing preliminary details.
• Regular Updates: For P1 and P2 incidents, status updates are published every 30 minutes until the issue is resolved. For P3 incidents, updates are published hourly.
• Resolution Notification: When the incident is resolved, we will publish a resolution notification confirming service restoration and a brief description of the fix applied.

Post-Incident

• Root Cause Analysis (RCA): For P1 and P2 incidents, we will publish a Root Cause Analysis within 5 business days of resolution. The RCA will include a timeline of events, root cause identification, impact assessment, and preventive measures implemented.
• Customer Notification: Affected Tenants will be notified via email with a summary of the incident, the duration of impact, and any applicable service credits.

Communication Channels

• Platform dashboard status banner (real-time during incidents).
• Email notifications to Tenant primary contacts.
• Status page (when available) for real-time incident tracking.

8. Service Credits

If Momo Pulse fails to meet the uptime commitment for a given calendar month, affected Tenants are eligible for service credits applied to their wallet balance:

How Service Credits Work

• Service credits are calculated as a percentage of the total charges debited from your wallet during the affected calendar month.
• Credits are applied as a wallet balance adjustment with a clear description referencing the SLA breach.
• Service credits are not redeemable for cash and cannot be transferred to another account.
• Service credits are the sole and exclusive remedy for SLA breaches under this agreement.

9. Credit Calculation & Limits

Requesting Credits

• Service credit requests must be submitted within 30 days of the end of the calendar month in which the SLA breach occurred.
• Submit your request to support@momopulse.com with the subject "SLA Credit Request" and include your Tenant ID and a description of the impacted period.
• Our team will verify the claim against our monitoring data and respond within 10 business days.

Credit Limits

• The maximum total service credit for any single calendar month shall not exceed 50% of the total charges incurred by the Tenant during that month.
• Service credits are not cumulative across months. Each month is evaluated independently.
• Credits cannot reduce your balance below zero or create a negative obligation for Momo Pulse.

10. Exclusions

The following situations are excluded from uptime calculations and do not qualify for service credits:

• Scheduled Maintenance: Downtime during pre-announced maintenance windows as described in Section 5.
• Force Majeure: Events beyond our reasonable control, including natural disasters, wars, government actions, pandemics, widespread internet outages, or catastrophic infrastructure failures affecting multiple cloud providers simultaneously.
• Third-Party Provider Outages: Downtime caused by the unavailability of third-party services that Momo Pulse depends on (e.g., Meta's WhatsApp Cloud API, upstream AI model providers, telephony carriers, SMS gateways, payment processors) where the outage originates entirely outside Momo Pulse infrastructure.
• Customer-Caused Issues: Service disruptions resulting from the Tenant's own actions, including misconfiguration, API misuse, exceeding documented rate limits, or actions that violate our Terms & Conditions or Acceptable Use Policy.
• DNS & Network Issues: Connectivity problems between the Tenant's network and Momo Pulse infrastructure that are caused by the Tenant's ISP, DNS provider, or local network configuration.
• Alpha/Beta Features: Any features, services, or APIs explicitly labeled as "alpha", "beta", "preview", or "experimental" are not covered by this SLA.
• Account Suspension: Service unavailability due to account suspension for non-payment, policy violations, or security concerns as described in our Terms & Conditions.

11. Monitoring & Reporting

We use comprehensive monitoring to measure, maintain, and report on service availability:

• Automated Health Checks: Synthetic health checks run every 60 seconds against all core service endpoints from multiple geographic locations. These checks measure availability, response time, and functional correctness.
• Infrastructure Monitoring: Server CPU, memory, disk, and network metrics are monitored continuously with automated alerts for threshold breaches.
• Application Performance Monitoring (APM): Request latency, error rates, queue depths, and database performance are tracked in real time.
• Call Quality Monitoring: Voice call quality metrics (jitter, packet loss, latency) are monitored for calls processed through our platform.
• Alerting: Automated alerts are routed to our on-call engineering team 24/7. P1 alerts trigger immediate paging; lower-severity alerts follow the escalation path described in Section 13.

Reporting

• Enterprise Tenants may request monthly availability reports showing uptime percentages, incident summaries, and maintenance windows for the preceding month.
• Reports are provided within 10 business days of the request and cover the most recent complete calendar month.

12. Support Tiers

Momo Pulse provides support across two tiers, each with different response times and channels:

To inquire about Enterprise Support, contact sales@momopulse.com.

13. Escalation Procedures

If you are not satisfied with the response to a support request or incident, you may escalate through the following path:

Escalation Levels

When escalating, please include your Tenant ID, the original support ticket or incident reference, and a description of why you are escalating. Enterprise Tenants may escalate directly to their named account manager at any time.

14. Data Protection & Backup SLA

In addition to platform availability, we maintain commitments around data protection and recovery:

• Automated Backups: Full database backups are performed daily. Incremental backups run continuously to support point-in-time recovery.
• Recovery Point Objective (RPO): 1 hour — in a worst-case disaster scenario, no more than 1 hour of committed data would be lost.
• Recovery Time Objective (RTO): 4 hours for critical services, 24 hours for non-critical services — the target time to restore full service from a backup after a catastrophic failure.
• Backup Encryption: All backups are encrypted at rest using AES-256 and stored in geographically separated locations from the primary database.
• Backup Testing: Backup restoration is tested regularly to verify data integrity and recovery procedures.

15. Third-Party Dependencies

Momo Pulse relies on several third-party providers to deliver its services. While we select providers with strong reliability track records and monitor their availability, outages in these services may affect Momo Pulse functionality:

• Telephony Carriers: Voice call setup and routing depend on upstream carrier networks. Carrier outages or congestion may affect call quality or availability.
• SMS Gateways: SMS delivery depends on third-party gateway providers and destination mobile networks. Delivery delays or failures at the carrier level are outside our direct control.
• Meta (WhatsApp Cloud API): WhatsApp messaging functionality depends on Meta's Cloud API infrastructure. Meta's service disruptions directly impact WhatsApp features on our platform.
• AI Model Providers: AI agent functionality depends on external AI model providers. Provider rate limits, outages, or model availability changes may affect AI agent performance.
• Payment Gateways: Wallet top-ups and payment processing depend on third-party payment gateways. Gateway downtime may prevent top-ups but does not affect the use of existing wallet balance.

We communicate known third-party outages through the same incident communication channels described in Section 7 and work with providers to restore service as quickly as possible.

16. SLA Review & Updates

• This SLA is reviewed at least annually and updated to reflect changes in infrastructure, service offerings, and operational capabilities.
• Material changes to SLA terms (such as uptime targets or credit percentages) will be communicated at least 30 days in advance via email to all Tenant primary contacts.
• Enterprise customers with custom SLA terms in their service agreements are governed by those agreements, which take precedence over this public SLA where they differ.
• Continued use of the platform after SLA changes take effect constitutes acceptance of the updated terms.

17. Contact Us

For SLA-related inquiries, service credit requests, or to discuss enterprise support options:

• Support: support@momopulse.com
• Sales (Enterprise SLA): sales@momopulse.com
• Legal & Escalations: legal@momopulse.com