There's not a lot of information provide in the question, such as the responsibilities of the various phases, in terms of contract or artifacts/events maintained.
However, you have two choices, polling and notification.
Polling is inefficient at high frequencies, but sometimes a good option if you need/want to do things on a batch basis, say daily or weekly.
Notification sends a message from service 1 to service 2 immediately upon change. The degree of coupling between service 1 and service 2 is of interest, and can vary.
You can have service 1 know about service 2, which is relatively tight coupling, because it is not necessarily service 1's responsibility to know what service 2 needs.
You can have service 2 know about service 1, in which is requests a subscription for changes (of certain type and nature), which is looser coupling, because service 2 is downstream from service 1 and thus is already aware of some dependency.
If you use an intermediary message bus, you can decouple further as service 1 and service 2 know only about events and event types, one publishing and the other subscribing, rather than knowing about each other.
Which is the most appropriate for you depends on information not presented in the question, as is an evaluation of whether those are the right services or not.
When I'm looking at what services to have, I'm thinking about considerations such as what service is the authority of record for this or that information (or computation or decision). How are long running processes accomplished? Usually with one service responsible for the state of the long running processes, and other services interacting around changes to the long running state (doing something on state change, and then updating the state, which triggers something else to happen).
But before I even try to define services, I like to understand the business context of the ecosystem, which goes to the externally interacting roles (along with their responsibilities) of the business entities & customers involved.