Iteration is a natural part of the modelling process. It does not matter whether you start by looking for the actors or the use cases. We have chosen to begin with the actors, since it is a way of expressing the system boundary implicitly and identifying the different views that need to be taken into account. In practice, you are likely to find that the actors are to be found in the roles that people play as employees in the problem domain, such as the hotel's receptionist or manager.
Actors are not intended to represent a particular individual, rather they tell us about a particular role that someone or something might adopt in order to interact with a system. For example, someone who works as a receptionist in one hotel might want to stay in another hotel as part of his or her holiday. Thus the same person will act in the role of receptionist at some times but will adopt the role of a guest at other times. Hence the two roles are modelled as different actors.
You could begin the task of identifying the actors by looking for the groups of people who use the current system in order to do their work. It might be easy to find those who perform the main tasks, such as the receptionists who work on the front desk of a hotel. But it might be harder to find those who use the system in support of their administrative or maintenance tasks. For example, would the maintenance engineers and cleaners in the hotel have to be considered? The answer will clearly depend on the scope of the problem being solved.
You can use an actor to represent an external software system. In the case of the hotel chain, it is likely that you will need to pass information about a guest's stay to an accounting system. At some later point, you may be asked to provide an interface to the restaurant side of the hotel in order to associate the costs of any meals with the guests who ate them. When the guest leaves the hotel, there may be a requirement to collect payment for the guest's stay from an external banking or credit card system. In each case, you should consider whether or not there is some value in an exchange between the use case and any identified external system. For the actors that you have chosen to include, treat them as though they were an autonomous black box. You do not need to know how they work. You only need to know about the shared phenomena that are relevant to the exchange between your system and the external system.
It is important to distinguish between an actor and the way that actor communicates with the system. For example, when analysing a system you should not be concerned with the mechanism used by the receptionist to check guests in and out of the hotel system. It could involve the use of a paper diary and a pen, a keyboard and a mouse to interact with a series of screens on a personal computer (PC) or even include a network connection or voice recognition software. You should concentrate on the meaning of the stimuli and the responses for any given use case, not the communication mechanism that is used. That mechanism is part of the solution, which you intend to provide.
In situations where two or more actors are associated with a use case, one of them must initiate the actions. The other actor(s) will play a passive role. For example, when a guest checks into a hotel in person, the receptionist typically performs the checking-in process and the guest has no direct interaction with the system. In MRP this is described as a business event: the work learns that such an event has happened by the arrival of an incoming flow of data and responds to this business event.
When it comes to describing a use case, treat the system as a black box, as in the case of an external system. It will accept stimuli from the actors and generate responses. That is, information (data) flows between the actors and their associated use cases.