Emails sent from CommitCRM

[AN-Tech]

Can you consider adding the ability to specify what email address is used when sending emails fromCommitCRM?

When we close our tickets we click the send email button from the ticket. This creates an Outlook email that we modify to clean it up a bit. We then manually change the From address in the message to be sent from help@ourcompany.com. This way all replies go to the correct place.

It would be helpful if we could specify in CommitCRM to do this for us. One less step for us to do and less likely to make a mistake and forget to change it when sending the email.

Thanks

[Support Team]

Hi ascendnet,

I hear you and I understand what you mean. Outlook allows working with several email accounts and you can manually choose which one to use as the email sender whenever sending an email (via Outlook). Having this option defined in RangerMSP sure sounds like a helpful feature, although I'm not sure this is that simple to implement. I'll pass this on to the developers to think about...

In any case, have you considered changing your default account to be using the support email, in order to avoid mistakes? I know this may create problems when you wish to send emails from your personal account, so it basically depends on which way is more common for you. Note that when replying to emails, the correct account will be used anyway...

Thanks again for your suggestion!

Ethan

[AN-Tech]

I use my regular account for too much to be able to default it to our help@ account. This shouldn't be a problem when CommitCRM is handing all of the incoming and outgoing email correspondence related to tickets internally as opposed to using Outlook.

Hint Hint Hint

[Support Team]

Got it :-)

[jtfinley]

This is why we started using another ticket system, Kayako, to handle all our ticketing. This is something a couple other CommitCRM users and I have been poking/prodding for them to implement a better ticketing system to allow replies from any device. We are not always at our PC so replying to customers from our cellphones, any computer for that matter without needing "Outlook" is what drove us to implement Kayako. I HOPE, CommitCRM will implement something like this...

[Support Team]

Thanks for your input jtfinley, and for letting us know how we can help.

The good news is that we're currently enhancing the various emailing options which already exist in the system, and we are actually adding some options to support email threading (i.e. to make it possible to file all email communication re a service ticket under the ticket). The current changes are making their way to the coming 5.1 release.

Neta.

[ajgyomber]

Yippee! :) That will be awesome.

[jtfinley]

Neta,

Will these enhancements include the ability to reply from any where? For instance, when a "support@COMPANY.com" email comes in, Kayako, then forwards it to tech's emails with a special subject header that get's stripped when we reply back that way it can keep track of the emails. This ability is a MUST for us and I'm sure MANY MANY others. What I have to do now after a ticket is about to be closed it FORWARD it to COMMITCRM and then in a way double entry the description for charges.

[Support Team]

jtfinley,

The way it will work in RangerMSP is probably different than the way it works in other systems as each system is different and tries to achieve different goals.

I general, a technician will be able to send a copy (CC/BCC) of their reply to the customer to the RangerMSP Email Connector, which will receive the email and file it under the relevant ticket in RangerMSP.

Detailed information on this will be published once this feature is released.

Thanks,
Dina

[digitalminds]

I concur with jtfinley.

So with the 5.1 CommitCRM release, if a tech forgets to cc or bcc support@company.com (for the email connector to parse it) or to forward the replies back from a client/customer which will be sent to the tech's email address joetech@company.com (per your description above) to support@company.com, the communication is not logged. Did I understand correctly?

[ajgyomber]

I would imagine that if you can't update a ticket and automatically have it email the client with the change and if the client responds via email and it doesn't get added to the existing ticket and change the status from hold or something there will be complaints. I will be one of them!

[Support Team]

@digitalminds - with RangerMSP emails are sent using your email client, usually Outlook. If the tech's communicate directly with the customer using the tech's personal email address, other than the public support email address (the one the email connector automatically tracks and processes) then the technician needs to BCC/CC the connector in order for this communication to be automatically filed. In any case, the technician, as an employee in the system, will be able to forward a message to the connector which will automatically file it. Or, you can always drag the email from your Outlook and drop it on the Ticket in RangerMSP so it will be filed.

@ajgyomber - the email threading with 5.1 handles email sent by technicians to customers and incoming email sent from customers to you. Emails will be filed under the Docs tab of the ticket. Changes to the ticket details will not automatically send an email to the customer. The technician is in control and the technician is the one that decides whether there's a need to send an update email to the customer when a ticket is modified

Thanks guys for sharing your thoughts on this. We believe that the new email threading feature in the coming 5.1 is great and that it will help many of you. Anyway, I don't think it'll cover everything and every possible scenario... but, like we always do, we'll be carefully listening to your feedback and implement the relevant changes.

