Follow

Break Fix Calls

We often find clients where there are no or few Calls with CM call type category. Corrective Maintenance type calls should be used in every break / fix situation and many reports, including ours, depend on this. Any call that is a break/fix call whether on contract or time and material should be in the CM category for these to work properly.

CM_Call_Type_example.JPG

CM_Call_Type_example2.JPG

 

Installs and scheduled PMs are NOT break fix calls. 

DUMMY CALLS FOR LUNCH, TRAINING ETC. SHOULD NEVER BE CM CALLS.

See here for a suggested list of call types.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

1 Comments

  • 0
    Avatar
    Mike Kirkpatrick

    Actually…that little category drives a LOT of functionality within EAutomates Reports when it comes to response time targets, callbacks, etc.

     

    Basically,

     

    CM (Corrective Maintenance) is DGI speak for ‘Break/Fix’…meaning the equipment/system is having issues and is not operating correctly.  EAutomate’s (and CEOJuice’s as well) reports only report response time as a performance metric on CM category calls.  So any calltypes that you do not want to impact your response time standard report measurements should not be assigned the CM call category.

     

    PM (Preventative Maintenance) also drives functionality within eautomate to help identify if a calltype was for PM or not.  The Eautomate Callback / Excessive calls alerts on the service call will trigger on CM & PM calltypes only, so again, calltypes for PM’s should be assigned to the PM category.  Response time is tracked of course on all calls, but the ‘Response Time’ number in the service management reports are again only reported on CM calltypes.

     

    PF (Phone Fix) which represents when a call is resolved over the phone and did not require a tech on-site.

     

    SH (Shop Call) for calls done in-house (assembling new equipment/rebuild demos/depot repair etc).  These call types do not impact response time reports and/or callbacks.

     

    IR (Install/Route) for delivery calls where equipment and/or supplies are delivered and no BreakFix/Repair/PM work is done.  We use the dispatch module here at SOS for the whole delivery process and all our delivery/pickup call types are assigned the IR category

     

    CC (Courtesy Call)….where a tech might do a ‘driveby’ call at an account that was not triggered by the customer.  Again, courtesy calls do not impact response time and/or callbacks.

     

    O = Other…because sometimes the softare companies cannot create a category for every possible calltype dealers might run..so you would assign this ‘Other’ for any other misc calltypes that you might want to use for internal reporting but where the calltypes do not fall into any of the other system defined categories (and of course your Other calltypes won’t impact response time / callbacks etc).

     

    One that new users feel is missing is “Rescheduled”..but that is not really a ‘calltype’.  A Rescheduled call is just that…a call that was ‘incompleted’ in eautomate (meaning tech had to leave the site but the repair is not completed) is tracked ONLY if techs are incompleting calls, which creates a call thread linking the first call to the second/third/etc calls until the call can be completed.  Many new clients think we find are having the dispatchers and/or techs change the calltypes to something like ‘Rescheduled’ or ‘Rescheduled for Parts’..but that is not a good practice .  Eautomate (and our ceojuice processes/reports) work off of the system process of incompleting a call in eautomate using the incomplete code, which automatically creates a second call (and starts the thread), and we can recognize that this process was used and that’s how we both see a rescheduled call in the system.  So in all our reports and/or the DGI GUI when it shows ‘rescheduled call’ it sees a ‘PreviousCallID’ in the backend database on the call record and that is a Reschedule.  That column/value is updated  by the GUI internally only when the incomplete call step is used to trigger the next call.  Just thought I’d mention that as it’s one thing we see most often skipped with new users…they close the first call and manually create a new call and they use a calltype they create for ‘Reschedule’…then they wonder why all of eautomates reports are wrong! 

Please sign in to leave a comment.
Powered by Zendesk