Multi asset by ticket, how to?

[Rayman]

Hi guys I am in trial period, sorry if this question has already been answered.

Lets say a customer call to go check 10 machines. How to add more than one asset to a ticket, and particulary add troubleshooting notes to each one, as well to replaced parts?

Do I need to create a ticket for every machine? How about if the customer calls in and says have three machines with problems, but when the tech arrives he/she realizes are 10 machines with problems instead of three? How to add those machines on demand.

Regards,

[Support Team]

Thank you for asking. A Ticket should be created for each device separately. This is even more true when, as you described, technicians needs to write specific notes at the machine level. This way the entire service history for each machine (Asset) will be displayed under the Asset without mixing other Assets service notes and history.

Also, you can easily copy an existing Ticket to a new one - when you do - you can select the Asset you now want to link it to. All of the Ticket record details will be copied automatically.

Hope this helps.

[AN-Tech]

Commit, Can you tell me if there has been alot of requests for being able to multiple assets to a ticket? I know that we requested it many years ago and still would greatly benefit from this feature.

In our case because we cannot have more then one asset on the ticket we do not typically even use the field and instead record the computers worked on in the description, history notes, or resolution fields. It doesn't make any sense to create 10 separate tickets for identical work being performed on them. It makes much more sense to have one ticket with 10 assets tied to it. Currently to look at the history of a system we have to use multiple filters on the ticket list. It would make it alot cleaner and easier to just be able to select an asset and have a complete history tab.

[Support Team]

Yes, we have received other requests for this and we evaluate it from time to time. The level of complexity this adds is very high. Much more than meets the eye when initially suggested. Yet, we thank you for the feedback and this is not our last word on this subject.

[AN-Tech]

I can understand that it may be complex to update. I just hate to see features that go unused in CommitCRM because they don't support the way technicians do things. Being able to add only one asset to a ticket might not sound like a big deal but if you try to use it in the real world it just doesn't work, I'm sure many here would agree.

[Support Team]

We definitely understand and we've analyzed this business case already. The result is more open questions than we started up with, what might have result in making the system way more complex. For example, if one Asset is managed and another one is not - which Contract the Ticket is opened under? If the technician spent two hours - should you remove it from the block of time for one-off repairs, or is it covered by the managed contract? so, you can then split the Charges into many Charges but again, many will don't want to do that. Another example, the Asset lists its own history and tickets related to it, now if many different Assets are related to the same Ticket lot of history notes, charges and other performed activity might be listed under the Asset history even though it completely relates to another Asset under the ticket. There are plenty of other such questions that need to be answered before we go ahead and adding support 1:N relationship support between a Ticket and Assets. What we really try to avoid is making the system too complex with unexpected end user results. We've seen some implementations of this which are, well, really bad. We really try to avoid getting there... We're not saying that we will not be supporting this sometime, however, we do say that the design here is more complex than it seems. Rest assure that we definitely understand your requirements and needs here. Hope this makes sense and thanks again for discussing this with us.

[nattivillin]

Thanks for the breakdown. It helps me to put the request into a not easy to do category. Not just from your side, but from our side as well.

I often start with "how will this monster look when we're done?" It seems you have already pondered that.

When we do a checkup that involves many systems, we don't assign it to any of them. We create an asset called general, and charge all general support items that that.

[Rayman]

Thanks support, Is there any way to speed up adding tickets on demand process from a mobile phone? It may just be that the navigation design makes it feel adding more tickets takes so many taps and time. In fact the whole mobile website is clumsy . I gave it to two of my young techs that are pretty good with smartphones, and they said easily lose track of where they were creating a whole bunch of duplicates. Mobile website needs urgent work.

[Support Team]

As an alternative you can consider using the Email Connector with these advanced configurations - then - a technician simply sends an email to the RangerMSP Email Connector which in turn automatically converts it into a service Ticket under the identified account.

[raymond]

we also keep touching on the notion of adding multiple asset references to a ticket. since this can't be done, we simply don't link any assets to any tickets (it needs to be an all or nothing process or will quickly become useless information/work). When working on a ticket, we often touch multiple assets so this would definitly be useful. Even if it were initiated from the asset (right click in the tickets tab and select our new "link ticket" option).

On a side note, it would be super useful to be able to link a document to multiple assets.

thanks --

//ray

[extrascope]

