Support Process and Support Request
In order for support services to be provided correctly, our users and business partners must report problems by following the rules below.
In order to provide you with accurate and fast service, the following information must be included in your call.
- Version Information: The version information of the called Workcube. specify.
- Fuseaction, which is the subject of the call: Write the Workcube Object shown as fuseaction="module.obje" in the URL.
- Addoption or Extend Fuseaction Control: Specify if the call subject fuseaction is customized. Non-standard customizations are the responsibility of the customizer.
- Explain the problem or suggestion in detail. Explain the problem clearly, in bullet points, and include screenshots if available. Operations take place in different combinations and usage practices on many Workcube screens. For example, it performs an expense recording or updating operation, accounting, budget, current transaction, bank, cash or credit card transaction. There are also transaction authorizations, processes, special settings. When reporting an error, reporting what kind of error was encountered in which usage scenario will speed up solving the problem. Remember; Efforts to recapture the same case in the development and QA environment will slow down the process of reaching a solution.
- Request: Specify your request from the team that provides you with specific support.
The correct way to Request Support is as follows.
- Open the page where you request information or have a problem. (If you submit notifications from different pages, the process will be delayed.)
- In the Workcube application, click "?" in the upper right corner. Click on the "Request Support" link from the dropdown menu that opens under the icon. The support form on wiki.workcube.com will be filled automatically with your subscriber, domain, version information, fuseaction, name and email. If you report from a different server, wrong page, or directly via the wiki site, our review time will be extended.
- Enter the keywords in the title to classify the problem.
- Add the problem to the description, not exceeding 500 words.
- Upload screenshots that will help us understand the problem better.
- This will make it possible for the call to automatically go to the support specialist assigned to your subscriber.
Workcube may request detailed documentation from you in some cases. Follow the steps below while preparing this document.
- Step by step, on which screen you did what, take the URL of the screen as the title, and write down the actions you performed in short sentences.
If necessary, you can include a screenshot. - List the findings that you think should be present but are not.
- Additionally, you can explain by taking a video using online screen video capture applications such as https://www.screencastify.com or https://www.loom.com .
Who can ask?
People who are not included in the subscriber team in the Network and Alltogether records can call, but in accordance with the KVKK rules, these people will not be given feedback and a warning will be given. In this case, an application should be made to the system administrator to take part in the subscriber team.
Who answers the calls?
The support specialist who has the WSA - Support Specialist certificate and is authorized for your subscriber will answer the calls.
Make sure that your support specialist is appointed. In some cases, our customers may receive services from different business partners. Registering these changes will speed up your work.
After the call is accepted, the workflow of the call;
- Opening the call takes place at SLA-1 level.
- If the call contains a request for information, the support specialist writes user-specific help information according to the need, using documents such as wiki, tips, etc.
- First of all, is the customer on the current version? is checked. In the version information, the last update date and the last merge date of the version are checked.
- If the last update date is older than the last merge date, the customer is informed about the system being pulled.
- If there is a problem with the system in the latest version, checks are first made in the beta environment.
- If there is no error in the system running from the Beta - QA environment, the customer is informed about the Future Version.
- Beta. - If there is a problem in the QA environment, checks are made on the system where the developer branch is used.
- If there is no error in the developer environment, it is checked whether there is an ongoing business process for the page that is not in beta. If it is not sent to beta, the edit made on the job is requested to be sent to the beta environment.
- If there is no ongoing or registered job record, the support specialist opens a new job record for the developers by calling the SLA-2 level.
- If there is no problem in the developer environment, the developers are requested to review it by stating that it is a Beta-QA problem to the Support experts.
- There is a problem in the Developer or QA environment. If the mission is a critical job, it is requested to be sent to the latest version when the error is fixed.
Attention:
Missing or incorrect notifications will delay the time to classify and identify the problem.
In such cases, users are requested for additional information again.
Notifications are sent directly to the problem. If it is not notified from the domain where it occurs, time will be lost to match the Subscriber.
Reminder!
With the 19.12.2.2.1 version, the KVKK and Secure Information Sharing Rules framework has been recreated.
Call applications are accepted and information is shared from people registered in Workcube specifically for each installation.
Review the Google Doc document. You must download (click), fill it out and send it to be registered in Workcube.