Service Level Commitment
What this document is about
This document says what level of availability Segmentic commits to, how it is measured, what is not committed, and what the customer gets if the commitment is not kept.
This is the English rendering. The Persian version is the authoritative one and governs if the two are ever read differently.
This document is annex two to the services contract and its text is also published openly. That is, what any visitor reads is what is signed under the contract.
The figures in it are deliberately conservative and are taken from Iranian comparators rather than American ones. A commitment breached every month, which generates credit every month, is of use to nobody.
--- Note: changes to this document are announced at least 60 days before they take effect. Until that day, the version published at the time of an incident governs, not today's version.
Article 1Definitions
- **The provider** means Kargostaran Nasl Javan Bakhtar,
trading as Segmentic.
- **The customer** means the counterparty to the services contract, the person
whose account is active on the system.
- **The service** in this document means two things: the event intake gateway,
the endpoint the SDK and the API call, and the management panel. This commitment covers those two only.
- **A month** means one Jalali calendar month, from its first day to its last.
- **Downtime** means the total minutes in a month during which the service was
unavailable under the article on how availability is calculated.
- **A working day** means a day that is not an official holiday.
- **A service credit** means a free extension of the subscription period equal
to a percentage of that month's fee. A service credit is not money.
Article 2The availability commitment
The provider commits that availability in any month will be at least ۹۹٫۵ percent.
This commitment covers the customer's production instance only. The evaluation environment, beta features and any feature marked experimental at release are outside it.
Planned maintenance has three conditions: announced at least forty-eight hours in advance, kept within the window of one to five in the morning, and no more than one hundred and twenty minutes in total per month. The third condition is there so that the maintenance exception cannot empty the commitment of meaning; without a ceiling, any outage can be called maintenance.
Emergency maintenance is carried out without prior announcement but counts as downtime. From the customer's point of view it makes no difference why the service is not up.
--- Note: accepting an event and delivering a message are two different things. Delivery is not the subject of this commitment, and the reason is in the article on exclusions.
Article 3How availability is calculated
Monthly availability equals the total minutes in the month minus the downtime, divided by the total minutes in the month, times one hundred.
Measurement is taken from this vantage point:
- Monitoring is from outside the provider's network, from at least two points
inside Iran connected to two different internet providers.
- Each point sends one health request to the event intake gateway and one to the
panel every sixty seconds.
- A check fails when the response is a server-side error or takes more than ten
seconds.
- A minute counts as downtime when both points recorded a failed check in that
minute. Two points are required so that one internet provider's disruption is not charged to the service.
- The smallest unit of counting is one minute.
--- Note: where the customer has their own measurement and their figure does not match ours, both appear in the claim file, but the basis for calculating credit is the provider's monitoring log.
Article 4Exclusions
These minutes do not count as downtime:
- **Planned maintenance** meeting all three conditions in the availability
article. Maintenance without announcement, or beyond the monthly ceiling, is downtime.
- **The customer's own configuration.** An invalid key, an outdated SDK, an
unregistered domain, a wrong condition in a campaign definition, and exhausted sending credit.
- **Exceeding the contracted usage ceiling.** When the request rate passes the
agreed ceiling the service throttles the excess. That is protection of stability, not an outage.
- **Upstream infrastructure.** The telecommunications operator, the SMS gateway,
the push services of Google, Apple and Cafe Bazaar, the user's own network or device, and a nationwide internet or international link disruption. The service infrastructure is inside Iran and the data stays inside Iran, so the loss of the international link does not usually bring the service itself down, but it does directly affect push services whose servers are outside.
- **An order from a competent authority.** Cutting or restricting access on the
order of the competent authorities, including filtering.
- **Force majeure.** Article 229 of the Civil Code provides that an obligor who
is unable to perform because of an event beyond their power to avert is not liable in damages. The instances expressly listed in this document are: a nationwide power cut, natural disasters, war, and a general strike.
- **Justified suspension.** Stopping a campaign or suspending an account for a
breach of the Messaging Policy or an overdue debt.
Message delivery is also outside this commitment and that has to be said plainly. A recipient who has switched off promotional SMS by short code is on the operator's blacklist and the message does not reach them, however healthy our service is. A recipient who has sent the cancellation code likewise receives nothing further from that sender ID.
Article 5Service credits
If availability in a month falls below the commitment, the customer may claim a service credit:
| Monthly availability | Service credit |
|---|---|
| Below the commitment and at least 99 percent | 10 percent of that month's fee |
| Below 99 percent and at least 97 percent | 20 percent of that month's fee |
| Below 97 percent | 30 percent of that month's fee |
That month's fee means the monthly subscription amount. Where payment was made for a longer period, the basis is the total divided by the number of months in that period.
Credit is not applied automatically and requires a claim. The reason is that there are months in which the monitoring figure dips without any effect on the customer's work, and giving credit for something nobody felt is a cost to us and means nothing to the customer.
Credit is given as an extension of the subscription period. There is no cash settlement, no refund and no transfer to anyone else.
Article 6The service credit ceiling
Total service credit in any month does not exceed thirty percent of that month's fee, even where several separate incidents occurred in that month.
The service credit is the sole remedy for a breach of the availability commitment. No other claim for loss arising from an outage, including indirect loss and loss of profit, is accepted.
Because that ceiling is low, we have set another right against it: if availability stays below 97 percent for three consecutive months, the customer may terminate the contract by written notice within thirty days of the end of the third month, and the amount prepaid for the remaining period is returned.
--- Note: where the commitment in the availability article is set at or below 99 percent, the first row of the table does not apply and the first band is the second row.
--- Note: an account with an overdue debt does not receive service credit until the debt is settled.
Article 7How to claim
A service credit claim must be filed no more than twenty days after the end of the month claimed for, by ticket in the panel or by email to support.
The claim must contain:
- The account name or the contract number
- The date and time range of each outage, stating that the time is Iran time
- At least one sample error or the identifier of a failed request
- A description of the effect on the customer's work
The provider responds within ten working days and attaches the monitoring figure for that month. An accepted credit is applied to the next period's invoice.
Letting the twenty-day deadline pass means the claim is waived. That strictness has a reason: the further we get from an incident the harder it becomes to reconstruct exactly what happened, and the assessment ends up being made from memory rather than from data.
Article 8Support
Support hours: شنبه تا چهارشنبه، ۹ تا ۱۸. The channels are a ticket in the panel and email to support@segmentic.net.
Severity is set by the visible effect on the customer's work, not by which part of the system the defect is in:
| Level | What it means | First response target |
|---|---|---|
| One, critical | The service is down for all of the customer's users, or incoming events are not accepted | One hour, around the clock |
| Two, serious | Part of the work is stopped with no alternative route, such as a campaign that will not send | Four hours, within support hours |
| Three, normal | A limited error or slowness with a workaround | One working day |
| Four, question | A question, a configuration request, a cosmetic defect report | Two working days |
A response target is not a resolution target and that difference has to be said plainly. Until the cause of a defect is found, nobody knows whether fixing it takes an hour or three days, and we do not give a commitment we cannot know we can keep.
Instead, at severity one, status is reported at least every two hours until resolution, and after resolution a root cause report is given to the customer.
Outside support hours only severity one is worked. The rest enter the queue at the next working hour.
--- Note: the support commitment is lifted where the source of the problem is the user's own network or device, third-party software not obtained from the provider, or an account with an overdue debt.
Contact
Service credit claims and any question about this document: support@segmentic.net
Kargostaran Nasl Javan Bakhtar https://segmentic.net