It would be great if we can forward the SMS in OwnerRez CRM to my cell phone. I have automated messages sent out to my guests with my cell phone number inside, however, I notice a lot of people don't read or remember my direct cell phone number and still use the OwnerRez phone number to respond, this led many incidents that I failed to timely address their inquiries or concerns due to the fact there is no immediate notification from OwnerRez unless I am using OwnerRez.
Stuff like this is why I haven't activated OR's SMS feature yet, despite being an early proponent of it and asking to be put in the beta.
I think with as much as the OR system is maturing (including offering channel messaging integrations and SMS functionality), it's past time the OR team develops (or contracts to develop) mobile apps with push notifications and quick access to a messaging inbox. Real-time notifications are absolutely necessary in this industry in 2021, especially with the (also unnecessary) ~2-minute delay OR engages in when sending emails via their Postmark ESP (they appear to use a batch process that runs every ~1-2 minutes instead of sending messages in real-time, which Postmark should support AFAIK).
Chris L said:especially with the (also unnecessary) ~2-minute delay OR engages in when sending emails via their Postmark ESP (they appear to use a batch process that runs every ~1-2 minutes instead of sending messages in real-time, which Postmark should support AFAIK).
Because of the volume of data we process, we can't connect to data partners in real time. Doing that would cause negative domino affects depending on what the success/failures was from the partner and the response time. All SaaS apps of any size have to use queues to process inbound and outbound requests. Not just email but also SMS, bookings from channels, inquiries, rate/rule pushes and a dozen other things.
We send email to the ESP (typically Postmark, but not always) every ~30 seconds or less, and it's often a lot less, so the TTI (time to inbox) is very fast. Not sure where you're measuring 2 minutes, but that's not typical. Could be your inbox provider not surfacing it for a minute or virus checks or something else going on.
ESPs sometimes delay messages on their own based on temporary network slow-downs, blocks or issues they are seeing with IPs being slow on their side. They might have rules for Comcast (for example) that say they shouldn't deliver more than 10k emails per hour on a particular IP and they're coming up close to the max across the entire block. We use dedicated IPs with our ESPs but it doesn't always matter.
I should point out that our TTI is typically faster than the channels. Vrbo can sometimes take 5-10 minutes to deliver a message, and that includes the push notification on their mobile app.
There's no way to design or pay for a system where you have always-immediate email delivery. That doesn't exist in the email world.
SMS is a bit better but still not guaranteed immediate when sending via SaaS.
PS. I agree on push notifications, and we've discussed that internally as a delivery option for system alerts.
I don't know how many emails you guys send a day, but at my day job, we use AWS SES to send about 25,000 transactional messages a day. We send in real-time, not in a batch/queue process. It's possible that SES may implement some minor delivery throttling on their end (between SES and the destination SMTP server), but I've never noticed any delays beyond maybe a few seconds.
Two minutes may be a slight exaggeration, but here's one that had a 54-second delay: https://secure.ownerreservations.com/inbox/history/emails/23266793. I clicked "Send" at exactly 14:09:40 and it wasn't sent by Postmark until 14:10:36 (and then delivered to my Google Apps/G Suite/Google Workspace/Whatever-they're-calling-it-this-week hosted email account at 14:10:37):
Date: Fri, 22 Oct 2021 19:10:36 +0000
Subject: xxx 2:09:40
Received: by mta222a-ord.mtasv.net id hec6aq27tk4d for <xxx>; Fri, 22 Oct 2021 15:10:36 -0400 (envelope-from <xxx>)
Received: from mta222a-ord.mtasv.net (mta222a-ord.mtasv.net. [126.96.36.199])
by mx.google.com with ESMTPS id r25si9849819vsj.349.2021.10.22.12.10.37
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Fri, 22 Oct 2021 12:10:37 -0700 (PDT)
Received: by 2002:a54:354d:0:0:0:0:0 with SMTP id e13csp2212015ect;
Fri, 22 Oct 2021 12:10:37 -0700 (PDT)
I think the reason for the delay is because you queue your messages up and then send them in batch at xx:xx:30 (30 seconds after the top of the minute). (I sent test emails every 10 seconds for a period of 2 minutes and was able to discern that pattern.)
That delay is mostly fine for low-priority booking alerts but not acceptable when you're having real-time communication with a guest and relying on those email notifications to know when you've received a text and need to respond to it. I use Google Voice for texting and have frequently had the experience where a guest texts me and I may be in the middle of composing a response, but if I don't send the response within ~60 seconds of their send, my phone starts ringing with a call. I've learned to very quickly respond, "Hi [Name], one sec" while I then compose the rest of my response. :D
That's interesting research, thanks for sharing it with us. I understand how with the SMS/conversation side, a minute longer is annoying.
FYI - the reason we queue isn't just the volume alone, it's about all of the negative affects of sending inline. eg. what happens if you detect security issues (a user starts sending thousands of spam messages out) or the ESP is momentarily down. You don't want to drop messages, etc
It's possible to both queue and send fast at the same time, but our focus is mostly going to shift to other ways to get notified instead of email. Email isn't the correct medium for chat conversations.
Hey Paul - so are there plans to at least set up push notifications?
That would require a dedicated app, so, no, not in the near future.