Announcement

Collapse
No announcement yet.

Ticket Creation/Flow

Collapse
X
 
  • Filter
  • Time
Clear All
new posts

    Ticket Creation/Flow

    Hi

    We are currently trialling CommitCRM.

    In the first instance, I would like to replicate the way our current call logging system (access database) works until we can educate the majority of our client base to log calls via email or the web interface.

    This is how it works currently:

    1. A team of users with very little technical experience will take a phone call and log the problem for the customer.

    2. These users will make a judgement as to whether the problem requires and engineer to attend or whether it can be dealt with remotely by the in-house technical team.

    3. If they decide the call needs to be dealt with by an engineer attending site, they will enter the call in the database and print an engineer attendance sheet.

    4. If they decide the call can be dealt with by in-house technical, they will place the call in a queue called "First Line".

    5. The in-house technical engineers monitor the "First Line" queue for new calls and will pull them into their own queue as and when they are in a position to deal with it. They determine which calls they can deal with themselves. There isn't a supervisor that tells them which calls to deal with.

    6. If the in-house technical engineer works on a problem and then determines that it will require a site visit to complete, they will "pass" the call back to the team that log the calls in step 1.

    Is it possible to replicate the "First Line" type concept in Commit? Would this be achieved by creating a user called "First Line" and initially making this the Ticket Manager?

    I hope this all makes sense.

    Thanks

    Re: Ticket Creation/Flow

    Thank you for posting this.

    There will probably be several different ways to handle this... anyway, please find a few ideas to explore and decide what works best for your team:

    * A Ticket that is for on-site visit - should be mark with "Show in Dispatcher" flag.
    This way, the ticket will get listed in the Dispatcher Window and you will be able to easily dispatch it to the relevant tech/free-time.

    * Each Ticket has a Type field, I believe that you can use that field for 'On-site' vs. 'First-line' settings.
    Then the first line technician will know which tickets to handle. And in case the ticket needs to be dispatched for an on-site technician, the first-line tech will change the type of the Ticket to 'On-site'.

    * Aleternatively, you can use Ticket Labels for this - create two labels 'On-site' / 'First-line' and label new tickets accordingly. Then the first line technician can easily see which tickets they should handle.

    * Another option -
    In case there is a complete separation between the on-site tech/s and the first-line tech/s (e.g. different technicians) then Ticket Manager is probably a good option to consider, meaning - assign the Ticket to the relevant tech (e.g. as the Ticket Manager) where each technician track and managed tickets assigned to them.

    Hope this helps.

    Comment


      Re: Ticket Creation/Flow

      Thanks for the suggestions.

      In-house techs and field techs are indeed different teams.

      I think this will demand some experimentation. I assume assigning a ticket manager is mandatory.

      When the call logger logs the call, they will automatically become the ticket manager? If that's the case, the in-house techs will need to change the ticket manager field to themselves when they are dealing with the call.

      Comment


        Re: Ticket Creation/Flow

        Yes, that the case, e.g. the Manage defaults to the user that opens the ticket, however, they can assign it to someone else during this process, so maybe the call loggers will be able to assign it and the in-house techs won't need to pull it. In any case, both options will work.

        Comment

        Working...
        X