Service logs in JSM?

[Gaute Wardenær]

The company where I work have an internal discussion regarding where to log work, in the Atlassian ecosystem. 

We do AV installations and often do service and maintenance work at the customers location. I have been putting logs of this work in Confluence. The logs often look like: 

Technician: "name" 

Time spent: 2h 

Equipment worked on: LED wall and audio amplifiers 

"Updated firmware on the amplifiers and changed dust filters on bla bla bla..." 

The specific venue has its own confluence page, with a folder labelled "logs" 

My colleague strongly disagree with this method and says that I should rather create a new ticket in JSM, log all the information there and set the status to "done".

I believe that information should flow from JSM to Confluence, for storage and reference, not the other way around, but I am willing to change my mind, if there is a good case for using tickets as a logbook. 

Any thoughts? 

[Jovin]

Hey @Gaute Wardenær 

Great question and in terms of ways of working everyone has their own preferred method of doing so. 

My opinion is in alignment with your colleague - use the tickets to create, authorize, track and complete work, and confluence to track information on the clients' sites.

Benefits of JSM would be:

• Ability to actually estimate & log time spent on tickets, this could be done through the "Original Estimate" and the "Time taken" fields, and would allow reporting on how much work is currently scheduled, alongside how much actual time has taken.
• Ability to schedule the work - using the "Due Date" or "Start Date" fields you can specify the scheduling of the work, in addition, you could leverage automation rules to create maintenance tickets on a schedule as well.
• You could also create a service portal, allowing the customers to advise of issues in their site and you could then leverage all other aspects of the ticket to track that same information.

[Gaute Wardenær]

Thanks for your reply! 

It might just be me who find it unintuitive to create a ticket to log things that already has been done. I also find it unintuitive to schedule on-site work through JSM and not JWM. All our technicians have access to JWM, but only our office staff have agent access to JSM. 

But the things you are mentioning does make a lot of sense

[Rick Westbrock]

How does a technician know that they need to visit a site for an installation? If you were to create a JSM ticket as soon as it is known that a site needs an installation then that solves the "problem" of logging tickets after the fact.

Since you can surface Jira data pretty easily in Confluence by using tickets to track the work you should be able to configure a Jira macro on a Confluence page once and not have to touch it again.