Start with some some Database design ,based on the relational model.The requirements you have are not particuarly complicated . If you're doing this work yourself , there are plenty of tutorials that will outline how to progress
From what I read you should be ok with one table. One field for the session (might be the date), one field for the showroom, and a field for each of the questions. And if I'm right, thne you may as well do it it in Excel.
On the other hand, if, for example you would want to link more info to session, i.e. give it a date, the inspector's identification etc., and if you would want to add the address, the tel nr and the manager of the showrooms, then you would add a "master table" for the sessions and a "master table" for the showrooms and link (relate is the word) them to your main "questionnaire result" table.
The key to this exercise is to determine (discover?) "operational information", i.e. information that is not redundant, and that is not computed anywhere else. That is the information you want to name and save in your tables. Via queries, forms and reports you produce the "non-operational" information.
That process, of determining what your "operational information" is, is known to most of us as "normalization", although I'm sure you won't find it defined in this way, so don't quote me.
If the number of employees can be either 0,1, or n, you should not have a problem, because you really have only one value for that field. I guess you figured that out yourself. So it's the names of the employees that you want to save.
The normalized way of approaching this is to create a table that has the session, the showroom and an employee name. Depending on the circumstances, this could be cumbersome because you would have one table more to maintain. But it's doable.
As far as relations are concerned, I guess at this stage, the easiest is to check outt he query builder. It's almost self explanatory. Onces you have it figured out, you might try to do data entry via the query you just built.
You can also have the database save the relations. It's similar, but different . It really depends on how you are going to use your system. Are you going to do your data entry in the tables themselves and is the point of this really to make reports withs stat?, or is this the basis of something more sophisticated that will grow with time. I'm asking because I could be confusing you with things you may not need.
Before you go too far, the the maximum number of fields in a table is 255, so you will need a table for your questions with each record for your question. This table would be linked to your other tables.