Root-cause review and improvementsFor significant incidents
SUPPORT STAGES
From incident to recovery
This is how the team handles an incident. Select a stage to see what Smartup does and how the customer checks the outcome.
Context01
Register
Clarify who experienced the issue, when it occurred, which product was affected and which actions led to it.
Outcome: the team has the information needed to investigate.
Priority02
Assess impact
Determine whether a critical process is stopped, how many operations are affected and whether an acceptable workaround exists.
Outcome: an agreed priority and a person responsible for customer updates.
Action03
Restore operations
Investigate the cause, agree on a fix or temporary workaround and check how to restore operations.
Outcome: the process is restored or an agreed workaround is operating.
Control04
Verify the result
The customer and Smartup check the result in the actual scenario and confirm recovery before closure.
Outcome: verified recovery and a recorded resolution.
Improvement05
Review the cause
For significant incidents, record the root cause, corrective actions and measures that reduce recurrence risk.
Outcome: findings and actions are visible to the participants.
PRIORITY BY IMPACT
Request priorities
Priority depends on what has stopped working and whether operations can continue. Priority levels and response targets are agreed in the signed SLA.
P1
Critical impact
A critical sales, shipment, payment or accounting process is unavailable and no acceptable workaround exists.
The SLA defines how urgent issues reach the responsible specialists.P2
High impact
A significant share of operations is constrained, but the process can continue temporarily under an agreed workaround.
Restore the process first, then address the cause of the failure.P3
Limited impact
The issue affects a function or user group without stopping the primary business process.
Diagnosis and correction follow the agreed operating workflow.P4
Request or consultation
The team needs configuration, clarification, access, a change or product development without a current process failure.
Clarify the task and assign it to the responsible team.
WHAT THE SLA DEFINES
What the SLA covers
Before support starts, agree on its scope, the people involved and how to respond to an incident.
Response
The team starts working on the request.
Recovery
The process returns to working order, including through an agreed workaround.
Targets and measurement rules are defined in the signed SLA.
01
Support scope
Products, environments, companies and processes included in support.
02
Channels and participants
Who raises requests, where communication happens and who can make decisions.
03
Priority matrix
How business impact maps to an incident priority.
04
Support hours and targets
Request intake hours, time zone, response and recovery targets, and progress updates are agreed in your SLA.
05
Planned maintenance
How planned work, notices and operational impact are coordinated.
06
Escalation and reporting
Who to contact if an issue remains unresolved and how support results are reviewed.
07
Change and exit
How terms are reviewed, data is handed over and service is closed.
PREPARING A REQUEST
What to tell support
For an urgent issue, use the channel agreed in your SLA. Describe what stopped working and how it affects operations; the details below help with diagnosis. Do not send passwords or secret keys, and remove unnecessary personal data.
01
Where
Company, environment, module and affected process.
02
Who
User, role, business unit and device.
03
When
Time of occurrence and the last successful operation.
04
How to reproduce
Sequence of actions and relevant input data.
05
Expected and actual
Expected result, observed result and system messages.
06
Business impact
Affected operations, scale of impact and available workaround.
RESPONSIBILITY BOUNDARIES
Who is responsible for what
Roles are agreed in advance so a request does not stall between the process owner, IT and the Smartup team.
Customer
Describe the issue and verify the result
Appoint authorized participants and the process owner.
Describe the steps and conditions of the error and agree on secure diagnostic access.
Verify the result in the actual operating scenario.
Smartup
Diagnosis, communication and recovery
Clarify the request and keep the customer informed of progress.
Coordinate diagnosis, correction and safe process recovery.
Record the resolution and required preventive actions.
Signed SLA
Support scope and working arrangements
Define applicable service levels and exclusions.
Specify channels, participants and escalation rules.
Take precedence over this public description.
COMMON QUESTIONS
SLA questions
01Who helps after launch: support or Customer Care?+
For a system question or error, start with support through the agreed channel. First-line support clarifies the request and passes the collected information to second-line engineers when needed. Customer Care helps discuss training, feedback and broader use of Smartup. The service arrangement and scope are agreed for your project.
02What is an SLA and why is it needed?+
An SLA (Service Level Agreement) defines support scope, response and recovery targets, priorities and responsibilities. This page is informational; binding terms are defined in the signed agreement or SLA.
03How is incident priority determined?+
By business impact: process criticality, affected operations and users, availability of a workaround, and risk to data or execution.
04How does response time differ from recovery time?+
Response is when the team starts working on a request. Recovery means restoring the process to working order, which may include an agreed workaround. Targets and measurement rules are defined in the signed SLA.
05When is a request considered closed?+
After the outcome has been checked in the agreed scenario and the resolution recorded. For an incident, this includes confirming that operations have been restored; for a request or consultation, it means checking the outcome against the question raised. Significant incidents may also require agreed findings and preventive actions.
06How are channels and escalation agreed?+
Authorized participants, working channels, communication owners and escalation rules are documented for the specific project in signed terms.
07How is the SLA different from the technical support page?+
The support page explains how to prepare and manage a request. The SLA defines contractual service boundaries, targets, priorities, responsibilities and escalation rules.
PUBLIC DOCUMENT
Full SLA text
Scope, support terms, responsibilities and exclusions. This is a public overview, not an individual agreement.
Status
Informational, non-binding overview. Availability targets, support hours, response and resolution times, pricing and service credits apply only when expressly stated in a signed agreement or SLA.
Operator
Green White Solutions LLC
Effective date
Version
2026.08
Status
Informational and non-binding
On this page
1. Document status
Informational, non-binding overview. Availability targets, support hours, response and resolution times, pricing and service credits apply only when expressly stated in a signed agreement or SLA.
2. Standard licence coverage
Standard coverage includes platform updates, documentation, service notices, guidance on supported functions, a limited agreed API scope and requests through official channels. Users, modules and environments are order-specific.
3. Service availability
Informational, non-binding overview. Availability targets, support hours, response and resolution times, pricing and service credits apply only when expressly stated in a signed agreement or SLA. Defined by the signed agreement.
4. Infrastructure and security
Defined by the signed agreement. Specific safeguards, environments and architecture are confirmed in project documentation and the signed agreement.
5. Exclusions
Availability excludes agreed maintenance, force majeure, customer or third-party network failures, customer misconfiguration, unsupported changes, attacks outside the agreed perimeter and contractual suspension.
6. Incident priorities
Defined by the signed agreement. Priority is assigned according to business impact, affected users and the availability of a workaround.
Target times
Priority
Example
First response
Target resolution
Critical
Production unavailable; no workaround
Defined by the signed agreement
Defined by the signed agreement
High
A key process is seriously impaired
Defined by the signed agreement
Defined by the signed agreement
Medium
Limited function with a workaround
Defined by the signed agreement
Defined by the signed agreement
Low
Question or minor deviation
Defined by the signed agreement
Defined by the signed agreement
7. Support channels and hours
Defined by the signed agreement. Channels, service hours and critical escalation procedures are defined for the specific project.
Support channels
Channel
Use
Response guide
Telephone
Critical and high incidents
Defined by the signed agreement
Bot or chat
Operational requests
Defined by the signed agreement
Email
Requests requiring files and history
Defined by the signed agreement
8. Additional work
Defined by the signed agreement. Additional integrations, migration, training and extended support are scoped and priced separately.
9. Request and escalation
Provide organisation, production environment, start time, affected process and users, reproduction steps and evidence. Use the agreed project channel, support@greenwhite.uz or +998 (71) 203-03-05.
Tell us which products and processes you use. We will discuss support scope, contact channels and response-time requirements so the agreed terms can be recorded in your SLA.
