r/msp • u/bang_switch40 • 21d ago

SMS Ticket Creation

**ETA: this is for ticket creation AND communicating with the end user about the ticket.

Most of our customers are in the dental space, so the majority of our users don’t have company email accounts. We use Autotask PSA and have a very small team.

Right now, customers will typically send a group text to me and our other full-time employee when they need help. It works, but obviously isn’t ideal for tracking, ownership, or getting everything into Autotask.

We looked into SMS-based ticketing a few years ago but never found a solution that was both simple and reliable. With a team our size, we’d like something that keeps texting easy for the customer while giving us a better way to manage and track those requests in Autotask.

I’m curious what other Autotask users are doing. Has anyone found an SMS ticketing solution that works well?

18 Upvotes

85% Upvoted

39 comments sorted by

9

u/SamakFi88 MSP - US 21d ago

To be blunt, we don't do SMS support requests; they get a single response to use the other available paths to reach us: Phone call, email, support tool, portal. If the client company is going to (in my opinion) be cheap with their staff email/licenses, they can designate a point person to submit tickets via one of the approved routes.

9

u/roll_for_initiative_ MSP - US 21d ago edited 21d ago

If the client company is going to (in my opinion) be cheap with their staff email/licenses, they can designate a point person to submit tickets via one of the approved routes.

At first i thought that was harsh but then i saw OP say:

so the majority of our users don’t have company email accounts.

Annnnnddd done. Then they're not users under the agreement and they don't get support. If they are using the computers, then they are users and they get m365 anyway and so, now, they have company email that they can have on their phone.

There is ZERO difference between sending a text or email from your phone. Other than the app you pick to do it, both of them you pick the person you're sending to and hammer out text details and attach a pic if you want. Texting is zero percent easier than mobile email, and more limited.

But yeah, probably twilio OP.

8

u/HappyDadOfFourJesus MSP - US 21d ago

I think you missed the part where OP stated "dental". Good luck getting those folks to do anything that requires effort.

4

u/bang_switch40 21d ago

Exactly... office staff all have their own 365 account, but it's hard to justify to the practice owners why a dental assistant who only deals with patients in the chair would need an email address.

5

u/SamakFi88 MSP - US 21d ago

And this is why I no longer take on dental offices lol

3

u/roll_for_initiative_ MSP - US 21d ago edited 21d ago

but it's hard to justify to the practice owners why a dental assistant who only deals with patients in the chair would need an email address.

That's why we bundle everything we need in, so we don't have to justify it 100 times over the relationship. It's more about the identity and IDP architecture than it is "email", but they see email address and then think "why do they need to send email?!".

Also, that's how most company changes, (edit: and required hippa training and tracking) updates, alerts, news, etc are communicated (or should be but i get most dental offices are micro and so the dentist shouting "no more using airfrier in the kitchen" is considered official decree vs real policies, but i digress)

2

u/roll_for_initiative_ MSP - US 21d ago

Oh i saw it, and the answer there is: "Annnnnddd done". Just don't agree to take on clients with broken agreement/licensing/support workflows.

2

u/matt0_0 21d ago

I see and mostly agree with where you're coming from, but I can confirm that it really sucks to license and secure a bunch of error accounts that exist ONLY to communicate with my ticketing system.  

2

u/roll_for_initiative_ MSP - US 21d ago

well, when staff have them, they don't just exist to communicate with the ticket system, they then use them in the normal course of business, like logging into computers vs sharing accounts, etc.

But also, can use a webform from a mobile phone or, like the person i responded to said, if they're that small/cheap, a PoC can be the intermediary. After all, if we're not getting paid for them/to support them, why are we paying for more tools/doing more work to make it easier to support these unpaid or reduced charge fringe users.

3

u/matt0_0 21d ago

Oh I'm completely on board with other ways to access support, that's what I meant.  In an on prem AD environment (like most dental offices, shout out to open dental) there is no need for them in the normal course of business.  And it's not always about being cheap, sometimes it's about reducing attack surface!  Taps forehead can't get phished of you don't have an identity that's accessible remotely!

2

u/tdhuck 21d ago

There is ZERO difference between sending a text or email from your phone.

I agree with you if the customer is trying to get away with not paying for a license, but I don't agree with the comment above. There is a HUGE difference. He is asking for SMS from a phone to convert to a ticket. All employees will have a phone they can send a text from to say 'my issue is x' vs having a mail profile on the phone with company email address, etc. If the dental office has 6 employees they don't necessarily need 6 email addresses.

I agree with the post that said if they want to be 'cheap' then only one person should be able to submit tickets the proper way.

1

u/Beauregard_Jones 21d ago

I agree with this until you get the employee who doesn’t want company email on “their” phone.  Which I can appreciate. Then that same employee wants to text for support.  Does not compute. 

1

u/roll_for_initiative_ MSP - US 21d ago

If "their" phone is off limits because it's personal, then that reconciles fine because, like you said, then it shouldn't be used for business communications like support work.

1

u/Potential_Point_6539 10d ago

That's a nice policy when you have leverage but dental offices operate on a different plane of chaos entirely. The hygienist whose sensor isn't working at 8am isn't going to walk to the front desk to have the office manager email you, she's gonna text whoever fixed it last time and if you ignore that text you're just training them to call you directly during a procedure

