Managing Expectations Through Ticket Updates

When updating a ticket, it's important to remember that this can have a direct effect on client expectations.

It is, therefore, vital to always bear in mind that any update we place publicly on a ticket is effectively communicated directly to a client. We aren't able to predict to which degree a requester is relaying the updates we offer directly to a client, so we must assume that everything is shared.

So when we say that a task will be available tomorrow, we need to be able to fully commit to this - as our employees (the ticket requesters) may freely communicate this to a client and then the client will in turn expect a service fulfilment by a specific deadline.

If these promises aren't kept, it decreases the sense of value our clients expect from the services we provide, and it's easily avoidable.

To help avoid scenarios where clients have to chase requests or are met with disappointment when seeing their requested changes are not actually live, if we can all make a concerted effort to slightly adjust the language we use and how we use it, we will all be able make a more positive impact.

It's great to update the ticket when the development stage progresses, as this helps our requesters understand that there has been movement on their ticket. However, we need to distinguish between a general progress update and a deadlined promise.

If your ticket is going up for review...

It is a good idea to update the ticket to reflect this, especially if the request is urgent.

It's not a good idea to specify a time or day when this will definitely be completed by as we can't tightly control this process to that degree. I would, therefore, avoid stating any certain promises along the lines of "Ticket 123 is now up for review, it should be checked in tonight and will be ready tomorrow" as this is setting up a scenario where we can fail to meet a deadline.

However, if it is an urgent task and we feel the requester needs to know more specifically, it would be appropriate to use terms such as should, could, hopefully, etc. For example "Ticket 123 has been put up for review - as this is an urgent task, I am going to try to get this looked over this afternoon so that we can hopefully look to get this checked in for release tonight". This is not an evasive way to communicate - it is as much detail as we can honestly commit to at this particular stage.

If your ticket is being checked in for release...

Again, it makes sense to update the ticket to relay this information to the requester.

As above, make sure to not offer measured promises - e.g. "Ticket 123 has now been checked in and will be live in the morning". It's entirely possible for the release to fail, be cancelled, or otherwise not perform as intended. So in that respect, if we promise it will be ready in the morning, we're fully committing to a process that we can't tightly control and are setting up a scenario to fail to meet expectations.

It makes more sense to inform the requester with as much detail as we can honestly commit to, e.g. "Ticket 123 has been checked in for this evening's release. If the release goes through, this should be available in the morning." would be a more appropriate way to communicate.

Finally...

It's also important to ensure that the fix/new feature is working and available for the requester before contacting them to ask them to check if they are happy. It's the final responsibility of the assigned developer to ensure that the work has been completed successfully; the requester should only really be informed when the work is correct and available on the system. This is simply just good customer service and helps generate trust.

So, if in doubt, stick to what you know is certain and communicate honestly with the knowledge that what you have confirmed is as much as you could confirm. That way, it should help alleviate the number of times a client will need to come back to say they're still waiting for a request.