Terms of Support system usage

Updated: 24th June 2022.

"Support system" purpose

This application referred in legal documents as "Support system" is designated to handle ideally all communication between the the customer and the supplier related to all software products (referred here as "Products") released by companies Forcebase (Tax ID 01394096, bought by Bit Carvers s. r. o.) and Bit Carvers s. r. o. (Tax ID CZ04507517) meaning mainly the demand, offer, order of Services, their approval, acceptance and conclusion of the partial contracts.

All customers using Support system must sign an FRAMEWORK CONTRACT ON THE PROVSION OF ORDERED SERVICES otherwise the response times may be slower.

Sharing of content on Google Documents and similar services with the support team

In case you share any type of document with the support team (anybody respresented by an email on domain @bitcarvers.com), a support request connected with this document is searched. If the search requires more afford, or it is not clear to which request the shared content is connected, or the document is shared before an request is done, a new request is created with the same name as the document. Creation of such new request may result in additional fee to cover this extra work.

By sharing content via 3rd party services (Google Documents) you take full responsibility of the possible violation of the data privacy policy rules adapted by BitCarvers. Our support is not responsible of data loss of any content stored on 3rd party services (like Google Documents).

Use email import@bitcarvers.com for sharing documents like Google Document or any other data/interface access. Do not use personal address of the team (eg. tomas.vacl@bitcarvers.com), as it prevents from effectively sharing the access within the support team and also disables some security measures connected to this special email address (import@bitcarvers.com).

The support team will rewrite the summary of the requests stated in the shared content into the request (if suitable) for transparency/versioning reasons.

Usage of email, phone and instant communication

Email, phone, Skype or other channels are not recommended or supporter channels for Products as there is no transparent tracking progress, price and other management processes supported. Phone or email requests are transferred into the Support system, however a fee for usage of other than authorised channel may be attached to the request and they may be considered as urgent, which may also result in additional fees. The instant messaging and remote voice services (Zoom, Skype, Hangout etc.) are used only for scheduled meetings or deployment/license dicsussions.

Meetings can be scheduled via address based on https://support.bitcarvers.com/meet (support gives you a particular link according to region/product).

If you ask about a possible meeting date in a request comment, pesonally or by an email/call, it may be ignored. Use the online meeting reservation tool mentioned above.

Voice messages can be sent via these channels:

WhatsApp: +420739921393

Each voice message is processed with additional fee of 1 EUR within 7 working days and are replied via Support system. If there is already a Support request and the voice message is considered as attachment, the processing is according to the request type (therefore faster and usually free).

Request solution process

When a new request is created following process follows:

  1. Request is "qualified" with a type as:
    Type Description / Standard solution time Price
    Urgent error Critical finance-related process failure or suspicious behaviour, access to a critical function is disabled, action cannot be performed or an action/process is not finished properly. You may be charged an extra fee in case the problem is not related to a critical feature / finance process / email deliverability and is rather caused by 3rd party which is not supported by Bit Carvers s. r. o.
    Done before all other requests. Done ASAP including weekends and holidays.
    Always for free.
    Process error User action within the function can be finished however only with an exceptional effort, additional/avoidable steps or by a non-logic manner. This also covers misleading texts.
    Done before all other requests. Usually done within 1-2 days including weekends and holidays.
    Always for free.
    Usability error User action within the function can be finished however there is a possibility to improve the comfort of performing the action or improve design or documentation.
    Done before all other requests. Usually done within 1 work week.
    Always for free.
    Question Done before all other requests. Answered ASAP with link to training/document, with possible longer period for implementation of improvement (usually created as separated request of other type) Usually free, however it may contain fee if the question is answered repeatedly, contains know-how which is special to the particualr customer or the question is caused by loosing know-how which was already trained to the customer
    Urgent improvement Done before all other requests. Guaranteed reponse time under 90 minutes + guarenteed resolution time until next working day morning hours. Such request is always paid. The minimum fee to pay for such request is stated on the page where you create the request.
    Local new feature/improvement Feature is usable only by the particular customer and cannot be used by other customers. Date of delivery and price is defined in next 5 days. In case of ASAP need a price is set ASAP and implementation can begin sooner. Paid according to the development hours needed for implementing the feature. The budget and deadline is accepted by the customer in acceptance process, once the request is analysed by the support team. The improvements are cheaper and more quickly implemented than ne features. New features does not include product-management decision process on the side of the application support.
    Licence and upgrades Represents regular fee, support conditions, sales case or billing question. -
  2. Request is waiting in a queue until other contracts requests are done (applies only for new features and improvements)
  3. Request is contracted: attached a price tag (if applicable) and deadline and waits for confirmation from your side to accept the conditions (not applicable for free requests or requests which does not need to have special deadline)
  4. Request is solved (delivered to your application)
  5. Request is accepted by the customer (if not done, accepted automaticly in 7 days after delivery)
  6. Request is billed within a regular invoice (early beginning of each month)
  7. Request is paid as you receive the invoice