Dina

[Easy I.T.]

to CommitCRM Support - I praise you guys on trying and listening to our feedback- but the solution you guys are implementing i dont believe will be any great help to anyone. As when the Tech replies - it will come from their own email address - and then if the end user replies - this will go to the tech and the email trail will be lost.

If you insist on using outlook and the connector there is maybe a way around it. What Cerberus helpdesk does. ->

When an email comes into support@supportcompany.com and then is assigned to techuser@supportcompany.com - the email address support@supportcompany.com is always used. So the tech receives an email from support@supportcompany.com (instead of end user) - when he replies - he replies to support@supportcompany.com and then the helpdesk software parses the email and in turn files it/adds it to the thread and also forwards it to end user from support@supportcompany.com instead of techstaff@supportcompany.com - This is just one option which allows the use of the tech users outlook client instead of the webinterface - ofcourse they can log into the helpdesk software and send emails from within the web interface (Which would be nice if CommitCRM could do this)...

The ticket is then all threaded nicely - on one page - instead of attachments - is CommitCRM planning on doing this or sticking to the attachments? - which make me not want to use it - (i would have to open 5 seperate emails just to see what i could be displayed in one page of threaded emails)

[ajgyomber]

Ticket threading does NOT equal email threading. I don't want email threading as I already have that with Outlook. What I want is when I update a ticket that update gets sent to my client through CommitCRM from my support@company.com email address. If the client clicks reply and gives us some information related to the ticket, I want it to insert that information into the ticket notes and notify me there was an update. This is pretty much how every other ticketing system works.

[Support Team]

Thanks Easy I.T. for the interesting feedback on this.

RangerMSP 5.1 will soon be released (Beta) so you'll able to actually see how it works.
It will work differently than you described though. RangerMSP Email Connector will not serve as a central email hub that manages all email traffic. It will "simply" file all email communication, going through your public support email address, and is related to a specific service ticket under this ticket.

With what you describe the customer always communicates with the support@supportcompany.com email address (this is what we call the Public Email Address). It works the same with RangerMSP. You'll just need to make sure technicians have access to this email account and that the send replies/emails to customers using this email address (instead of their own email address). This way customer replies will be processed by the email connector and filed and only then forwarded to the internal support email address.

That said, we understand that it doesn't cover all scenarios and we will probably add more features and options in the following releases. We do believe it will help many users even w/o any additional options and this is why we prefer to release early while embedding the required changes in future releases.

Hope this makes sense.

Doron

[dyntech]

I am strongly considering buying CommitCRM and have been wondering if there is a way to "interface" it with my existing Kayako ticketing system. I have done the trial version of CommitCRM and think it is a wonderful tool and does a great job of what it does, however I also think from what I have read in the forums, that it needs to be "opened" a bit. I see there is starting to be some connectivity to some of the MSP platforms. Most of your customers are already using a MSP platform and would prefer to keep using it along withCommitCRM. The same goes for other ticketing systems.

I do not believe that there is or even should be one piece of software that can run an entire business. I want to be able to use the best piece for each part of the business. CommitCRM does a great job with the CRM part and I think Kayako is the best ticketing system out there. I just wish there was more interoperability between the two. Maybe CommitCRM could "license" the Kayako ticketing system or at least work with them or other companies to achieve this.

The end result will only be a better product and happy customers.

[ajgyomber]

Funny that I sold Kayako to move to CommitCRM as I felt it was better suited for the business model.

[Support Team]

Thanks for your comments dyntech.

We believe that we're pretty open.

We publish an API to the RangerMSP system.
Using the API developers can write programs that do a lot of things. Integrating with other systems should quite easy using the API.

Using RangerMSP's API you can - add and update - tickets, accounts, assets, charges, appointments, tasks, history notes, documents etc.

We also offer full access to our database for read only purposes. This means that using SQL you can query and fetch any piece of information stored in the RangerMSP database.

If you prefer to use another ticketing system and sync the tickets with the ones in RangerMSP you can write a plug-in using our API that'll sync the info.
You'll just need to check whether the other system is open as well and will let you integrate with it.

I hope this shed some light on the subject.

Dina

[lpopejoy]

I'm sure my comments are premature, but...