Hi, we are in the process of evaluating the software and whilst we will most likely purchase, it is a major downside that we cannot add multiple assets to a ticket. It is so rare that we would attend a callout to carry out just one job. There are usually about 3 or 4 and that is then doubled on site. Adding all this information into seperate tickets is very time consuming and so we dont see ourselves using this feature.

Maybe it would be useful to have the system automatically create the additional tickets for you via a popu windows where you can enter asset, problem, resolution information for each sub-ticket. The sub-tickets can then inherit main information from the master ticket.

[Support Team]

Thank you for your comments and suggestions. It will be considered.

[raymond]

We had the discussion again in our weekly meeting and it seems that all our techs still come to the conclusion that linking a ticket to multiple assets is critical to being able to see and understand what is happening with that asset. All we want to do is build a history of what happened with an asset by linking any ticket that had something key about that asset – and it happens frequently that a ticket touches multiple assets. As far as I can see, linking a ticket to an asset has absolutely nothing to do with contracts or charges so talking about splitting charges doesn’t apply here. In fact, assets don't even have a contract field or custom charges tab!!

There is also mention of something about how the history information would become mixed and overwhelming... I'm not understanding this at all. Ticket history stays with the ticket... asset history stays with the asset. When these are linked, the history for each item should show when it was linked but that's it... there is no blending of the history from one into the other (it doesn't do that now) -- nothing changes! We look at the ticket list under the asset, review the ticket and if we need to get more details, we open the ticket and review that. Simple.

There seems to be a very simple resolution to all this: get rid of the asset field for tickets and create an asset tab just like there is a ticket tab for assets. Done!!!

Unless I'm missing something (and if I am, please explain what the asset field in a ticket does other than create a link back to an asset), this really is simple to implement (it's just a pointer list) and as you said, "we have received other requests for this and we evaluate it from time to time". Maybe it’s time to implement?

Thanks --

//ray

[Rayman]

We decided not to go with CommitCRM because of this. Every tech sees an average of 5 devices per visit, I cant always send the same guy for the next visit so we rely on previous history. Without a real asset history tracking my techs and I would be lost. I cant remember the number of systems I've tried and I see a huge lack of understanding from the software developer prospective of how a Tech day in the field is. They dont realize that three months down the road one have to go back to the same place and remember what the heck you or someone else did on the last visit, then waste hours troubleshooting something previosly diagnosed, that with proper software information could've taken 5 minutes. That really affects my bottom line, I know there is a smart way.

I may need to hire a developer.

Rayman

[aaspeer]

We would really like to see this feature added, we consider it one of the big features that CommitCRM is lacking (that and direct exchange sync support) Other than that, we are very happy with CommitCRM.

Austin Speer
Onward IT Consultants

[Support Team]

Rayman, I think that these may be two different items. RangerMSP does track the entire service history for each Asset. Simply visit the Assets Tickets tab and you get an entire list of all tickets that are related specific, and only to, this specific Asset. This way that technician should not spend the time reinventing the wheel for an issue that has already been handled for the device, they should simply review past tickets for this specific Asset, again, this is already supported and working well.

Actually, with multiple Assets per a single Ticket we are somewhat afraid of breaking this consistency. Supporting this will mean that when you visit the Asset History to see past Tickets you'll see Tickets that are also related to other Assets, not only this one, and this might be confusing when you open the Ticket and read its resolution only to find out that it has nothing to do with the Asset you're interested at. Having said that, we do see the point and how it may help to support multiple Assets per a single Ticket and we will evaluate our options.

Thanks for all your feedback.

[raymond]

Commit, as kindly as I can say it, you are simply not getting it... everyone here is saying the same thing: we need to be able to link a ticket to multiple assets so that we can quickly look at an asset and see ALL the work that was done to it. Six things to consider:

1) The concern "Supporting this will mean that when you visit the Asset History to see past Tickets you'll see Tickets that are also related to other Assets" is entirely a non-issue, in fact that is the whole point -- that's exactly what we want!!! Tickets get linked to an asset only if the tech decides it's relevant before manually linking it. THIS WILL EXPONENTIALLY IMPROVE ASSOCIATING AND FINDING INFORMATION ACROSS THE BOARD!!!

In fact, having it link to multiple assets might actually lead to a faster solution in the field! For example, if a tech works a ticket and they touch two obvious assets in the process (say a workstation and antivirus) then later realizes the solution involved an asset that nobody thought would be connected (maybe the firewall was the problem because it was blocking packets), then they may decide that the ticket really only needs to be linked to the antivirus asset and the firewall asset. The next time someone is having issues with antivirus, they would look at that asset and possibly see the link to the firewall... bam -- a much quicker solution!

