A saga is a workflow and “saga” a cool term, but basically a saga solve the exact same problem a workflow solves.
A saga is a wonderful way to orchestrate a set of messages in a single place and let the saga infrastructure handle the persistence of the saga state.

State?

Yes, exactly. A saga has an associated state, a state that has the shape we need, a state automatically created when the saga is started, persisted when the saga moves on and deleted, generally, when the saga ends.

Started, move on, ended?

Since a saga is a workflow there is something that triggers the startup of the saga, something that triggers a state change and something that ends the saga. What happens between states, yes multiple states and multiple steps, is up to us.

Commands

What triggers state changes in a saga are commands, messages on the queue in NServiceBus semantically identified “as commands”. Whenever the state in a saga changes an event can be triggered by the saga itself in order to broadcast to the outside world what has happened (in the past and asynchronously).

So why NServiceBus?

because, even if you can easily manage all the above concern manually, a toolkit gives you the power to forget the non-business relevant part of the story and let us concentrate on the business relevant ones.

.m