Rollout clauses can help with this. For instance, don't draw up a contract blindly, mandate an install base and training as part of the package, and that contr

Rollout clauses can help with this. For instance, don't draw up a contract blindly, mandate an install base and training as part of the package, and that contractually, it must be installed, training complete, and in process for X number of days, and in that time period requests are limited to direct support (IE, actual bugs or user questions). You should be meeting with users as much as possible during this time, if you can. Make it clear that you only want and will listen to their feedback and make changes in that respect. Then, schedule a meeting with the users at the end of the specified period, to get a sum of all the positives and negatives of the product, and have a separate with management about whats next, what your roadmap with them looks like (if applicable) etc. This keeps the relationship in control in a positive way, usually for everyone. I've seen clauses like this before in enterprise contracts. If you can everyone to agree to it, they turn those fears into assets real quick, and helps manage the burdensome spam of support requests for X or Y feature.