Learning Launch Tool : delivery of a ticketing tool for managing   customer complaints 

 Challenge 

 As a consultant , I am mobilized on different types of client engagement . The engagement I detail   here was about implementing a new ticketing tool used for following customer complaints . The   project scope included identification , selection and implementation of the adapted solution . 

 One challenge was to conduct this project within a defined budget ( 200 K€ ) and timeframe ( 6   months ) . Another challenge was to go for a tool based on a workflow engine , to ensure a customer   complaint is actually treated . The tool needs to monitor the process from an end to end perspective   until the customer issue is resolved and not abandoned to maximize customer satisfaction . 

 Selection 

 The client I was engaged with was used to work on a classical way for this kind of projects , that is   working first on a detailed description of the needs , followed by a detailed specification written by   the IT team , then the development of the solution and finally the validation of the delivered software   with no implication of the end user at any step of this process . 

 The classical way to conduct such a project has demonstrated a lot of limitations when it is about   achieving results with high level of expectations and constraints : experience shows that projects are   conducted in a delay longer that the initial planning , the budget is under estimated and the final   product does not meet the end users expectation or at least works in an none adapted way . 

 So , this time we achieve to convince the customer there is a better way to proceed : we were enough   confident to accept the constraint in terms of timeframe and budget – it means any delay or   additional budget would be assumed by us or the selected vendor . Taking into those elements , it had   been decided to work on a more agile way taking advantage with the end - user engagement and the   use of the learning tool . The main objective was to quickly deliver , test and adjust a prototype taking   into account user feedback . 

 Application 

 We divided the scope of work in several use cases , depending on the kind of resolution needed to   close an issue from a customer . Moreover , before developing the solution over the final   environment , we developed a prototype over and Excel worksheet : in VBA is was possible to   developpe user interface in a flexible way . 

 Examples of screenshots for the prototype developed : 

 The prototype was developed by a team of three : a developer , an end - user and myself . We were in   the same room for several days . 

 This approach helped us to both work on the user interface and the API connection with third   parties . We provided the end users with a prototype for each use case defined and get back feedback   from them to improve the next delivery . We achieved to deliver a first prototype with the first use   case in 3 weeks . 

 Once the prototype with the main use cases implemented was globally validated we go through the   development for the solution based on the final environment . Those developments were based on   the prototype and not a written detailed specification . Once again , we submitted each use case to   the end users for getting feedback . 

 Besides engaging with end - users , the team in charge of IT environment and managing the system   have been part of the team in defining the right solution . 

 Insight & approach 

 This approach helped us not only to identify the key features , to prioritize them taking into account   end users point of view and not just what we assumed as the most important , but also to ensure the   solution was compliant with the IT environment and third parties API in a more efficient and effective   way . Besides , we avoided a long stage of writing down detailed specification which would have   delayed the delivery of a first release of the software . 

 At the end , we delivered the project in four months within the budget initially defined . 

 The learning launch approach is the right way to work on software we do not know what the final   results should be because it is the first time such a project is conducted . 

 The alternative way – classical cycle of development – would not have fit to this project due to   complexity we had to go through to adapt the prototype to the final environment . 


EMAIL: 
ID_NUM: 
NAME_STUDENT: 
PHONE_NUM: 
STREET_ADDRESS: 
URL_PERSONAL: 
USERNAME: 

### Task: You are a PII (Personal Identity Information) Detection. Given a essays written by students, you have to identify ONLY the following:
NAME_STUDENT - The full or partial name of a student that is not necessarily the author of the essay. This excludes instructors, authors, and other person names.
EMAIL - A student’s email address.
USERNAME - A student's username on any platform.
ID_NUM - A number or sequence of characters that could be used to identify a student, such as a student ID or a social security number.
PHONE_NUM - A phone number associated with a student.
URL_PERSONAL - A URL that might be used to identify a student.
STREET_ADDRESS - A full or partial street address that is associated with the student, such as their home address.
### Input: Learning Launch Tool : delivery of a ticketing tool for managing   customer complaints 

 Challenge 

 As a consultant , I am mobilized on different types of client engagement . The engagement I detail   here was about implementing a new ticketing tool used for following customer complaints . The   project scope included identification , selection and implementation of the adapted solution . 

 One challenge was to conduct this project within a defined budget ( 200 K€ ) and timeframe ( 6   months ) . Another challenge was to go for a tool based on a workflow engine , to ensure a customer   complaint is actually treated . The tool needs to monitor the process from an end to end perspective   until the customer issue is resolved and not abandoned to maximize customer satisfaction . 

 Selection 

 The client I was engaged with was used to work on a classical way for this kind of projects , that is   working first on a detailed description of the needs , followed by a detailed specification written by   the IT team , then the development of the solution and finally the validation of the delivered software   with no implication of the end user at any step of this process . 

 The classical way to conduct such a project has demonstrated a lot of limitations when it is about   achieving results with high level of expectations and constraints : experience shows that projects are   conducted in a delay longer that the initial planning , the budget is under estimated and the final   product does not meet the end users expectation or at least works in an none adapted way . 

 So , this time we achieve to convince the customer there is a better way to proceed : we were enough   confident to accept the constraint in terms of timeframe and budget – it means any delay or   additional budget would be assumed by us or the selected vendor . Taking into those elements , it had   been decided to work on a more agile way taking advantage with the end - user engagement and the   use of the learning tool . The main objective was to quickly deliver , test and adjust a prototype taking   into account user feedback . 

 Application 

 We divided the scope of work in several use cases , depending on the kind of resolution needed to   close an issue from a customer . Moreover , before developing the solution over the final   environment , we developed a prototype over and Excel worksheet : in VBA is was possible to   developpe user interface in a flexible way . 

 Examples of screenshots for the prototype developed : 

 The prototype was developed by a team of three : a developer , an end - user and myself . We were in   the same room for several days . 

 This approach helped us to both work on the user interface and the API connection with third   parties . We provided the end users with a prototype for each use case defined and get back feedback   from them to improve the next delivery . We achieved to deliver a first prototype with the first use   case in 3 weeks . 

 Once the prototype with the main use cases implemented was globally validated we go through the   development for the solution based on the final environment . Those developments were based on   the prototype and not a written detailed specification . Once again , we submitted each use case to   the end users for getting feedback . 

 Besides engaging with end - users , the team in charge of IT environment and managing the system   have been part of the team in defining the right solution . 

 Insight & approach 

 This approach helped us not only to identify the key features , to prioritize them taking into account   end users point of view and not just what we assumed as the most important , but also to ensure the   solution was compliant with the IT environment and third parties API in a more efficient and effective   way . Besides , we avoided a long stage of writing down detailed specification which would have   delayed the delivery of a first release of the software . 

 At the end , we delivered the project in four months within the budget initially defined . 

 The learning launch approach is the right way to work on software we do not know what the final   results should be because it is the first time such a project is conducted . 

 The alternative way – classical cycle of development – would not have fit to this project due to   complexity we had to go through to adapt the prototype to the final environment .
### Output: 