SMS ticketing

MMRHC

SMS integrations. What, if anything, is anybody using?

cybershieldms

Something I am testing… you can set up a Google Voice number and set it to forward all SMS to a Gmail account. I have a forwarding rule in this Gmail account to forward to my ITFlow monitored email.

With "Create tickets for emails from unknown senders/domains" enabled, the email/SMS will come in as a ticket and you can then assign it to a customer. It only works one-way though. This can give customers a quick and easy way to open tickets.

wrongecho

This is really interesting, I actually like the concept. I used to be able to re-order contact lenses by just replying "Yes" to a text, it's so convenient.

Mapping texts to users would be quite easy given that you could add their mobile number on their contact record.

My main concerns would be:

If a contact has multiple tickets open, which one should the text be mapped to? There's no subject line in typical text messages, like we do in emails
160 character limit

cybershieldms

@wrongecho - I have set up a POS system for a jewelry retailer that has SMS integration so I do have some thoughts to share…

The POS system uses the Twillo API to send one-way outgoing text messages. Customers get notifications of status changes for their order for example, and a link to click on to pull up the sale (or ITFlow-speak "ticket") in the customer portal. For IT Flow I could imagine the client getting a text message such as:

"[MSP] A note has been added to your ticket. Click here to read: http://bit.ly/12345"

"[MSP] Ticket# 12345 has been created. http://bit.ly/12345"

"[MSP] Invoice# 12345 has been created for $100.00. http://bit.ly/12345"

The Jewelry POS has sending SMS templates as a function of a Workflows module. Basically, I can configure a rule that "if Repair (record type) status changes to Ready for Pickup, SMS and Email customer these templates."

FYI, sending Invoice notifications via SMS has been a huge win for my customer. He gets paid fast!

The 160 character limit for SMS is a pain, but if the text goes beyond, it will still be received as 2 or more back to back SMS messages. You definitely don't want to blast the whole ticket info across SMS.

I see Twillo is advertising RCS support now. RCS does not have a character limit and iOS/iMessage finally support it now too.

wrongecho

cybershieldms

I can totally see the usefulness of this but I don't want to be tied into Twilio. I have nothing against them specifically, it's just that it becomes another "Can we add X provider" - like we have with Stripe at the moment.

For a direct integration, I'd prefer this functioned like SMTP does: where you just input any RFC complaint mail server with credentials and it just works. SMPP seems to be that protocol but the research I've done this morning suggests there are very few providers that offer SMPP gateways for customers. The providers that do offer these gateways charge $250-500 a month just to use the gateway. I don't think it's worth the time to write this. They all just want you to use their API, which just increases the stickiness and reliance on specific companies within ITFlow.

In this instance, if we were to add this, my approach to this would be to provide an abstraction layer & decouple SMS sending from ITFlow as much as possible. We'd allow configuring when to queue SMS messages (e.g. invoices, tickets, etc) but queue messages into a table in the database. The message info would need to be retrieved and sent externally (either by a local custom PHP script or by a third party service accessing the API). I get this increases the TCO of running ITFlow, but it would allow you you to integrate with whatever SMS gateway you like.

Thoughts?

cybershieldms

@wrongecho - I agree with not wanting to become married and dependent on any third party. However, just like the payment processors these vendors want you married to them and have no motivation to move towards a standard.

For SMS, at least for outgoing only, the API calls are very simple. Check out this one for example: https://textbelt.com/ .

I like the way Invoice Ninja handles the problem of this API rabbit hole. They basically have set up "drivers" that can be made for each unique API for the different payment processors, making it easier for the community to add or change vendors:

https://invoiceninja.github.io/en/payment-gateways/

invoiceninja/invoiceninja/tree/v5-stable/app/PaymentDrivers

Food for thought…

wrongecho

cybershieldms

It's frustrating that a standard exists but isn't widely adopted. Like you say, they have no motivation to move towards it as they want you married to them.

Even with simple API calls, we still need a way to allow for the different formats. In Textbelt, they use 'message' whereas Twilio uses 'body'. Not to mention the different ways services want you to authenticate - textbelt as a 'key', others might accept a bearer header token.

Thanks for mentioning InvoiceNinja's approach to custom things with payment drivers. That's an interesting approach to this, and one I wouldn't be opposed to. We've mentioned before about adjusting ITFlow so it's more extensible, it's just not clear how to do this (outside of just saying to use the API).

Kind-of related post from earlier today: https://forum.itflow.org/d/1081-have-i-been-pwnd-and-password-strength/7

To be clear, I'm not against general SMS integration - I'm just against 'xy-specific-service SMS integration'. Whatever we add needs to be flexible enough that it can plug into most other services. It's more about the approach than the integration itself.
(Unless, of course, Twilio would like to donate me a cruise ship and a few islands 😂)

cybershieldms

wrongecho

What do you think about using the cell carriers email to SMS gateways. For example: just send an email to:

6015551212@txt.att.net

6015551212@vtext.com

6015551212@tmomail.net

Maybe add a SMS email field to Contact records and then go from there. Ideally this would need to be for outgoing status notifications like I mentioned earlier.

Downside it is slow to receive the texts and users may have email to SMS disabled on their end. Example: Consumers on AT&T can disable it with AT&T ActiveArmor. Business and FirstNet users cannot.

wrongecho

cybershieldms

I'm based in the UK. I remember playing with these about 10 years ago and they didn't work then.. :/

Bigbug

cybershieldms I've actually done that for ticket notifications for technician

I thought of mentioning it here but you did it first ;-)

cybershieldms

Bigbug - It just isn't the most reliable method. And you would have to know your client's cell carrier for the email address domain name too.

I'm afraid SMS is another example of having to create code to call one particular vendor's API. This is another example of where a repo of drivers similar to what Invoice Ninja has and could be maintained by the community would be beneficial.

wrongecho

cybershieldms

I really like the 'drivers' idea for issuing notifications. It solves many of the challenges because it's offloading 90% of the work to the person writing/maintaining the file.

Let me look into it further.

wrongecho

First draft at this: itflow-org/itflow1079

If you create a file at xcustom/xcustom_action_handler.php, you'll be able to listen for triggers and entity IDs and act on them.

cybershieldms

wrongecho Very cool. I will check it out!

MMRHC

I don't see a good way to have 2way communication via ITFlow without a built in integration.

FWIW, Twilio seems to be the standard for SMS. TacticalRMM has it built into their platform as the only sms option.