Came here looking to vote on adding rich formatting to ticket comments. Ran out of votes, but there are a lot of other good ideas here as well.

Customer skim ticket updates or don't read them at all. We'd love to be able to draw attention to certain parts of a message. The signature option for logged in user would be awesome as well.

First off I did not read all the comments but I am sure I agree with most of them. This is another place that needs some improvement.
-Use of color fonts
-Bold and underline
-HTML edited canned responses
-Emojis would be fun.
-# hashtags labels

I see that this concept has been implemented elsewhere in RepairShopr. What is the status of implementing it within the Communications area?

@Troy: So can NOTHING be done? We're at square one right now, so ANYTHING would be an improvement... Surprise us?

I like the part about having a signature for the logged in user for outgoing communications. So...maybe there could be a place in settings that was formattable, like Canned Responses, that could be added to a client communication or ticket comment. ?

@ryan - they are helpful to illustrate some of the original posts points, but the post specifically calls out asking for a WYSIWYG and wanting HTML in ticket comments and that was not mocked. You need to show rich HTML like a newsletter, paypal receipt, etc in the ticket comments area, ticket template, etc.

@Troy: How about exactly what I mocked up? With the exception of two changes in the comments, a fairly large number of votes have been cast following my mocks. The biggest question is rather or not to keep two separate comment boxes; which IMO wastes space and is unnecessary when a [blank] drop-down would force the delivery audience to be specified; therein eliminating incorrect delivery.

As for the HTML subset - how about exactly the same as used in templates on the backend? I think it's obvious that the majority of RS users don't want flashy colors and cat emojis; but instead want some BASIC features like bold, list bullets, and font sizes. As you've said before, why not deliver a feature that is a not-perfected improvement, and then perfect it over time - like everything else in RS seems to be?

@Adam: THANKS!
@Chad: Agreed!
@Chris: The default would be NOTHING so it would be required to set it as Public vs Private
@RS: Any updates on this? Almost 2 YEARS with NO UPDATES of any kind?!

Ryan, your mockup looks great. Only thing I might add is the ability to specify which technicians to CC instead of just a check box.

And RS, please get on this!

As a manager I think something like this is definitely needed. We used Connectwise before and when I had questions about tickets or wanted technicians to look at tickets, I'd create a comment and cc: the technician on it. Sometimes this would be to elaborate on a ticket or just review it. Now I have to go through another step to forward a ticket to a technician, and there is no documentation that I contacted the technician.

I still consider this to be the best solution to this feedback request. Please everyone provide some feedback if you think differently, or remind @RS we really have wanted this for over a year. http://i.imgur.com/AicNdtP.png

@Everyone: I've just finished up my mock-up of the actual view of ticket updates. It's a rough draft only because I'm busy - but I really wanted to let everyone see:

http://i.imgur.com/KN4MzIM.jpg

This would cover the following:

Was the ticket update emailed or not?
Who received the email?
Was a sub-contact or CC emailed?
Sending to the tech only and not the customer.
Colors defining who was messaged and in what delivery fashion.
Is the ticket comment public in the portal/PDF?
Ability to edit private (non-emailed) notes.
Ability to change which tech receives the email.

@Chris: With my mock-up, the default settings in the drop-downs for public/private will be [BLANK] which would require techs to always specify how and to whom the message is shown to. Although this is manual (which I hiss at the thought of), I think every ticket update is unique and some need to be emailed to the techs only, others to the customer only, others to no one at all, etc. With this setup, techs will always have the question in their mind ("Who needs to get this message?") before actually submitting it. I think this will result in customers getting only the relevant emails they need, and not getting bombed with unnecessary updates.

Further, it provides more power to email staff-only, without sending the customer unimportant updates. I tried to design the mock-ups to add as much power/features as I could, while being as space saving as possible. Not sure how else we'd have room for signatures, attachments, canned responses, Cc/Bcc, and WYSIWYG with two comment boxes. Really came down to not wasting space (duplicate text boxes) if possible. Your thoughts?

I don't like the idea of combining the private and public. We like to make sure its a private noc regarding the ticket and we know the one side is private and we can type quick and not have to worry about a drop down box or a checkbox to make sure its private. That could be a very bad mistake depending on the situation. I like the idea of cleanup but not sure this is right and surely not for us. I DO like WYSIWYG

@Troy: Is there any update on this topic? This isn't necessarily a big deal in itself, but it is a prerequisite for updating/fixing other modules in the app, including things like:

- Ability to identify/differentiate between comments that were emailed vs not emailed
- Editing private ticket comments, or public comments that were not emailed
- Audit tracking who exactly was emailed (if multiple contacts exist)

Completely agreed with all of these update suggestions. I have created two mock-up variants of a solution that allows for all of these requests to come alive AND MORE! Some of the features in this include:

Add assigned contacts (linked contacts under that customer) as a CC email
Add external contacts (not in your database) as a CC email
Eliminates the side-by-side duplicate text field boxes
Adds all standard WYSIWYG features (already being used in templates editor)
Allows signature to be inserted (just like canned responses)
Allows files to be attached via drag-and-drop into the message

Here are the mock-ups:
http://i.imgur.com/AicNdtP.png
http://i.imgur.com/HwxFXH6.png

In addition to all of that, my BIGGEST idea is to upgrade is the comment DELIVERY AUDIENCE and VISIBILITY METHOD. Right now, there's just Public and Private, with the option to not email on Public. These are only 3 delivery scenarios out of a total of 6. We need to be able to specify exactly WHO gets the message, as well as HOW the message can be viewed. Here are the details…

What we have:
Public comments emailed to everyone (both customer and tech)
Public comments emailed at no one
Private comments emailed to no one

What we don’t have:
Public comments emailed to the customer only (tech doesn’t need informed)
Public comments emailed to the technician only (customer doesn’t need informed - rare)
Private comments emailed to the technician only (communication about problems/customer)

This is the ANSWER! It solves ALL of the issues we have! Let’s make it happen 

I agree with Chris; don't make it easier to make a mistake and send a comment to the customer that they should not receive.

Personally the whole platform could benefit from WYSIWYG functionality in a number of places.

For what it's worth:
1) I can see that being useful on occasion.
2) I think this is how it used to be and it's not nearly as good. You have people forget to check the box or vice versa and email are going out that aren't supposed to. I prefer the way it currently is with separate boxes.
3) Personally, I don't see a need for this.
4) Again, not something we would use.
Attachments, however, would be useful.

I'm actually in the beginning stages of mocking up a complete revamp to the ticket comments section. It covers a lot of the same topics mentioned here, as well as defaults that force users to specify important details like: whether the comment is emailed or not, as well as specify what the comment type is. Too often our users are emailing a comment without changing the comment type.

I expect to have this done in the next week or so. Stay tuned.