System Update: New event statuses and automated booking flow
To help you better track the status of your events, we’re giving the Event Statuses in PPM a refresh.
The ‘migration’ of accounts, from legacy to new statuses (and related changes), will be a managed process over a period of several weeks, on an account-by-account basis, commencing March 2024.
We’ve created this help doc that has everything you need to know about the changes and migration process.
—
In addition to the help doc shared above, we wanted to share more thoughts to help you better understand our goals and reasoning for this important change.
Ultimately, our goal with these changes is to help our users ensure better record keeping within Party Pro Manager, which then paves the way for some really amazing, and powerful automation opportunities (which we are working on and excited to launch soon!)
To expand on what we mean here, in the old version of PPM it was technically possible (due to lack of validation), for users to put events into ambiguous or inconsistent states.
—
- Example 1: You could previously set an event, for which you were planning on collecting both a deposit and final balance later, into ‘Booking secured’ status, but actually have both the deposit and final balance payment already recorded as received.
If you were to look back at this event at a later date, you might wonder, which of the following was true:
- The event status is correct, and the final balance payment was recorded as received in error, or
- The final balance payment was correctly recorded as received, and the status is incorrect and should be ‘Balance Settled’
—
- Example 2: Imagine an event where no deposit amount has been recorded, but the deposit received date has been entered.
If you were to look back at this event at a later date, you might wonder: “How much deposit was received?!”
—
This sort of confusion is bad for you as a user, and it’s really really bad for automation tools to know what course of action to take on your behalf.
When it comes to things like online payments, and PPM Autopilot, it can be hard for the system to know what to do, when an event is in such an ambiguous / inconsistent state.
Looking at the two examples above, what should be displayed to the client in terms of payments already received, and what should it be requesting for the client to do next?
The ambiguities and inconsistencies can potentially prevent PPM Autopilot from running automations on your behalf, or worse, it could send incorrect and misleading information to your clients.
—
Looking ahead to features that are in the pipeline, like SMS messaging and an expanded, more powerful PPM Autopilot, it became evident to us that these potential ambiguous scenarios would be even more problematic for our users.
And, especially because SMS has a cost involved, we are dedicated to protecting our users from scenarios like this happening, allowing them to fully embrace automation (including sending of SMS), without fear of misfires.
