TM Forum Community

Hi

I am working on trouble ticket and we have this requirement to be able to capture specific data while creating the ticket. Each Ticket Type can have different data to capture. We want to help the CSR understand what information is needed when opening one trouble ticket.
For example, we want o capture the Bill ID number when opening a dispute bill ticket.
I am thinking that this kind of information is good for characteristics. However, there is no such relation between TT and Characteristics.
Could we add such relation in the model?
Is there some specific reason you thought that this is not needed?

thanks.
#CustomerExperience
#General

------------------------------
Panagiotis CHristodoulou
Amdocs Management Limited
------------------------------

Hello,
Not sure who owns the management of that particular specification but I would agree that some form of extensibility might be helpful.
I see that Service Problem Management has characteristics for the problem as a whole (the authors give an example of "cost" as a characteristic).

If adding Characteristics though I think one needs to give some thought as to where such as a structured approach to extension is required. By that I mean what are the actual things you are capturing the "characteristics" of? Otherwise characteristics become a bucket of anything that people want to add to the ticket and that can degenerate in a mixture of unrelated name value pairs  in a list.

Where I have seen such an extension mechanism is in providing a structured means of describing the nature of the trouble experienced rather than just a free text description. The characteristics then represent a way of following a script of diagnostic questions relating to a specific combination of product and trouble type followed by questions to capture specifics of the trouble experienced. So, for example, a broadband speed problem might have a question asking "Is the problem continuous or intermittent?", if the answer is "Intermittent" a follow up characteristic might be "Describe the pattern and frequency of the problem".

Also on the specific example you give, TMF621  gives an example of using relatedEntity to capture the id of the disputed bill.

"relatedEntity": [
{
"id": "3472",
"href": "https://mycsp.com:8080/tmf-api/customerBillManagement/v4/customerBill/8297",
"name": "March 2019 Bill",
"role": "disputedBill",
"@type": "RelatedEntity",
"@referredType": "CustomerBill"
}
],


------------------------------
Derrick Evans
------------------------------

Original Message:
Sent: Nov 26, 2021 02:16
From: Panagiotis CHristodoulou
Subject: Trouble Tickets and Characteristics

Hi

I am working on trouble ticket and we have this requirement to be able to capture specific data while creating the ticket. Each Ticket Type can have different data to capture. We want to help the CSR understand what information is needed when opening one trouble ticket.
For example, we want o capture the Bill ID number when opening a dispute bill ticket.
I am thinking that this kind of information is good for characteristics. However, there is no such relation between TT and Characteristics.
Could we add such relation in the model?
Is there some specific reason you thought that this is not needed?

thanks.
#CustomerExperience
#General

------------------------------
Panagiotis CHristodoulou
Amdocs Management Limited
------------------------------

I agree the example I specified was not the most obvious one. I am interested in  "an extension mechanism is in providing a structured means of describing the nature of the trouble experienced rather than just a free text description".

------------------------------
Panagiotis CHristodoulou
Amdocs Management Limited
------------------------------

Original Message:
Sent: Nov 29, 2021 12:20
From: Derrick Evans
Subject: Trouble Tickets and Characteristics

Hello,
Not sure who owns the management of that particular specification but I would agree that some form of extensibility might be helpful.
I see that Service Problem Management has characteristics for the problem as a whole (the authors give an example of "cost" as a characteristic).

If adding Characteristics though I think one needs to give some thought as to where such as a structured approach to extension is required. By that I mean what are the actual things you are capturing the "characteristics" of? Otherwise characteristics become a bucket of anything that people want to add to the ticket and that can degenerate in a mixture of unrelated name value pairs  in a list.

Where I have seen such an extension mechanism is in providing a structured means of describing the nature of the trouble experienced rather than just a free text description. The characteristics then represent a way of following a script of diagnostic questions relating to a specific combination of product and trouble type followed by questions to capture specifics of the trouble experienced. So, for example, a broadband speed problem might have a question asking "Is the problem continuous or intermittent?", if the answer is "Intermittent" a follow up characteristic might be "Describe the pattern and frequency of the problem".

Also on the specific example you give, TMF621  gives an example of using relatedEntity to capture the id of the disputed bill.

"relatedEntity": [
{
"id": "3472",
"href": "https://mycsp.com:8080/tmf-api/customerBillManagement/v4/customerBill/8297",
"name": "March 2019 Bill",
"role": "disputedBill",
"@type": "RelatedEntity",
"@referredType": "CustomerBill"
}
],


------------------------------
Derrick Evans

Original Message:
Sent: Nov 26, 2021 02:16
From: Panagiotis CHristodoulou
Subject: Trouble Tickets and Characteristics

Hi

I am working on trouble ticket and we have this requirement to be able to capture specific data while creating the ticket. Each Ticket Type can have different data to capture. We want to help the CSR understand what information is needed when opening one trouble ticket.
For example, we want o capture the Bill ID number when opening a dispute bill ticket.
I am thinking that this kind of information is good for characteristics. However, there is no such relation between TT and Characteristics.
Could we add such relation in the model?
Is there some specific reason you thought that this is not needed?

