Object |
Shared with other SmartSolve© Applications |
Required for SmartComplaintsTM |
|
Yes |
Yes |
|
|
Yes |
Yes |
|
|
Yes |
No |
|
|
Yes |
No |
|
|
Suppliers, Customers, Regulatory Bodies, Importers/Distributors |
Yes |
Yes |
|
No |
Yes |
|
|
Manufacturing Sites Reporting Sites |
Yes |
Yes |
|
Yes |
No |
|
|
Yes |
No |
|
|
Yes |
No |
|
|
No |
No |
|
|
No |
No |
Object |
Shared with other SmartSolve© Applications |
Required for SmartComplaintsTM |
|
Yes |
Yes |
|
|
Yes |
Yes |
|
|
Yes |
Yes |
|
Yes |
No |
Object |
Shared with other SmartSolve© Applications |
Required for SmartComplaintsTM |
|
Yes |
Yes |
|
|
Yes |
Yes |
|
|
No |
No |
|
|
Yes |
No |
Object |
Shared with other SmartSolve© Applications |
Required for SmartComplaintsTM |
|
Yes |
Yes |
|
|
Yes |
Yes |
|
|
Yes |
Yes |
|
|
Yes |
No |
|
|
Yes |
No |
|
|
Yes |
No |
Object |
Shared with other SmartSolve© Applications |
Required for SmartComplaintsTM |
|
Yes |
Yes |
|
|
No |
No |
|
|
Yes |
Yes |
|
|
Yes |
Yes |
|
|
Yes |
No |
|
|
Yes |
No |
|
|
Yes |
No |
|
|
No |
Yes |
|
|
No |
No |
|
|
No |
Yes |
|
|
Yes |
No |
|
|
Yes |
No |
|
|
No |
No |
|
|
No |
No |
|
|
No |
No |
|
|
No |
No |
Object |
Shared with other SmartSolve© Applications |
Required for SmartComplaintsTM |
|
Yes |
Yes |
|
|
No |
Yes |
|
|
No |
No |
|
|
No |
No |
Object |
Shared with other SmartSolve© Applications |
Required for SmartComplaintsTM |
|
Yes |
Yes |
|
|
No |
Yes |
|
|
No |
Yes |
|
|
No |
Yes |
|
|
No |
Yes |
|
|
No |
Yes |
|
|
No |
Yes |
|
|
No |
Yes |
|
|
No |
Yes |
|
|
No |
Yes |
Object |
Shared with other SmartSolve© Applications |
Required for SmartComplaintsTM |
|
Yes |
Yes |
|
|
No |
Yes |
|
|
No |
Yes |
|
|
No |
Yes |
|
|
No |
Yes |
|
|
No |
Yes |
Object |
Shared with other SmartSolve© Applications |
Required for SmartComplaintsTM |
|
Yes |
No |
As an administrator it is important to become familiar with the various setup and policy tables available off the shelf with SmartComplaintsTM.
Please see the SmartComplaintsTM End User Guide for more information on SmartComplaintsTM end user functions and how to maintain end user records once the system is configured.
Prior to configuring the SmartComplaintsTM system, meet with the key stakeholders of SmartComplaintsTM. You should discuss exactly what business requirements must be met in the system, who is responsible for these requirements, and the standards for the completed requirements.
This common practice is not only needed to configure the SmartComplaintsTM system successfully; but also helps Pilgrim customer’s to revisit their business processes and work to ensure that these processes are effective and efficient (continually improved to ensure processes use the least amount of resources).
Some important things to consider when implementing SmartComplaintsTM:
Start with one simple model and build your configurations from this one scenario. Then you can pull in the rest of your scenarios after testing them to see if these configurations will work. Trying to do everything at one time causes proven delays in your implementation so keep it simple!
How many other SmartSolve© systems will, or have already been implemented within your organization?
If any other systems have been implemented, obtain a copy of the software requirements specification (configuration documentation) and refer to this documentation. Also, collaborate with other SmartSolve© administrators about how these other SmartSolve© systems were configured.
It is important when process mapping to try not to figure out what is going to go where in the SmartComplaintsTM system. First make sure the business requirements are clearly illustrated.
Map out a process flow for reporting an exception (i.e., inquiries, complaints) and discuss the following:
Define the type of event (exception) you wish to start with and how event will be recorded (by end user reporter, or imported from other third party application using Pilgrim's Complaints Synchronization Agent)
Identify all entry fields required for reporting the exception (i.e., products, failure modes, business entities involved, etc,).
Map out the process for managing the exception (who will own the exception and oversee it throughout its life cycle).
Determine when you may need to create an Issue from the exception record (if applicable).
Illustrate the steps performed by user roles to record and resolve exceptions and issues (step sequence from simple resolution to most complex model, for example Tasks for Regulatory Reporters, etc.).
Determine how exceptions and issues will be looked up (Saved Searches) and how information will be analyzed through reports (queries), etc.
What are Complaint Codes?
Complaint Codes are failure modes and can be setup the same way; however they can be made specific to the type of complaint that is being recorded (i.e., inquiry complaint codes may be different than adverse event or product malfunction codes). If using SmartCAPATM with SmartComplaintsTM and you wish to keep your complaint codes separate then you can also use this option in setup.
Exception Type |
Complaint Category |
Complaint Code |
|
Product Complaint
|
Packaging Mechanical Malfunction |
Damaged Container Balloon Burst
|
|
Inquiry |
Packaging Documentation |
Clarification Missing Documentation
|
Anyone can submit a complaint exception. Exceptions can come from customers, end users, or distribution partners, etc. The importance of the exception record in SmartComplaintsTM is having the ability to track, record, classify and trend all the exceptions that are submitted.
The illustration below shows some of the different ways in which exceptions could be reported in SmartComplaintsTM:
The scenarios below explain a little more in-depth how the complaint reporting examples above could be carried out using SmartComplaintsTM:
Scenario |
Description |
|
Field Service Scenario |
People in the field could have the data entry form on their lap tops so that they could enter the information into their template while in the field. Once back in the office, they connect to the network (within the office or via VPN connection), access the solution over the server, then synchronize and upload the complaint into the SmartComplaintsTM exception record.
|
|
Customer Services Scenario |
Customers may call in to submit a complaint. In such cases, a customer service representative would typically enter the information locally into their CRM system. The CRM system would then synchronize with SmartComplaintsTM and push the information into the SmartComplaintsTM record.
|
|
Customer/Partner Scenario |
Customers/Clients may also submit their complaints directly through your company website. The information which is entered through the web site can then be pushed into SmartComplaintsTM to be managed and resolved through the SmartComplaintsTM record.
|
|
NOTE: These approaches would require interfacing with systems such as CRM systems or web sites. However, the event can also be entered manually by the user. The next step in the process is recording an exception (event) in SmartComplaintsTM with all required information and validated data. |