Under a loose definition, any program you write would classify as a state machine. Your program changes state as it moves from one line of code to another, and as the variables change values.
When we talk about using a state machine as a design pattern, it usually involves separating out the main state transitions into separate modules (classes), where each object's fields store the state information that it's interested in, and its main execution method deals with the primary task of that current state, and then returns information about the next state that you should move into. A main control loop invokes each state's main execution method until a defined end-state is returned.
This pattern has the advantage of closely mirroring the structure of a visual workflow that you might create in Visio or some such. When each main state of the program has vastly different responsibilities, then this helps you to naturally group your code following the Single Responsibility Principle. And when each state can only move into one or two other states, you end up with relatively loosely-coupled code, which also helps to make things more maintainable.
The program you describe seems to be a good candidate for this pattern.
- It sounds like it will be complex enough that you don't want to define the whole workflow in a single class or method.
- It sounds like each state will allow you to move to a limited number of other states.
- It sounds like the expected operations in each state are different enough to merit their own classes. If changes are made to the workflow, they will probably affect one or two states, and not the entire workflow, so it makes sense to split your classes up this way.