Qualification is made by the support team with exception of error which you can indicate on your own.

If customer adds an error as Question, the support team can requalify the request to non-urget error and consider that type as the original type of the request added by customer.

If customer adds an request for an operation different from a question about a situation/data/feature (eg. "please do", "please improve", "please visit") as Question, the support team can requalify the request to an impovement or a new feature and consider that type as the original type of the request added by customer.

"ASAP" solution is considered as <48h reaction, counting CET timezone work-hours; if the technical limits update of your application as soon a workaround is offered.

Each request has only one primary contact on customer side even the communication may be in copy to other contacts (on request).

Solution of request may involve communication between the support and primary contact of the customer. The customer may wait for reply from the support according following rules:

Re-opening resolved/accepted requests

Once request is marked as resolved, it can still be reopened. This case happens when the resolution quality is compromised or addition to the original request is added to improve/debug the request result.

Old requests (resolved more than 4 weeks ago) should be reopened only in severe cases and it is always peferred to create an error/question request rather than reopening an already resolved/accepted request.

Note that creating a new request may lead in many cases with faster response and also saves billing clearing issues (when the reopened request is already billed and the price possibly change).

Contacts related to the request

Each request has exactly 1 contact from the side of customer (the reproter who created the request). This contact is notified when a comment or non-automated update of the ticket is done.

In case the contact is not valid any more (eg. team changed on side of customer), you can request change of the contact (also in bulk manner if there are more requests assigned to the contact).

You can request to put all updadtes of a request in a copy to any number of addtional contacts.


Not everything can be done until next day! In case there are more opened requests, it takes some time until those requests are analysed, the deadline is allocated and budget confirmed. It is a common practice to have only several new features/improvements with a deadline set, while the other opened requests are waiting in a "queue" to be yet analysed and assigned a deadline.

You can sort (prititize) your requests in this waiting queue, so the support knows which one to pick next tfor anaysis and then contract it (set budget and deadline) once other contracted requests are done. Therefor you can (and should) use Prioritization menu to help the support team decide which request is more important.

You are informed on a request in case the prioritization is needed and also a message is displayed on the request page if prioritization is recommended.

Only requests of following types can be prioritized by the customer:

Once the priorities are changed, you will receive updates on the affected requests with proposal of new deadlines and price (if apply).

It is usual that even after prioritization, the less-periority requests will still be postponed, as the standard number of parallely-opened requests is set individually for each project (and may vary depending on the status of the project, eg. for starting project it is higher and for projects which are already settled and stable, the numbebr is lower) and it makes no sense to have more requests opened at a time (meaning they are on production line).

Requests which are lower priority are automaticly postponed. They get back active again once re-prioritization is done or requests with higher priority are already resolved.

You can create request only on name of your legal entity (customer), you cannot invite other contacts to use support services (including booking calendar meetings) if they do not have an SLA signed with BitCarvers.

Such changes will wait for confirmation from your side.

Prioritization of long-term roadmap request to upper position (more important for you) will result into conversion to a local new feature/improvement.

Hourly rates and support levels

Please login to access this information.