Developers approach a complex problem by decomposing it into smaller ones and solving them separately.
In an ideal world, solving an issue would be a complex problem A and you would be able, in a given time, to decompose it into a short list of small problems A1 to An, for each evaluating the time is straightforward, given that the time required to solve the initial complex problem would be:

with D being the process of decomposition itself.
In real world, the only problem is that t (D ) would actually be bigger than the time you spend resolving the small problems. In other words, in order to get to this level of decomposition of the problem, you practically need to solve the problem itself.
You can still:
Separate the given task (solving the issue) into smaller chunks, each chunk being still a complex problem,
Evaluate the expected time for each chunk and the corresponding risk.
For example, the task 1 requires approx. 5 hours, but the risk to being blocked doing it is high, so give 12 hours as your expectation to the customer.
Evaluate the dependencies and how they affect the time.
For example, the task 19 requires 2 hours, and the risk is so low that you can say it's 2 hours for sure. Not 1. Not 3. But task 19 relies on task 24: the task 24 may affect the task 19 in a way that you would require to completely rewrite the code of the task 19 using a different approach.
Give all those details to your customer. Don't give the sum.
The last point is important. If you give the sum, let's say 192 hours, the customer believes that it's a very precise metric, and the time you will spend is from, say, 189 to 195 hours.
If, instead, you give the details,
The customer who cares will understand that it's not 192 hours. It's 192 hours if everything goes wrong given the risk determined during the assessment. It's also 238 hours if everything goes even worse. It's also 85 hours if everything is ok.
As for the customer who doesn't care, he will not read your answer in all cases. All he want is a number, to be able to blame you later. By giving a very detailed answer he will never read, you know that he can't ask you for the time it will take again: you already answered that. He also can't blame you later, since he didn't read the answer in order to calculate the sum.