thanks.
#CustomerExperience
#General

------------------------------
Panagiotis CHristodoulou
Amdocs Management Limited
------------------------------

Are you looking for Processes, Information or supporting System Functions?
Are you looking for fetching relevant (Customer) information for the TT to support the CSR, or are you looking for creation of statistics about TTs for the quality follow up, or are you looking to fetch e.g. system performance and quality information (characteristics) correlated to the TT to accompany the statistics?

In the Functional Framework there is e.g. this function

Customer Problem Resolution Support

Customer Problem Resolution Support supports Problem resolution with the following data to resolve the customer problem: o Customer Topology and inventory type data (e.g., logical and physical inventory) o Customer Information including the business organizational hierarchy o Change Management data o Customer Service Order data

This function is probably used by the Process Element "Support Problem Handling". The sub-processes can indicate what more a component with the above function should be able to do. The ODA Component Definition specifies that every component e.g. the component that executes the function above shall log "Who did What and When" and have a reporting function for that to promote statistics, traceability, audits, etc. and notify other assurance components for possible actions.

------------------------------
Kaj Jonasson
kajj@appliedbss.com
------------------------------

Original Message:
Sent: Nov 26, 2021 02:16
From: Panagiotis CHristodoulou
Subject: Trouble Tickets and Characteristics

Hi

I am working on trouble ticket and we have this requirement to be able to capture specific data while creating the ticket. Each Ticket Type can have different data to capture. We want to help the CSR understand what information is needed when opening one trouble ticket.
For example, we want o capture the Bill ID number when opening a dispute bill ticket.
I am thinking that this kind of information is good for characteristics. However, there is no such relation between TT and Characteristics.
Could we add such relation in the model?
Is there some specific reason you thought that this is not needed?

thanks.
#CustomerExperience
#General

------------------------------
Panagiotis CHristodoulou
Amdocs Management Limited
------------------------------

I am working on Open API TMF 621:
https://tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com/OpenApiTable/4.0.0/user_guides/TMF621_Trouble_Ticket_API_REST_Specification_R19.0.0.pdf

I am looking to get relevant information to support the CSR. @Derrick Evans described it very well.
I am not looking for statistics, or quality follow ups. 


​

------------------------------
Panagiotis CHristodoulou
Amdocs Management Limited
------------------------------

Original Message:
Sent: Nov 30, 2021 08:49
From: Kaj Jonasson
Subject: Trouble Tickets and Characteristics

Are you looking for Processes, Information or supporting System Functions?
Are you looking for fetching relevant (Customer) information for the TT to support the CSR, or are you looking for creation of statistics about TTs for the quality follow up, or are you looking to fetch e.g. system performance and quality information (characteristics) correlated to the TT to accompany the statistics?

In the Functional Framework there is e.g. this function

Customer Problem Resolution Support

Customer Problem Resolution Support supports Problem resolution with the following data to resolve the customer problem: o Customer Topology and inventory type data (e.g., logical and physical inventory) o Customer Information including the business organizational hierarchy o Change Management data o Customer Service Order data

This function is probably used by the Process Element "Support Problem Handling". The sub-processes can indicate what more a component with the above function should be able to do. The ODA Component Definition specifies that every component e.g. the component that executes the function above shall log "Who did What and When" and have a reporting function for that to promote statistics, traceability, audits, etc. and notify other assurance components for possible actions.

------------------------------
Kaj Jonasson
kajj@appliedbss.com

Original Message:
Sent: Nov 26, 2021 02:16
From: Panagiotis CHristodoulou
Subject: Trouble Tickets and Characteristics

Hi

I am working on trouble ticket and we have this requirement to be able to capture specific data while creating the ticket. Each Ticket Type can have different data to capture. We want to help the CSR understand what information is needed when opening one trouble ticket.
For example, we want o capture the Bill ID number when opening a dispute bill ticket.
I am thinking that this kind of information is good for characteristics. However, there is no such relation between TT and Characteristics.
Could we add such relation in the model?
Is there some specific reason you thought that this is not needed?

thanks.
#CustomerExperience
#General

------------------------------
Panagiotis CHristodoulou
Amdocs Management Limited
------------------------------

Hi again,

I did not get any feedback yet, if you believe that TMF should extend the Trouble Ticket (TMF 621) and add characteristics to it.

------------------------------
Panagiotis CHristodoulou
Amdocs Management Limited
------------------------------

Original Message:
Sent: Nov 30, 2021 09:43
From: Panagiotis CHristodoulou
Subject: Trouble Tickets and Characteristics

I am working on Open API TMF 621:
https://tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com/OpenApiTable/4.0.0/user_guides/TMF621_Trouble_Ticket_API_REST_Specification_R19.0.0.pdf

I am looking to get relevant information to support the CSR. @Derrick Evans described it very well.
I am not looking for statistics, or quality follow ups.


​

------------------------------
Panagiotis CHristodoulou
Amdocs Management Limited

