Inbound SMS Organization


  • Used Zammad version: 3.1.x
  • Used Zammad installation source: RPM
  • Operating system: CentOS 7
  • Browser + version: Chrome

Expected behavior:

  • Inbound SMS ticket submissions having some form of organization to them. Either in the form of active threads staying on one ticket or having an identifier at the start of the text that organizes it to the correct ticket.

Actual behavior:

  • Customers are submitting SMS tickets and updates that randomly open previously closed tickets or open new tickets in the middle of an active conversation. This has been an ongoing issue and I have not been able to find a way to manage inbound SMS ticket settings through the web based GUI or admin console.

Steps to reproduce the behavior:

  • Customer from organization ‘x’ sends text message to our inbound connection and this message will be added to a random ticket that this customer has previously opened in the past. It’s random when it comes to which ticket it will go to, but it will always be a ticket from that customer.

  • Main example is a customer will send two text messages “This is my issue”… “Can you assist”… and the messages they send will be added on to two previously closed tickets, open them(due to trigger), and have no organization to them so we have to create a new ticket and copy their SMS messages to that manually and close the two opened tickets.

This is not an urgent issue. Thank you for your time.

Do I understand correctly that the particular sms is put to an absolute random ticket, not the last ticket of the customer?

Any special about the SMS? Something like numbers iniside? What does your follow up detection magic say ( see: )

The first statement is correct. We have a customer in our system that frequently uses the SMS feature. When they send an SMS sometimes it creates a brand new ticket and sometimes it will add to the end of “any” previous ticket they have previously sent (typically ones via email).

As for the follow-up settings there are not any that I can see for SMS inbound. Only for email which has the following detection set as shown below…

Thank you for clarification, looks like a bug, what do you think @thorsteneckel ?

Here is the logic that handles incoming SMS from Twillio. Just to be sure: Are you using Twillio @mikeal.walker?

As described in the code: The last Ticket of the Customer that contains an SMS and is not in a closed, merged or removed state type will be used for the follow up. If non was found a new ticket gets created.
I agree that this might feel random but at least it isn’t.

What would be a desirable behavior @mikeal.walker? How could we improve the follow up handling?

@thorsteneckel We are indeed using Twillio. One thing though is that we are seeing closed tickets be used for the new inbound SMS(which causes them to re-open due to an existing trigger). I feel this may be a bug… I also gather just from usage that the SMS ticket submission isn’t really a core option and that email or web submissions will always have greater functionality.

One thing I feel would be helpful is being able to send a text like “?tickets” and Zammad would reply back with a query of open tickets for that customer. Or if there was a way to parse the ticket number out of the inbound SMS and use that to specify which ticket you want this response to go to (in the case of multiple tickets open).

EX SMS: “12345 I need further assistance with this issue. It started happening again”

This would cause the response to go directly to ticket 12345 and not strictly following the hard coded logic. If there was just a way for the texter to explicitly specify what ticket they would like to respond to, that would be ideal.

Let me know if I can assist with any debugging of the issue we are having with closed tickets being opened with an SMS. I would be happy to provide examples privately so this could be investigated further.

Thank you for your time.

Hi @mikeal.walker - thanks for the follow up. Examples would be great. Would you mind sending an email to support at zammad dot com and referring to this post and me? I’ll have a look then. I’m specially interested in the history of the example ticket (screenshots would be great). One question: Have you changed your Ticket States in any way? Like adding, removing, changing existing states?

Yeah you kinda right. The SMS functionality was sponsored by a customer ( :heart: ) and we basically implemented their use case and shared it with the whole user base. You can read more about it here:

It’s sometimes hard and mostly faulty when I try to anticipate the use cases of our user base. So it would help me a lot to understand how you work and how the SMS functionality is part of it if you could write it down like:

As an Agent I want to be able to create a Ticket by sending a SMS to a Customer
As an Agent I want…
As a Customer I want…
As an Administrator I want…

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.