HOW TO SAY A DEADLINE FOR A CLIENT IF THERE IS NO DEADLINE

Katerina Vinokhodova

The idea for this article was born when I saw a message from our CEO in our team chat:

The idea of not setting deadlines came from a case where we wanted to do our best, but we didn't try hard enough and didn't manage to keep our promise. It is better to be silent than to deceive — seems fair, right? But this is a harmful attitude: failure to meet deadlines is equivalent to a failure to take responsibility for solving the problem, and this is a sign of deep unprofessionalism for those who deal with clients. In fact, you should always name deadlines, you just need to be able to handle them. How?

Be honest. Be careful. Be proactive.

The phrase "no deadline" is prohibited. Where does it come from? If a solution to a task / problem / bug is not typical, it consists of several stages, which involve different teams with their own rules and a list of other tasks. To put it bluntly, a support employee doesn't have the slightest idea when they will start working and fix a bug that has just been found: there are too many parameters that affect the estimation of a deadline. What to do?

Break it up into chunks

The solution to any problem takes multiple steps. On the first step, we don't know when the fifth will come, but we know exactly when the second will come. That's the concept we use.

We explain to the client how the issue will be resolved and name the terms of the next step, or at least the next step we can estimate exactly.

That looks like a bug, passing the task to our testers, and I will get back to you with results on the investigation by 16:00 today.
Afterwards, if the bug is confirmed we will pass the task for evaluation to our development team who are will estimate it on Tuesday. Once that's done will confirm the sprint which the task will be allocated to. Aiming for that to be also done on Tuesday.

It seems like this functionality is not working, when will you be able to fix that?

Usually, the product team discusses new customer requests on Wednesdays. If a feature is accepted, it will need to be designed, then evaluated and prioritized, and then we will understand how much time it will take. You can expect the intermediate result of the product team's decision from me on Thursday.

Can you add this feature? When?

We are preparing a personal offer for you, and I want to discuss additional services and discounts for you with the management. We have a meeting scheduled for 18:00, so I will send you the document in more detail tomorrow by 14:00.

When will you send a commercial offer?

Name a time frame with a safety margin

Always make the deadline later and finish earlier. For simplicity, multiply by two. If you know that the issue will be resolved tomorrow, promise the day after tomorrow. That way, you kill two birds with one stone: you give yourself a safety cushion and exceed the client's expectations, if you are lucky and you actually manage to do it faster. The desire to set deadlines earlier is insidious. Never set the deadline earlier to please the client at the moment; if you break the agreement, it will be worse.

Act proactively

It shouldn't be the client who reminds you about the task; you should inform them regularly at an agreed time:

➤ The stage of solution of the issue;
➤ Timing of the next step;
➤ A time for the next contact (The last is the most important.).

Important! You are working with a client, you are a support rep or salesperson or an account. You are not a developer, lawyer, or product. You can't influence the solution of a bug or the design of a feature, or the agreement of a contract. You can only communicate with the client, keep them informed, fulfill promises, and give the impression that you have everything under control. You are not required to promise a deadline for a solution; your duty is to promise and get back to them on time with a new status.

I will get back to you:

What if I really, really don't know the timing of even the next step?

In this case, we will inform the client about when we find out the timing. For example, let's say there was a major failure, it is not clear what exactly is broken, you can assess the timing of the solution only when everything is fixed. In this case, we tell the client directly and honestly: "We need a timeout of half an hour to 2 hours to decide on the timing, no later. I'll be back with an update."

What if my colleagues наебали (misinformed) me about the deadline?

When we promise our colleagues deadlines, the colleague is our client. Accordingly, if everyone acts according to these instructions, the probability of misinformation is minimal.

We have an airbag for such cases with an increase in deadline for the client — that gives us a head start.

If nothing works out, as soon as we realize that the deadline is close but there is no solution, we immediately go to the client and inform them that the deadline has changed. EARLIER than we agreed with the client.

Negotiate with colleagues about a pre-deadline from the get-go. For example: if something changes, let me know 4 hours before the deadline. This way you give yourself time for a workaround and save colleagues from the shame when they say "nothing is ready, sorry" 5 minutes before the deadline.