Just me, is the new 2500 character limit not going work for them?

Definitely would like to sternly request a removal of character limit on emails. May I get an explanation of why this was implemented? haha. My canned email with full details of work completed, recommended upgrades, and mention of upsells is now too long. I definitely feel this ties my hands with comprehensive email correspondence.
Thank you in advance!

I thought the same and decided that it was time for me to pare down my messages to be more to the point and focused.

Noone is going to read all that. You can barely get people to read at all anymore. They care about outcomes not details. If you need details for technical reference, make them internal.

I can’t even get people to read “Can you try rebooting it?”

1 Like

lol this is so funny yet so true.

I agree the limit should be eliminated. However, we never have really large canned responses. Typically have a summary there and a link to a Hudu knowledge base article that can be formatted pretty.

Users not reading is what keeps our help desk department in business. LOL.

1 Like

Suuuure, but then were are the details when the client later shows some sort of gruff about not being informed enough, or that you aren’t doing as many things as you lead to believe? That’s my personal isseu at least lol. Which is why I’m often called ab iver explainer. Mix of my inner broken child, but also my inner broken tech guy I’d imagine lol.

Yeeeaaaa, but that’s not the point. Not many people will “your” book, but they thumb through, then listen what you are trying to tell them in a video, words in person, or some other shorter form of communication or teaching. This is a conecpt in marketing and education to create authority and trust. It often is taken of advantage of, of course, however I’ve found good results in documenting the things I do and later citing all the documentation when the client attempts to the “deminish your product or service to equate to lower value of said product or service.” This is to break up, or lower price generally. Couldn’t count how many times citing the well documented processes of what was done removes the doubt they random thought of, or a friend/famiily member planted and water the seed of in their mind. Ya know?

Riiiight, but I’d much rather the choice, as opposed to being strong armed into it lol. I could also see an argument of “this is a great time to keep email brief, and then direct the client to the portal.” However, I feel it’s absolutely certain the client will have the same sense of forcing, and be aggravated they’re now requried to do the log in stuff and what not. But, perhaps that’s better in the long run, as then you’re teaching them to be in the portal for other possible benefits like paying a bill or … Not sure what the other benefits would be haha. Another angle however, is it’s much better to put the strain of people open and reading emails on email server, as opposed to more logins and use of portal syncromsp server? This endures more cost, that will eventually be passed onto us, and thus client… Oh the overthinking of technical people lol.

Also, are we to put detailed long form in portal, then compose sms/email? Extra step… Currently I have it down to a canned message with long form template, and sms short form template. Swap out some numbers, specs, findings, and recommendations, cut paste short form to sms and hit send. Pretty slick and efficient. But of course, doing this with one portal public message, then cut pasting same message to sms email to guide client to refer to portal isn’t then end of world or ridiculous extranious… Just something NEW and different. So wil take a little for my reluctant to workflow change mind to wrap around this perhaps haha.

Using a documentation portal like Hudu lets you use graphics and nice formatting that you cannot get in a basic canned response.

Strongly agree with the 2500 character limit not working. We have some long canned responses for common issues some of our customers face, that really don’t rise to the level of needing a tech if the customer is given instructions on troubleshooting it themselves. For example, we have a canned response that covers being unable to connect to a VPN. Often times, the user just needs to do something simple like change their password, be reminded that they don’t need to use the VPN while connected to their office’s internet, or a few other easy things. Its much easier to send that canned response than for a tech to schedule a call with the user, then chat with them briefly to give them the same instructions covered in the canned response.

We also commonly write lengthy emails whenever an executive at a company wants a detailed report of what progress has been made on a variety of tickets. Or, they have an upcoming large project and would like detailed information about a variety of ideas on what they would like us to do for the project or want to know how we could assist them. If the customer is asking for detailed information, they probably intend to read that email, or at minimum be able to reference the relevant information later on when they are ready to consider it. And even if they don’t read it all, they still requested the information and we obviously aren’t going to respond with, “Well since you likely won’t read everything you asked for, we’ll just send a shorter response.” So frankly, it doesn’t matter if a customer reads the emails we send or not. If we send them the information they want, at least we are covered in the future when they wonder why we didn’t explain something to them and we can point them to the email in which we did provide that information.

1 Like

Amen bruther. My sentiments exactly!

My guess (for what it is worth) is that the 2500 limit (which if being stored as UTF-32, 2500 characters at 4 bytes per character = 10 KB) is in place due to SyncroMSP trying to limit the storage used.
Same reason that only 10KB of the output of scripts is stored.

I don’t understand why architecturally it is a problem.
Data compression of text is extremely efficient and such text data I would have expected to be stored by reference in a slower storage blob (and cheaper blob) than the rest of the database which requires a high speed of access.

Of course searching that compressed text in cheaper/slow blob storage for strings takes longer, but it is still possible. Its a trade off between having more storage at a cheaper rate vs speed to search/display older stuff

1 Like

Should not have to wrap your business and processes around the platform. The platform should wrap around your business and processes.

2 Likes

Good technically speculation my good sir! However, I don’t think I’d be handle to handle that still haha. Need me long detailed emails! It’s email for goodness sake. That’s like microcents a dozen by now right? haha :thinking:

1 Like

Agree, I cannot think of a good explanation for the limits except for a cost cutting exercise, instead of investing in better software engineering.

So if we look at the AWS costs.
which are here. Amazon S3 Simple Storage Service Pricing - Amazon Web Services

Storage is $0.023 per GB for first 50 TB.
So lets assume that.
If the storage I used in Syncro was capped at 100 GB, that would cost USD $2.3 per month.
Lets add another $1 for retrievals to the internet (there shouldn’t be much)
Transfer in from the internet (from endpoints) is apprantly free according to the above site.

Working out the price is probably more complex than that, but we are not talking sheep stations here. Looks more like penny pinching.

Of course, if Syncro had integration with the Office 365 tenant used by the MSP, then they wouldn’t need to store the email anyway as they could likely pull the email from the Office 365 mailbox into the Ticket WebUI using MS Graph. I believe Syncro would only need to store the message IDs, and the {id | userPrincipalName} would already be known as that would be the inbound mailbox for the MSP.

Get message - Microsoft Graph v1.0 | Microsoft Learn
GET /users/{id | userPrincipalName}/messages/{id}

I don’t like the character limitation. The description field is not just for the end users, but also diagnostics for our techs. I would like to see that number be upped considerably as I’ve run into it a few times.