• Replies 2 replies
  • Subscribers 245 subscribers
  • Views 87 views
  • Users 0 members are here
Related

Mobile Phone Numbers vs ...Not...

Jamie O'Brien
$organization

We enabled TNEW's Mobile Opt In functionality last winter and have had decent adoption of it. At the time, we didn't have a "proper" texting operation, merely a non-integrated element of a new VOIP phone system that we could co-opt for last minute show cancellation scenarios. In that world, since everything was entirely manual, the opt in moment was the priority and we could easily preset the Output Set to look to the exact data point.

Fast forward to now, and we're aiming to level up and go beyond the "emergency" manual situation. As such, I'm looking to get onto steadier ground as to which Phone Type we pull in when. The technology is in place to detect which numbers are valid for SMS, but that's about sending it out, not the data point itself. I believe I'll be able to prioritize which field is looked to, but again, that's about sending rather than having data classified in a way I can look at.

I know this is a rather vague summary and I'd be better off posting a specific question or two, but I'm not there yet. Is there anyone out there who has been in this situation themselves and might be able to offer up some pointers about how to approach this, especially in terms of how to plan around having active usage of both the Phone Type required by this TNEW feature AND one tied into one associated with an address (not allowed per the feature; eg Phone 1)?

  • $organization

    Any updates on this, Jamie? I thought I heard someone in a community group mention a tool to run numbers through which will tell you whether they are mobile or not, but I can't remember what it was. I wanted to use something like it before enabling TNEW's mobile opt in so that I was more confident that the numbers already recorded in Tessitura in that phone type are all cell. 

    Are you using an SMS integration with Prospect2? 

    Any additional insights or thoughts on this are appreciated! 

  • $organization in reply to Odele Peter

    I'm not sure I'm in any better place to write up strategy overview, but here are some individual facts:

    • We went live on crowdEngage (cE), part of the Activity Stream offerings, as of the start of our Dec show. It's an enhanced mobile ticket platform, with the primary delivery method of SMS. Email is also part of it, but somehow SMS feels more primary. There is also an "instant send" aspect to handle quick blasts. It is a transactional product, NOT marketing.

    • cE detects usability of a phone for SMS, and they worked with me to customize which order to go through contact points on records.

    • I learned yesterday that I should be able to trust that *any* number imported into cE means it is a mobile. This is only of middling value though, at least in as far as I've gotten with it so far, because you can only ever see this information as a download per performance, the "Occupancy Report." (There's really no database aspect to it, but you can look up the current set of performances to see what's getting picked up.) I can't see us taking on a data review project based on having to export and merge spreadsheets of individual performances.

    • We're slowly making our way towards doing a data clean up on both email and phone contact points. I'm relatively sure that the majority of this work will just be about inactivating/renaming the Types to be clear indicators of usage, with supporting staff re-training and documentation around this. (e.g. "Second Email" may be replaced by "Payment Contact" or something like that--no one knows what "second email" means but there's a business need to log an extra email onto a record to send an extra copy of an order confirmation to) Within this, on the email side, we'll also pay close attention to the idea of the Primary Checkbox, as that is at the heart of what address actually shows up.

    • The one other thing we've encountered that I expect will make some people lean in is that Merges create double entries, even when it's the same value. This isn't a groundbreaking discovery, but it's a tiny item with some occasional impact. My current evaluation is that it doesn't matter a lot for us on a day to day basis, but it definitely creates a jumble if trying to inspect a record or work with an export that is set to repeat constituents across rows when there are multiple qualifying values. And, it needs more serious consideration in terms of Purposes, but that's a future topic still for me.