A storm closes the grounds on a Saturday, and by Monday your staff have moved a few hundred timed tickets to later dates. A month later the finance director asks a reasonable question: how many tickets did we reschedule because of that closure, and to which dates? Getting that number out of Altru is harder than it sounds.
This article explains why rescheduled tickets are awkward to report on, what to check in your own database before you assume anything, and a few ways to make reschedules countable from now on.
Why reschedules are hard to see in a query
A reschedule changes where a ticket lives. After the move, the ticket points at the new event or time slot. Ask a query “which tickets are attached to the Saturday 10:00 entry?” and the moved tickets simply are not there anymore. Ask “which tickets are attached to the following Sunday?” and they look like any other ticket for Sunday.
So the question you actually want answered, “show me tickets that were moved, from where, to where, and when,” depends on whether Altru keeps the original event alongside the current one in a place your query can reach. We have not found a reliable, well-documented field for this that every Altru database exposes, and we would rather say that plainly than point you at a field that may not exist in your version.
Check your own database first
Before you build workarounds, spend half an hour confirming what your instance does and does not record. In a sandbox or test environment if you have one:
- Make a test sale. Sell one ticket to a near-future event and note the order number.
- Reschedule it to a different date the way your staff normally would.
- Open the order and the ticket record and look for any trace of the original date: a history panel, a note, a status, a changed line.
- Build a ticket or sales order query filtered to that order number. Browse the available fields, especially anything with “original,” “previous,” “history,” “status,” or “date changed” in the name, and add them to the output to see what they return.
- Check revenue. Some reschedules involve a price difference or a fee. Look at whether that creates its own revenue or adjustment line you could filter on.
If a field turns up the original event, you are most of the way there. If nothing does, ask Blackbaud support directly: “Is there a query-accessible field that stores the original event for a rescheduled ticket?” A yes or no from them settles it, and they can tell you whether your version behaves differently from others.
Workarounds when the query cannot show it
Mark reschedules at the moment they happen
The most dependable fix is to record the reschedule yourself, in a field you control, every time. Options organizations commonly use:
- An attribute on the sales order such as “Rescheduled” with the original date as the value. Attributes are queryable, so you can count and filter on them later.
- A standard note with a fixed prefix, for example “RESCHED: from 6/14 10:00.” Less structured than an attribute, but quick for staff.
- A dedicated reason or fee item if your process charges a change fee or zero-dollar item. That line becomes something you can filter in revenue reports.
Pick one, write it on the desk procedure sheet, and make it part of the reschedule step rather than an afterthought. A tag that staff remember only some of the time gives you numbers nobody trusts.
Take a snapshot before a mass reschedule
Closures and weather events are when reporting matters most, and they are also predictable in one way: you know which events are affected before anyone starts moving tickets. Before staff begin, run and export a query of every ticket and order on the affected events. Afterward, run the same query on the order numbers from that export and see where each ticket landed. The difference between the two lists is your reschedule report.
Compare event capacity over time
If you only need rough volume, not ticket-level detail, record sold counts for affected events before and after. It will not tell you which guests moved where, but it answers “how many did we move off that day” quickly.
What a good reschedule report usually includes
Whichever method you use, aim to capture the same handful of columns so reports stay comparable across incidents:
- Order number and constituent
- Original event date and time
- New event date and time
- Date the change was made and who made it
- Reason (weather, guest request, staff error, closure)
- Any price difference or fee
The “reason” column is the one teams most often skip and most often wish they had. It separates operational reschedules you caused from guest-requested changes, which matter for very different conversations.
Keeping the comparison out of manual exports
The snapshot approach works, but running and exporting the same query by hand every time gets old. Data Bridge syncs Altru queries to Google Sheets and other tools, so a ticket query for upcoming events can already be sitting in a sheet when you need a before-and-after comparison, and your team can keep dated copies there instead of exporting from Altru each time.
Quick answers
Will a standard ticket query show the original date of a rescheduled ticket?
Not reliably in our experience. Test with a sample order in your own database, and confirm with Blackbaud support before you build reports around it.
Can I go back and find reschedules that happened before we started tagging them?
Only if your database stored the original event somewhere you can query. If not, older reschedules generally cannot be reconstructed, which is why starting to tag them now matters.
