Sometimes I brought the customer's business process in the concept and showed on it the areas that our system was supposed to affect. In other cases, I indicated the old and new process schemes and showed how the new scheme was more effective than the old one and due to which our development provided better functional indicators.
If the customer is not afraid of UML diagrams, show him sequence diagrams: they very clearly demonstrate how different components of the system interact with each other. Activity diagrams can be provided. However, do not overdo it: diagrams in the concept are only needed to illustrate the principle of the program, nothing more.
Before accepting the concept as the basis of the project, it is necessary to review it. The purpose of such a review is to find out that the concept really meets the set goal and provides a solution to the set tasks, but at the same time is easy to understand and does not contain anything superfluous.
Since the concept is not written in technical language, it is customary for us to convene the entire project team, which is at that moment, to “defend” the concept, and even invite someone from outside. The author of the concept makes a short presentation, and then everyone present can ask their questions. The presence at the presentation of specialists from different fields and with different experience allows us to consider the proposed concept from different points of view. Sometimes the author goes to think further, more often he receives several very sensible comments.