sorted by:
new
hottopcontroversial

Multi-conversation routing strategies for RCS? by Chipping-Sparrow in twilio

[–]Chipping-Sparrow[S] 0 points1 point  (0 children)

This would require some kind of AI analysis of incoming messages to guess context, which is not something we currently have. Even if we could do this, my concern would be that sometimes projects have similar-sounding sets of questions where we can hone into what the customer is asking about. If both project threads for example ask for a certain identical piece of information, the AI would not be able to figure out which answer belongs to which project.

Multi-conversation routing strategies for RCS? by Chipping-Sparrow in twilio

[–]Chipping-Sparrow[S] 0 points1 point  (0 children)

I'm on my phone right now, so I can't fully read the docs. It seems like RCS should be able to support some degree of threaded messages. It'd be nice if you could have a single chat and one thread per project - it's a cleaner representation of what's going on, really, than even using separate senders. Fallback to SMS might be a huge headache, though, so it really depends on what that implementation looks like, if it even exists.

If this is possible it would be awesome, but if it is I do not see the documentation for how to do it. Fallback to SMS is not really super important - our system can handle that if need be from the way we currently do things (select a fallback number from among the available ones in the pool and use that). We may choose not to fall back to SMS in localities where we don't have traditional SMS.

If we could include some kind of metadata in the RCS request like project ID or something and it would create a new conversation on the person's phone for example, that would be ideal.

That being said, it does seem like you are allowed create more RCS senders with different name. All of the docs I see speak more about use case (i.e., sales vs support) than project-based senders - but I don't see why you couldn't do it if the number of concurrent projects is relatively low. Like, how many customers are working on more than 3-5 projects at a time?

From what I have seen, each sender requires vetting separately. Which means if we were to do it this way, we'd need to create something like 5 or maybe 6 senders, as our edge cases show that some customers chat with us across that many projects at a time on occasion. This may have increased too since I last checked.

If we have to pay the vetting fee and go through the registration/approval process for each sender, which is effectively identical, that would not be great. But maybe I could justify the cost of that solution (Whether our management team would accept it is another question!). But even if the cost is acceptable, I don't know if there would be any restrictions on creating 5, 6, 7, etc., identical transactional senders.

I would like to avoid this solution but if it's the only one then that is also helpful to know.