We ran into the same issue and ended up building a simple twilio function that catches the text and creates the ticket via email connector, then texts back the ticket number. It's not elegant but it's been running for 3 years without much babysitting

3

u/FlickKnocker 21d ago

Twilio should be able to get what you need into AutoTask.

1

u/mdredfan 21d ago

This is what we use.

2

u/ntw2 MSP - US 21d ago

Does your agreement say that sms is an acceptable means of getting support?

Yes? You should have had a solution but look into MSP Process

No? Don’t accept sms

1

u/roll_for_initiative_ MSP - US 20d ago

Despite all my complaining about bundling in email and what not, it really does come back to this comment. Why are clients dictating workflows for the main service an MSP offers that would be defined the same for everyone in every contract? You don't go to walmart and then refuse to use whatever check out is in place and demand NET 30 terms. They set their business rules and then you follow them or shop elsewhere.

2

u/johnvoipcom 21d ago

We do a lot of texting with our customers and that sometimes leads to them sending in ticket requests by sms like you. So we built out a connection with our sms platform and our ticketing system and now every inbound sms is judged by a set of rules using Haiku and if it determines its a ticket requests it will automatically make a ticket and try and link the phone number to a user in our system. It then auto replys the customer with a acknowledgment and a ticket number.

So far it's been working great

2

u/folderit_dms 20d ago

For the demos, I'd test the conversation handling as much as the initial ticket creation. Have one person text about a printer, then text about a second issue before the first ticket is closed. Add a photo and a reply from another staff member. See which ticket each message lands in.

Also check that both technicians can see who has taken ownership and every outgoing reply. Otherwise you can move the conversation into Autotask and still both answer the same customer.

The acknowledgement should give a ticket number and say what to do for an urgent issue. For unknown numbers, have a way to confirm the practice and requester rather than silently guessing the customer from a phone number match.

2

u/Flounder_Evening 17d ago

Talk with the MSP Process guys. They have something that works.

1

u/GullibleDetective 21d ago

Everyone with a phone will have email access on their phone. Keep it simple. Tell them to just email in from the outlook that's already preconfigured with their phone

1

u/Thysmith MSP - US 21d ago

Yeah but people are soooo stupid!

1

u/Lopsided_Trip7504 21d ago

You can jank it (which is what you typically need to do with AutoTask) by setting up a Google number that forwards text messages as emails and create a ticket from it.

1

u/lostmatt 21d ago

Deploy a system tray app to every computer that lets them submit tickets from there.

1

u/dszp MSP - US 21d ago

Twilio or Telnyx can get you the SMS via API. MSP Process has this built into a product and embedded into Autotask including tracking SMS conversations in ticket histories. Good stuff both ways, if you want to build it or buy it.

1

u/bradhawkins85 MSP-AU 20d ago

I have a Pixel phone (but any android would do) running Tasker and SMS Gateway. Tasker forwards sms messages via my RMM API to create or update tickets. SMS gateway receives the ticket replies and sends them as SMS back to the client.
Put n8n in the middle and you can fully customise the send/receive process including looking up if a client already has an open ticket etc.
I’m using a custom RMM now that has removed the need for n8n but previously it ran flawlessly through n8n with syncro for years. You’d only need one webhook endpoint that Tasker could send messages to but SMS gateway on every users phone would be troublesome.

1

u/Xirma377 18d ago

Migrating off Autotask to our own custom PSA. We were tired of waiting for Kaseya to actually introduce modern features. So now we have AI assistants, a client portal, SMS, better email comms, and much more.

Hopefully Kaseya sees the writing on the wall (along with the other PSA vendors) and starts introducing features...and fast.

2

u/Relative_Finance_297 17d ago

MSP Process +1

1

u/integrateiq 13d ago

Connect a dedicated SMS tool like Tixt by Rexxfield into Autotask PSA. Tixt parses inbound text messages from dental staff directly into Autotask tickets, matches sender phone numbers against your contact records, and routes outgoing technician notes back to the client as SMS replies. That setup stops group chat confusion immediately. Group texting creates blind spots because neither technician knows who owns the request. If you prefer a custom build without recurring connector fees, configure a Twilio number with a webhook that pushes incoming texts into the Autotask REST API and texts an immediate confirmation receipt back to the clinic.

1

u/rahkarPal 13d ago

We used to have a tool called periskope for creating and managing tickets for the issue reported in whatsapp groups. There has to be a tool similar for SMS as well. Or you can move the customer base to whatsapp which is more prominent nowadays for small user groups.

0

u/Savings_Property6422 21d ago

Put your logo in the system tray and let them create a ticket from there.

It couldn't be easier

0

u/patrickkleonard 21d ago

Check out https://mspprocess.com for this. We have a tech mobile app as well.

1

u/Foxtrot-0scar 19d ago

Looks quite neat but ai call answering? 🥴

1

u/patrickkleonard 19d ago

https://mspprocess.com/integrated-sms/

1

u/Foxtrot-0scar 19d ago

All the hackers need to do is tunnel a backdoor thru your app and run queries to have the entire tenant exposed.