Knowledge base
Instructions for modules, settings and routine operations.
Skip to main contentFor self-service answers For team training To clarify the next step For investigation and record-keepingEmail
Support for day-to-day operations
Technical support
From the first symptom to a verified solution, with a clear process.
Record the context once. The Smartup team classifies the request, assigns an owner, communicates the next step and closes the request after verifying the outcome.
- Channels
- Knowledge base, videos, Telegram, email and phone
- Request process
- Intake → classification → ownership → verification → closure
Where to start
Choose the right channel for your task
Start with the knowledge base or videos for instructions. If the issue needs investigation in your project context, submit a request and keep the correspondence together.
Video tutorials
Step-by-step walkthroughs of working scenarios on screen.
Telegram
A channel for direct communication with support about your project.
A request with a subject, supporting materials and a retained correspondence history.
Before you send
Five details that help speed up diagnosis
Do not send passwords or secret keys. Share only the context and materials needed to reproduce the issue.
- 01
Process and module
What the user was doing and in which section of Smartup.
- 02
Steps leading to the symptom
The sequence of actions and the expected result.
- 03
Affected users
The role, branch or group - without sharing passwords.
- 04
Evidence
A screenshot, screen recording, document number or event time.
- 05
Impact on operations
Which process is affected and whether an agreed workaround is available.
A clear process
One request - six tracked stages
Open a stage to see what happens and what should be recorded in the request history.
01Intake+
We register the request and its starting context.
Outcome: the request is registered with its initial context.02Classification+
We clarify the affected process, symptoms and priority.
Outcome: the process, symptoms and operational priority are clear.03Ownership+
We assign a request owner and the next action.
Outcome: an owner is assigned and the next step is defined.04Communication+
We agree the channel and record request updates.
Outcome: updates and agreements are retained in a single request.05Verification+
We check the proposed action in the agreed context.
Outcome: the action is verified in the agreed context.06Closure+
We confirm the outcome and record request closure.
Outcome: confirmation and the reason for closure are recorded.
Priority based on impact
Escalation starts with business context
The level depends on the affected process, the number of users involved and whether a workaround is available.
P1A critical process is disrupted
Service interruption
- Customer action
- Share the affected process and observed symptoms.
- Smartup action
- We clarify the context and manage the request through the agreed escalation model.
P2A specific workflow is limited
Function limitation
- Customer action
- Describe the scenario, users and available workaround.
- Smartup action
- We assign an owner, examine the scenario and communicate the next action.
P3Advice or a change is needed
Question or request
- Customer action
- State the task and the expected decision.
- Smartup action
- We route the question to the relevant workstream and record the response.
Verified closure
What remains after an issue is resolved
The request history avoids collecting the same context again and shows the outcome of the investigation.
- 01
Request record
The initial context, affected process and assigned owner.
- 02
Action history
Communication, agreed steps and verification materials.
- 03
Outcome confirmation
The verified result and documented request closure.
Practical questions
What to know before your first request
01Which channel should I use?+
Use the knowledge base or videos for routine operations. For an investigation in your project context, submit a request through the agreed channel to retain the context and action history.
02What should I include in a request?+
Include the process, module, steps leading to the symptom, affected role or group, expected result and evidence that is safe to share - such as a screenshot, document number or event time. Do not send passwords or secret keys.
03When will support respond?+
Request intake hours, priorities and applicable commitments are defined in the SLA and contract for the specific project. This public page does not replace those agreed terms.
04Does an engineer need access to the environment?+
It depends on the issue. Access is provided only within the agreed scope and under project rules; the team first uses the context and safe diagnostic materials you supply.
05When is a request considered closed?+
After the proposed action has been verified in the agreed context, the outcome has been confirmed and the reason for closure has been recorded in the request history.
Need help?
Share the context - we will identify the next step
Describe the process and symptom, attach evidence that is safe to share and explain the impact on operations. For urgent escalation, use the channel and procedure specified in your SLA.