While I applaud your efforts at responding to user requests (as someone has already said), this is NOT what we need. The solution I'm seeing is ridiculous. This is almost equal to what we had before. Why can't you figure this out? WHY does email have to be stored in clumsy email files that have to be filed in the Client's documents? Can't you see how crazy this is? So now I am going to have to go searching through 100 emails to find that one document that contains license info? ...or network documention... etc...

Listen, this is a great start, but why didn't you do it right to begin with? Maybe I'm missing something, but a BCC or a CC to support@mycompany.com does not fill the bill.

We need a REAL email/ticketing system.

I am about ready to hang it up and go find a better solution.

--Luke

[lpopejoy]

Oh, and by the way, I think if you would have asked ANYONE on this forum what they thought about your idea... You would have gotten 95% of the people saying just what I just said. I've been hanging on to this hope that you guys would get this stuff right... Now... I'm starting to doubt the wisdom of that.

[AN-Tech]

I was just asking for the outgoing email to say help@ourcompany.com :-)

[lpopejoy]

Lol, sorry, I guess we got a little off topic! :/

[AN-Tech]

Just trying to lighten it up a bit :-)

[jtfinley]

Easy IT, DigitalMinds and I are asking for an email broker to manage the emails. I use Kayako, Easy IT uses Cerberus. I think many are missing the point here. We are not ALWAYS sitting at our desk using Outlook. I personally use an iPhone. I MUST be able to reply from any client, Web/Mobile Phone, anywhere and tracked. Quick and short of it, tickets from customers come in via "support@MYcompany.com", Kayako picks it up, processes it and sends to my "jtfinley@MYcompany.com" with a REPLYTO as "support@MYcomany.com". When I reply, it goes back thru the ticketing system and Kayako again, parses it, and sends it back to the customer as "support@MYcompany.com". Kayako knows who the customer and who the tech is. I don't want to have to CC, BCC anyone. Kayako takes care of all of that for me.

Either we're having a understanding/communication barrier or I and others haven't explained it well enough, but this MUST be in COMMIT for myself and appears many other users to effectively run our business.

[jtfinley]

To expand more, with the way CommitCRM is setup now if a "contact" is not registered under an ACCOUNT, the email goes to a designated person or mailbox. I have customers who have 150-200 users. All of them send emails to "support@MYcompany.com", I CANT sit there and enter every EMAIL to make sure a ticket is created under the correct account. With some of their turn-over, we would spend more time adding/deleting Company Account Contacts than generating business. This is why it's SOOOOO important that whoever the email is from, a ticket is generated. If we could parse the email before creating the ticket based on "@DOMAINNAME.COM" or something, this would then place under the correct customer account.

[ajgyomber]

Dear CommitCRM Team:

I think this area is definitely a hot spot for most of us in the industry. Tickets are how we prioritize and managed our workload. I also think you can see that the most of the individuals that read this forum seem to feel that you are missing the mark on how to handle tickets and the associated emails generated by them. I think everyone will unanimously agree that there should be no need for Outlook or and special configuration as all that gets thrown out the window when you work through the web interface.

My suggestion is start with the foundation of we shouldn't have to go anywhere else besides the CommitCRM ticket interface to communicate with our customers. If you implement anything based on that then you'll be pretty close to where we all need the application to be.

Personally, I think it is pretty simple equation. When a technician updates or creates a ticket, the have the ability to AUTOMATICALLY send an email confirmation through the email connector. If a client responds via email, the ticket should AUTOMATICALLY be updated and moved off hold status. Customers want to know the status so it's pretty apparent that their should be an automated way within CommitCRM to send out emails through its SMTP capability.

Tell me we'll be able to accomplish that in 5.1 and I'll be a happy camper.

--AJ

[lpopejoy]

I think the CommitCRM Team is on vacation from this thread! ;) Anyway, right on, AJ!

[jtfinley]

AJ -- Exactly! It drives me nuts having to use another product for this seemingly simple capability (Ticketing). Right now, and to refer back to Kayako, but when a customer responds back after our response, the ticket is put into a "Received-Customer-Feedback". That way any techs looking at the queues know a customer responded. We also set up the queues that show techs that respond sends the ticket into a queue "Awaiting-Customer-Feedback".

[jtfinley]

Luke, I think if CommitCRM Team nails this ticketing integration, allow importing/exporting of Activity Templates, and importing of Assets from various MMS tools (Kasaya, N-Able which I use) they will have a well-rounded product.....

Their support is always responsive and a joy to work with....

Joe

