So me and my team have been doing estimates for a new project but we have been getting the feeling lately that the customer has trouble understanding not the estimates in itself but what the stories described actually contain.
We have been thinking of going through their RFP documentation and in this document make a connection to our excel list with estimations saying "this part is contained within this estimate". But this approach seems to me to be very time consuming and there has to be a better way to make sure that we cover what they expect us to cover in estimates while not making it too hard for them to understand.
My question: How would you approach a customer with estimates? In what format would this be? and foremost, how would you make sure the customer understands what you have estimated and what this story contains and thus rule out - for the most part - confusion between the two parties being my company and the customer's?
Edit: I do not think this is covered by the question proposed as duplicate since this question is more on presenting the estimates and omitting confusion between what is and what is not covered by it and the communication of this to the customer; while the duplicate presented is more of a way to have a client choose for agile and what to do if he does not, and the practices hereof.
Edit 2 on Comment of Thomas Owens: The customer provides the requirements through a full text document describing their processes as best as they can and what it is that they want. Note that this might be large or complex things which we have then subdivided ourselves and written down in order to make a better estimate. The product owner is one of the customer's employees who is closest involved to the new application they want us to create but is not fully sure on all the details; leading to a lot of uncertainty on - for example - financial formulas and how they should be used.
What we have done is create a list in Excel with the processes (possible stories but not as such) described and trimmed down or split up to try having a better understanding on what each part contains; not so much technical but functional.
i.e.
Note this image is a trimmed down version for confidentiality reasons