You can use the editor on GitHub to maintain and preview the content for your website in Markdown files.
Sunrise Gateway Customer SLA
In this contract, Supplier is Sunrise Gateway Ltd. led by Chabdar Georgiev
Customer is every person, organization or company, using SaaS services described below. In this particular copy of the document, this is (write manually by hand)
. . . . . . . . . . . . . . . . . (freetype name and address of the organisation)
. . . . . . . . . . . . . . . . . (freetype name and role of the representative to sign as customer)
. . . . . . . . . . . . . . . . . (freetype other details phone, e-mail, etc…)
Hosting providers Superhosting Digital Ocean Amazon Web Services
Secure Web Certificate Providers Comodo R3
Domain name providers Superhosting NamesForever
Related services DNS Backup Secure SSL VM Hosting ISP of both CUSTOMER and SUPPLIER
A service-level agreement (SLA) is a contract between a provider and the end user that states the level of service that the customer should expect from that service provider. That said, they also serve a company’s internal operations as well. They’re frequently used when a company is signing up new customers for a service.
In the event that the service-level agreement is between the marketing and sales departments, the SLA will detail the company’s sales and marketing goals, such as the number of leads it intends to generate monthly and the action that the sales department will take to support the marketing department’s efforts.
A service-level agreement is important because:
Protects both parties: The SLA sets standards for the service, ensuring both the service provider and end user are on the same page with expectations. By creating clear, measurable guidelines, the end user knows exactly what to expect and what the responsibilities are for everyone involved.
Provides recourse for unmet expectations: The SLA provides specific consequences for what will happen if a service provider fails to meet its obligations to the end user. Without the SLA, it’s unclear what will happen if one or both parties fail to meet expectations. With a service-level agreement in place, there is transparency about what the targets are for each of the service levels and what will happen if they’re unmet.
Gives peace of mind: The SLA gives the end user peace of mind knowing they can hold their service provider accountable for the service they committed to at the time of the agreement.
This type of SLA is between a business and a customer. It’s also referred to as an external service agreement. It includes:
In regards of this agreement, the SUPPLIER supports the CUSTOMER to have a working and updated organizational web page. The CUSTOMER requests content updates and provides text, pictures or any acceptable format data. This updates can be provide by email, manually by USB flash or similar. SUPPLIER preparing article and upload it to the visible part of the web.
The agreement is a service as followed:
Conditions of the service availability
I. TYPES OF INCIDENTS
Service could not be available because of several reasons, each described below.
{DOAWS} * Disaster in datacenters, caused by unpredicted incident in cloud providers (DO, AWS)
{SSL} * Inability to open page because of SSL provider maintenance or incident. NOTE: This is not predictable no matter what is the Service Level.
{SUPP} * Page not available because problems in CMS or maintenance on web servers or any related servers (SUPPLIER)
Appart of the above Service should be even considered as partially unavailable in case the requested by the CUSTOMER update is not visible into the webpage
{UPDATE} * Update is not done (SUPPLIER)
In any of those cases the agreement (standards, who is responsible and what are next steps, etc..) are described in next chapters
II. INCIDENTS SEVERITY
Depending of urgency and importance incidents are qualified as P1 to P4 (see TABLE1, Appendix [1]).
Full descrition of incidents, customer type and timing acceptance are in TABLE1, Appendix [1].
Standards for the time windows of each service level (see TABLE1, Appendix [1])
Clients are different types depending of type of the support they receive and the timings of reaction in case of incidents. Also time to finish requests for webpage update by new arcticle strongly depends of this type.
All incidents described below. Timings are normally staring by the registering phone call from the CUSTOMER. E-mails are not applicable to high-priority incidents. E-mails are OK for any non-P1 incidents. Then timing commencing 24 hours after email is received
Responsibilities of each of the parties
I. SUPPLIER SHOULD REACT PROPERLY ON INCIDENTS
{DOAWS} incidents In this case SUPPLIER should keep the CUSTOMER informed by email. Only exception is if the customer plan is VIP (VIP client - 4HRS to start migration, 24 HRS to get site on a safe instance).
{SSL} incidents Agreement to the Customer is only to inform. SSL certificates are different and very dependable by the customer plan VIP only - the webpage could be started on common HTTP port to avoid silly browser questions and keep service available. If the outage will be more than 4 hours. Time to react: 4 hrs. Time of implementation - 12 hours (all timings starting by the client’s call)
{SUPP} incidents In this type we can qualify any Page not available because problems in CMS or maintenance on web servers or any related servers Maintenance should be defined by downtime and the client should be informed 3 days in advance by e-maill. VIP Clients - no downtimes are acceptable for their services, in case of any occurrence the client should be compensated
{UPDATE} Incidents Inthese incidents, Update is not done by the SUPPLIER in 4 Days (four working days) VIP clients - 1 hour or 4 hours to publish any requested article or one day for a page (timings are 24/7 for VIP)
II. SERVICE REQUESTS Common customers (Non-VIP clients) - 4 working days (up to 2 separate articles) VIP Clients - up to 4 hours for any single article. For example, if the customer requested two separate articles, he should prioritize which one to be published up to four hours, the second one will take place in after four hours, etc…
III. MID-YEAR REVIEW This can be a meeting or email thread where the client should receive a list with incidents and service requests. The service provider need to get email response that the customer is acknowledged and this report is accepted
I. SERVICE REQUESTS FORMAT
II. INCIDENT CALL
VIP Clients - Email AND Call for P1
Common clients and all under P1 incidents - Email
This chapter explains step-by-step Escalation procedures. In fact, there are two ways to call in case of incident or request. Preferable is to email, but on P1 incidents or urgent requests to use phone (to measure urgency standards, see TABLE1, Appendix [1]).
The working contract might be terminated by (1). Declaration on mid-year review; (2). After this announcement, the contract ends in the end of the current financial year
See above the supplier responsibility’s details
The contract covering this services can be considered as an one-year-agreement on first sign. After that, it is auto-renewal. But if one of the sides want to terminate the contract, it can be done at the end of the current year. Note that, the contract can be terminated only if it’s declared on last mid - year review with the Supplier