[Support Team]

Guys,

Thank you for all the great feedback. You are really helping us design the future of RangerMSP, its features and making it a better product.

We hear you and were internally discussing this again quite a lot during the last few days.

RangerMSP 5.1 will offer nice features including ones for email threading. However, as stated, what we'll offer incorporates some different thoughts and ideas on this.

We were thinking about delaying the 5.1 release and implementing the additional options required to support the ideas and scenarios suggested in this thread.
Finally we've decided not to delay the release as we believe it includes useful email threading capabilities and other features that can help users today (we did not want to hold back new features which are ready to be used...).

Features that better reflect the scenarios suggested here will make their way into 5.2 (we actually already started working on those).

Thanks again for sharing your thoughts and taking part in this discussion.

The RangerMSP Team

[AN-Tech]

Can you please explain a bit more about what you are calling email threading? My vision of email threading is where you can easily see the chain of corresponse both incoming and outgoing. But from what I've read here it sounds like each email is still just going to be kept as a seperate entry on the doc tab like it currently does. Maybe I'm not understanding what you mean when you say email threading. So if you could describe it better I would be greatly appreciated.

Thanks

[lpopejoy]

CommitCRM Support,

Thank you for your response. I really appreciate the effort that you guys put into listening to community feedback. It re-affirms my decision to use your software as a PSA tool.

I'll just try to be patient now and wait for 5.2!

Thanks a lot!

Luke

[ajgyomber]

The CommitCRM team seems has been historically responsive to their customers needs and I think they hear us loud-and-clear on this issue. I suggest we let them focus on releasing 5.1 and then 5.2. If they are telling us it will be in 5.2, then I'm sure by then they'll have a way of handling tickets that doesn't require Outlook.

--AJ

[Support Team]

Thanks guys.

@ascendnet -
"separate entry on the doc tab" - 5.1
"chain of corresponse both incoming and outgoing" - 5.2

[digitalminds]

CommitCRM Support:

Thanks for listening to our needs. Will we be able to reply to email threads from the web interface in 5.2?

[Support Team]

digitalminds, this is a good point and we'll be looking at it as well. Thanks.

[jtfinley]

CommitTeam: I'd be more than happy to open my current ticket system so you can take a look as how it operates. Just let me know.

[Support Team]

Thanks for the kind invitation jtfinley.
I believe that we will contact you directly with this once 5.1 is out...

--
On a side note, you can apply to join 5.1 beta here (link removed)

[Easy I.T.]

Hi CommitCRM Support,

Are you able to update us on the plans for the next release and what email/ticketing will features will be implemented?

It would be really great if:

proper threading (Not doc attachments - as lpopejoy said having 100's of emails in the docs is crazy)

ability to send updates independant of Outlook - from within CommitCRM client and Web interface. (And option to automatically send updates if ticket is updated [or a tickbox within ticket] )

ticket escalation - We need the ability to set SLA's and alert us when a ticket has not been responded to accordingly

"Email Broker" (for use when using outlook) as jtfinely describes. (tech shouldnt have to remember to BCC CommitCRM and change his/her from address)

were all implemented. I, and I am sure many others would be very happy :)

Cheers,
Jeremy

[Support Team]

Jeremy,

Thank you for following up.

Yes, we are heading in this direction and plan to implement many of the ideas mentioned in this thread.

You'll probably be able to use these enhancements in 5.2 :-)

On a side note: The referred "5.2" may be renamed to "5.3" - name changes only - this will be the case if we'll be releasing another mid-term version sometime during the next few weeks - we hate holding new features which are already ready, so we consider releasing them as 5.2 instead of holding them until the originally planned "major 5.2" is ready.

Doron

[jtfinley]

Doron,

Good to hear. An added note, what would be the best approach for "devices", literally, equipment sending alerts to create a ticket (Firewall, switch, cameras) and not having Commit's Mail Connector stop due to the mailbox it came from does not exist?

[Support Team]

Jeremy,

RangerMSP Email Connector doesn't stop if the Sender email address is not recognized. What it does is forward this email to your support staff for manual review.
In general, devices that sends emails can be configured to send emails using the Customer email address (any email from the customer domain) as the Sender - in this case a ticket will automatically open for the customer, or, if you can control the email content format, use the Automated Emails feature of the email connector to automatically identify automated emails from different devices, identify to which customer they are related to and open the relevant service ticket. Review the email connector documentation for detailed information on this.

Doron