Original Message:
Sent: Nov 30, 2021 08:49
From: Kaj Jonasson
Subject: Trouble Tickets and Characteristics

Are you looking for Processes, Information or supporting System Functions?
Are you looking for fetching relevant (Customer) information for the TT to support the CSR, or are you looking for creation of statistics about TTs for the quality follow up, or are you looking to fetch e.g. system performance and quality information (characteristics) correlated to the TT to accompany the statistics?

In the Functional Framework there is e.g. this function

Customer Problem Resolution Support

Customer Problem Resolution Support supports Problem resolution with the following data to resolve the customer problem: o Customer Topology and inventory type data (e.g., logical and physical inventory) o Customer Information including the business organizational hierarchy o Change Management data o Customer Service Order data

This function is probably used by the Process Element "Support Problem Handling". The sub-processes can indicate what more a component with the above function should be able to do. The ODA Component Definition specifies that every component e.g. the component that executes the function above shall log "Who did What and When" and have a reporting function for that to promote statistics, traceability, audits, etc. and notify other assurance components for possible actions.

------------------------------
Kaj Jonasson
kajj@appliedbss.com

Original Message:
Sent: Nov 26, 2021 02:16
From: Panagiotis CHristodoulou
Subject: Trouble Tickets and Characteristics

Hi

I am working on trouble ticket and we have this requirement to be able to capture specific data while creating the ticket. Each Ticket Type can have different data to capture. We want to help the CSR understand what information is needed when opening one trouble ticket.
For example, we want o capture the Bill ID number when opening a dispute bill ticket.
I am thinking that this kind of information is good for characteristics. However, there is no such relation between TT and Characteristics.
Could we add such relation in the model?
Is there some specific reason you thought that this is not needed?

thanks.
#CustomerExperience
#General

------------------------------
Panagiotis CHristodoulou
Amdocs Management Limited
------------------------------

Regarding the Trouble Ticket Characteristic: Yes, it is a good idea to have TroubleTicketSpecification in TMF 621API.
I will put proposal for v5 using the TMF pattern Entity/EntitySpec. to allow defining characteristic specification to be apply when creating the TroubleTicket itself.

------------------------------
Jacob Avraham
Amdocs Management Limited
------------------------------

Original Message:
Sent: Dec 06, 2021 09:08
From: Panagiotis CHristodoulou
Subject: Trouble Tickets and Characteristics

Hi again,

I did not get any feedback yet, if you believe that TMF should extend the Trouble Ticket (TMF 621) and add characteristics to it.

------------------------------
Panagiotis CHristodoulou
Amdocs Management Limited

Original Message:
Sent: Nov 30, 2021 09:43
From: Panagiotis CHristodoulou
Subject: Trouble Tickets and Characteristics

I am working on Open API TMF 621:
https://tmf-open-api-table-documents.s3.eu-west-1.amazonaws.com/OpenApiTable/4.0.0/user_guides/TMF621_Trouble_Ticket_API_REST_Specification_R19.0.0.pdf

I am looking to get relevant information to support the CSR. @Derrick Evans described it very well.
I am not looking for statistics, or quality follow ups.


​

------------------------------
Panagiotis CHristodoulou
Amdocs Management Limited

Original Message:
Sent: Nov 30, 2021 08:49
From: Kaj Jonasson
Subject: Trouble Tickets and Characteristics

Are you looking for Processes, Information or supporting System Functions?
Are you looking for fetching relevant (Customer) information for the TT to support the CSR, or are you looking for creation of statistics about TTs for the quality follow up, or are you looking to fetch e.g. system performance and quality information (characteristics) correlated to the TT to accompany the statistics?

In the Functional Framework there is e.g. this function

Customer Problem Resolution Support

Customer Problem Resolution Support supports Problem resolution with the following data to resolve the customer problem: o Customer Topology and inventory type data (e.g., logical and physical inventory) o Customer Information including the business organizational hierarchy o Change Management data o Customer Service Order data

This function is probably used by the Process Element "Support Problem Handling". The sub-processes can indicate what more a component with the above function should be able to do. The ODA Component Definition specifies that every component e.g. the component that executes the function above shall log "Who did What and When" and have a reporting function for that to promote statistics, traceability, audits, etc. and notify other assurance components for possible actions.

------------------------------
Kaj Jonasson
kajj@appliedbss.com

Original Message:
Sent: Nov 26, 2021 02:16
From: Panagiotis CHristodoulou
Subject: Trouble Tickets and Characteristics

Hi

I am working on trouble ticket and we have this requirement to be able to capture specific data while creating the ticket. Each Ticket Type can have different data to capture. We want to help the CSR understand what information is needed when opening one trouble ticket.
For example, we want o capture the Bill ID number when opening a dispute bill ticket.
I am thinking that this kind of information is good for characteristics. However, there is no such relation between TT and Characteristics.
Could we add such relation in the model?
Is there some specific reason you thought that this is not needed?

thanks.
#CustomerExperience
#General

------------------------------
Panagiotis CHristodoulou
Amdocs Management Limited
------------------------------