How to properly organize support for small web projects: reaction speed and billing of small tasks?

Question

Business Informatics

Hey!
Briefly about us
Web studio of 3 people. We do small projects 2-4 pieces per month. Some projects live for 3-4 months, some live for years (corporate sites). There is a pool of regular customers.
The essence of the problem
Our beloved clients are very fond of instant messengers and pour tasks from there, waiting for our immediate response. The proposal to write to the mail, at least causes them bewilderment. This greatly takes you out of the work flow on current tasks.
It seems to be logical to make some kind of support schedule, but questions immediately arise:
How to catch really burning tasks? Although, I must admit, if something comes up, they immediately call.
How often to collect and answer tasks, once an hour/2/4/day? The client then waits for an answer to be given within an hour
What tasks to bill? For example, the server of the selector has crashed, we can’t seem to do anything, but we’re sitting and reassuring the client that now everything will start up OR the project has been delivered for a long time, but after a month they found a minor mistake (it takes 10-15 minutes to solve) OR “and we changed the phone , fix it?" - such a beat in general?
As a result, we cannot find a balance that would be fast enough and at the same time we would solve such problems as a pool and somehow explain to the client that time = money and here is the bill for you at the end of the month.
PS Thanks for the advice. The only moment, I don’t want to hit clients on the hands so that they don’t write to messengers. They're more comfortable that way, I can't blame them. My attempts to ask them to write to the mail (it seemed that it could be easier - not some incomprehensible service with a soulless form, but your favorite mail) are perceived as if to put it mildly .. well, if you came to the store and ask the seller , and where do you have yogurt on the window, and she tells you "Look on the shelf for yourself", so my clients with notes of misunderstanding and irritation relate to such advice, and then there is also an additional service.
With messengers, I like itssumma approach with their corporate messenger in telegrams.

Answer 1

I think, to raise a site for accounting tickets with a form, a ticket from the form immediately gets in line, you can receive a letter on soap, in telegrams or sms on your phone, which is more convenient. We painted the rules for the client - how long you respond and so on. This is done on a million services, nothing new can be invented here, and for no reason.
PySy. To reassure the client, you can install a smart bot so that it answers each ticket: "Your call is very important for us, you are 7561 in the queue." This is a joke. :-)

Answer 2

1. Turn off messengers.
2. Use zendesk or equivalent to track tickets.
3. For billing, use the rate per unit of time to solve a new customer's Wishlist (it is clear that bugs should be fixed for free). At the same time, the number of Wishlist will decrease =)
4. So that the incredulous customer does not suffer how much he will eventually pay - use manictime or timedoctor, which log the time and take screenshots.
5. Get yourself a regulation for closing tickets and write it down in the contract with the customer even at the stage of initial cooperation.

Answer 3

If we are still talking about organizational issues, then it is necessary to draw up and agree on an SLA in which the reaction time and decision time will be prescribed.
You will not be able to catch hot appeals (tasks) without a formal form of appeal.
As for the moment "waiting for an answer within an hour." Then operate to the levels of support, for example
, the Basic level of support, the solution of requests within 72 hours,
the Premium level of support, the solution of requests within 3 hours
, etc.
From a technical point of view, we need a system for receiving and tracking user (customer) applications, which will include a contact form, priority will be set automatically, etc. you can write such a system yourself on your knee or use any existing one.