When our front line staff self-identify files that need to be merged, they create a CSI for our admin team to schedule the merge. The front line staff do not have access to the Constituent Merge screen. With 15.1, we've noted that it is no longer possible to merge multiple files into one keep file at a time. We're now looking at how we'll manage that - do we ask the front line staff to create a CSI for each merge so that our admin team can mark one CSI closed and then complete the next CSI after the merge procedure runs? Or, do we ask our admin team to manually keep track? This can be troublesome because we only have our merge proc running three times a week.
So, we have a couple of questions here:
1. How often do you have your merge constituent proc running?
2. How do those on 15.1.x handle multiple merges into one keep file?
3. Do other orgs allow their front line staff to schedule merges themselves?
Any insight into your own process would be great!
Hey Michele,
I believe all the vast majority of our users have access to the merge window. We have the stored procedure run nightly to look for new duplicates and to merge our scheduled duplicates. We have our set very broadly so it brings in a lot of accounts that are not duplicates (I wish there was a way to remove that possible duplicate marker so that Tessitura doesn't find the same "dupes" every day). As for V15.1 and the new merge process, I just setup a reminder in Outlook to do those merges. I suppose I could also set up a task in Tessitura and have a reminder populate every time I have one when I log in the next day, until I schedule the merge.
I'd be happy to talk more with you.
- Chris
Thanks Chris. Do you find that you've had 'issues' with users incorrectly merging files? I worry that they may not be as attentive to the process as our dedicated admin staff.
I haven't noticed that happening at my current employer. I, personally, have made that mistake before. I find it's easier to make that mistake when manually entering account numbers versus using the merge window as that gives you what Tessitura thinks is the duplicate. It's a much easier way to verify that they are actual duplicates in need of a merge. Unfortunately, if you give access to merges, then staff can enter a manual number or use the possible dupes. However...if you instill true fear into staff about merges and that they "not able to be undone", then you should be okay. I always now double check merges I manually enter to ensure I am merging the correct duplicate accounts.
Hi Michele,
Merging the wrong duplicates has happened on occasion here as well, even from a staff person I would have never expected it to happen. When training staff who will schedule merges we tell them over and over to double check the keep and delete screen to be sure you have typed in the correct Constituent IDS for the duplicate accounts.
We have two levels of staff for merges. Those who can prep them, which is mostly all ticket office staff and those who actually schedule them. Those who schedule are proven trustworthy staff. However, as I said it has still happened. I can say though, this individual never forgot that mistake and is now very careful.
Those who prep get both accounts ready to merge by using rules we have provided to them in training such as ways to confirm it really is a duplicate, adding alias, and making sure the addresses are edited to our protocol. Then they create a Plan Step in Plans that marks them for merge. Those who schedule the merge run a plan report to find the list of prepped merges, take one more look to make sure they are appropriate for merge and then they schedule them and mark the Plan step complete.
We find mot of our duplicates by using the include potential dupes check box with constituent search while processing orders. Once those recently found/used accounts are fixed those who can schedule merges look through what is left in the merge screen potential dupes.
Keeping our records clean of merges is a constant battle and keeping staff trained well on how to do them when there is turnover is also difficult.
Thanks for this Terry. Any reason why you use Plan Steps instead of CSI's?
We find it is easier to use for our purpose than CSI. However it could go either way. In Plans we use the associate ID for the Delete account. I created a custom report from the Step Detail report that shows the associate's name. We can pull that report up on the screen and get into the plan step very easily to change the step type when working on the merges. We also can save the report to a PDF and easily copy and paste the customer IDs. It works pretty slick for our needs.