As someone who has had to become fluent in Executive, Project Management, Bureaucratic Procurement, Software Development, and Operations (I consider each of those completely distinct languages), I can empathize.
The best way I've found to improve on that type of pain is to try to shadow as many similar interactions as you can, but with people speaking the same language on both sides of the table, while having a lot of visibility into one side so you understand how their response differs from what yours would be in that situation. Unless something is horrifically wrong in a way which has clear consequences, I generally stay silent and keep my interjections to myself. And at most follow up after with the person "on my side" to try to explain to them, and let them decide if it matters enough to bring up. If they can't see the problem, it's generally useless to bubble it to the other party who has even less understanding of your position. I've learned a lot that way about how to appropriately articulate the same situation to each of those stakeholders.
In your situation, the way I've learned to handle it is always a "Yes, our system is designed to be able to support that." The buyer side just has a list of checkboxes that at some point distill down to a bid. They have no idea what the checkbox means, nor care. But they understand that bids have a lot of variables. If you as the technical resource know that it's possible to, in some warped sense, adhere to that definition, then it's a yes. But never a hard yes - every check box on their end is a potential to pull out a cost. If you have to develop SAML support, but know that it's a net new feature that'll need integrated into your auth system, then it's a "Yes, we're capable of supporting that." followed by an explicitly called out segment of your bid that pushes the anticipated development cost onto them as a line item denoting the cost for that feature's support and it becomes another negotiation point. Maybe they don't need that checkbox, if the cost is too high. Or maybe you can frontload the entire development cost of that feature onto that one customer, and it's an inconsequential expense for them. Or maybe they need it, but aren't willing ot fully absorb that development cost and push back. You don't know, and they don't either if you just say yes and try to work out the math on your side to make it work.
The best way I've found to improve on that type of pain is to try to shadow as many similar interactions as you can, but with people speaking the same language on both sides of the table, while having a lot of visibility into one side so you understand how their response differs from what yours would be in that situation. Unless something is horrifically wrong in a way which has clear consequences, I generally stay silent and keep my interjections to myself. And at most follow up after with the person "on my side" to try to explain to them, and let them decide if it matters enough to bring up. If they can't see the problem, it's generally useless to bubble it to the other party who has even less understanding of your position. I've learned a lot that way about how to appropriately articulate the same situation to each of those stakeholders.
In your situation, the way I've learned to handle it is always a "Yes, our system is designed to be able to support that." The buyer side just has a list of checkboxes that at some point distill down to a bid. They have no idea what the checkbox means, nor care. But they understand that bids have a lot of variables. If you as the technical resource know that it's possible to, in some warped sense, adhere to that definition, then it's a yes. But never a hard yes - every check box on their end is a potential to pull out a cost. If you have to develop SAML support, but know that it's a net new feature that'll need integrated into your auth system, then it's a "Yes, we're capable of supporting that." followed by an explicitly called out segment of your bid that pushes the anticipated development cost onto them as a line item denoting the cost for that feature's support and it becomes another negotiation point. Maybe they don't need that checkbox, if the cost is too high. Or maybe you can frontload the entire development cost of that feature onto that one customer, and it's an inconsequential expense for them. Or maybe they need it, but aren't willing ot fully absorb that development cost and push back. You don't know, and they don't either if you just say yes and try to work out the math on your side to make it work.