2) The number of times that a ticket touches more than one asset is frequent... understanding this fact is critical!

3) The comment about "breaking the consistency" doesn't really mean much given that the current asset link in a ticket does nothing other than create a link... why in the world wouldn't you want to improve this function and expand on it? Does your phone only link to one person/phone number? When you search the internet, do you only get one result back? When you look at your credit card statement, do you only see charges from one vendor?!?

4) Again, remember that the tech must create the links -- if folks only want to limit things to a single asset, then they only link it to one asset!

5) The modification is super simple to implement: add an Assets tab to Tickets (just like there is a Tickets tab in Assets) and delete the Asset field in the ticket... super simple! Heck, I would then make a case to move the Contract field back up where the Asset field is so that it matches the same location it is charges (now we are talking about keeping things consistent).

6) This single modification will go a looooooooooooong way to improving the "search" capability for CommitCRM in a serious and global way... seriously!!

Please, (please, please!) allow us to link multiple assets to tickets...

//ray

[nattivillin]

I see commit's issue with breaking the consistency, from a programming POV. I just don't think they see how each of our tickets touch multiple assets and how we NEED it to be that way.

Just today i went in for a simple printer issue, and ended up touching 4 assets. The printer, and the 3 desktops that couldn't print. Since I cant link the ticket to 4 assets, what do we to doCommitCRM? Maybe that have a better way to do it that we are not considering.

Since we cant link them properly, we choose not to add the asset to a ticket that touches many. Otherwise we have no consistency on our end. This is definitely not ideal because if it happens again, i would like to click on the printer history and see there are several assets involved with this printing issue. This would help the next tech jump to the end of the trouble shooting because they can see what we did already with EACH ASSET.

This is an issue of programmer meets field tech. This is how we need to use it, so you have to figure out how to make it work :)

[raymond]

Being able to track technically what is happening to an asset is undeniably huge (as we are all saying) but there are other benefits to being able to link multiple assets to a single ticket such as when ordering maintenance renewals. For example, if we have 3 firewalls that need to have security services renewed, we create a ticket to not only track the charges (which is usually one single order times three) and labor, but also the order process and status (either by attaching documents, forwarding emails through the email connector or via history notes) – this lets us quickly determine if we have a quote, did it get ordered (from which vendor and sales person), was it delivered, etc. Unfortunately we can't link this ticket to all three assets which kills the ability for us to reverse lookup where we are in the renewal process of a specific asset... we have to remember what's going on or worse, hunt and peck through the client’s tickets to see what’s up... (yikes)! This renewals process happens ALL of the time, for both software and hardware assets...

And if I’m going to continue on this path, let's not miss tracking charges per asset... think about the power of this option: list all charges and filter on asset... WOW!!! Being able to see in a cursory way how much an asset is costing to maintain... just think about how powerful that would be when talking with a client about replacing an old workstation/printer/switch/firewall, etc. I fully understand that this last idea is much more involved programmatically because there currently is no way to filter charges by asset (yet) but just think of the possibilities... dang!

I keep coming back to what I think is the main point here: implementing this would be super simple to do (add an Assets tab and remove the Assets field from tickets) and have huge benefits.

thanks again!

//ray

[Support Team]

We do not argue with what you posted nor can or should we. We are here to service your needs and requirements. Yet, from servicing all users and helping and many different scenarios we do see several points where such a change might cause problems to users and this is why we say that we evaluate and consider this feedback.

For what it worth, from technical perspective things are, by far, more complex than what one may imagine - database, APIs, system reports and user customized reports, templates, forms, Web interface, Online Services, Email Templates, Quick preview, filters you define, etc. - are all referring to a single database field of an asset in the ticket. Plus, the RMM links will break as well as the plugins (developed by RangerMSP or by third parties) rely on the Asset field being a field in the Ticket.
A Multi-Asset per Ticket will completely break this and will require plenty of changes both from our side, 3rd parties (RMM) as well as from user perspective (all of the custom reports/filters/online-services/etc. you configured for tickets that are based on the Asset field).
Naturally we've handled more complex cases, however, we wanted to clarify that it is a much larger project than it seems and therefore it is being considered in comparison with other requests.

Thank you all for keep posting your feedback. We highly appreciate it and learn from it.