What steps will you take when your office receives a water quality customer complaint? How can you organize this process? Further, how can you automate this process, or even portions of this process?
It's customer complaint resolution software to the rescue.
If you have the right software it will attempt to first assist you in categorizing your main types of water quality complaints. This way you can allow end users to select a "Complaint Type" from a pre-set drop down or list box.
Usually these lists can be managed by a separate setup table.
You probably would also want the ability to pull over or "stack" multiple complaint types. In this way you can select more than one...
... and then pull them over:
Once your system has established specific complaint types you can add one or more to your actual customer complaints.
The next step would be to attach "Related Action Types" to the customer's complaint record.
Adding related Actions
In order to do this you will need to have the ability to first of all create "Action Types" (usually via a setup table). Later you will need the ability to associate specific "Action Types" with specific "Complaint Types".
Customer Complaint Tracking Software for water quality labs can truly be your friend.
When it comes to tracking street addresses in a water quality customer complaint tracking software system, there are several pieces of information that become important. It is critical that you manage how the different portions of the actual street addresses are assembled.
Now, we are not talking about fields like City, State or ZIP. Nor are we going to consider the merits of tracking either GPS coordinates or even perhaps local map locations (A-2 or A-3).
We will only be discussing the physical street address. The street address actually can have more pieces to it than you may think. In the typical "American" street address there are a minimum of five logical pieces. These pieces can be defined as:
• Street Number
• Optional Directional Prefix (North, South, East, West)
• Street Name
• Optional Directional Suffix (North, South, East, West)
• Street Type (ST, RD, AVE, ...)
This is the bare minimum of "street parts" if you will. In your geographical neck of the woods there could be more parts than the five described above.
In order to make sense of the parts above you need to envision a record creation screen. The Street Number field and the Street Name field would no doubt have to be a free text entry fields. However when it came to optionally selecting either a Directional Prefix and/or a Directional Suffix you could provide all available choices via drop downs. This way you could control how the Street Address is textually assembled.
In this way you could eliminate the horrendously mismatched ad hoc naming conventions that always seem to creep into an address database:
• South Main
• S. Main
• So. Main
• S Main
• So Main
The same would hold true for your Street Type address part. You could pick a single value for "street" or "road", etc, to avoid the array of differences that would ordinarily creep into an address database:
• Street
• street
• St
• st
• St.
• st.
• ST
• ST.
• STE
• STE.
• Ste
• Ste.
By providing the three drop downs described and depicted above, you would ensure a consistent naming convention. Without a consistent naming convention, especially when it comes to the Directional Prefixes, all hopes of alpha sorting an address list go out the window.
With this design to ensure conformity you will have a consistent naming convention throughout your entire system.
It may sound strange to say that we need to "differentiate" between customer records an location records when recording a customer complaint at a particular location. However, this is so important to do as any member of a municipal drinking water lab is very well aware.
There are two main reasons why this is the case:
• The location may not belong to the current resident
• People (customers) move around, perhaps even in the same town
Think of the customer's personal address info as different than the actual location record. The address in the customer's record, is strictly for mailing purposes. The actual "location" record is going to be stored in a separate "Locations" table. This is because customer John Smith may live at 10 Main St for a time, but then he may move to 5 Ocean Ave. He is the same customer, but the location has changed. If the location was not a separate record in its own table then you could not track a history of the location itself, once John Smith moved out.
Separating customer records from location records allows you to see if the location is really problematic or if certain customers, who may move around, are problematic.
Additionally, many people rent and so while the "customer" lives at a location, the location record will have contact fields which can have a different contact, like the name of the landlord.
A typical customer complaint tracking software package would probably look something like this in order to handle the assignment of both a customer record and a location record:
By keeping the customer records separate and distinct from the location records you can then query on either customer records or location records for historical purposes.
