Make phone number searching better
This request is for a new feature to improve phone number search capabilities, specifically by handling varied formatting in the free-text phone number field.
The current phone number search often fails because it's a simple text match that can't account for different formats like hyphens, spaces, or parentheses. Staff will sometimes report back to a patron that their phone number isn't in the system because they didn't search for it in the way it was entered into the patron's record. This can then frustrate patrons if they continued to get called or texted by the notification system.
Implementing a search function that normalizes all phone numbers to a standard, digit-only format will improve search accuracy and staff efficiency.
The free-text field for phone numbers leads to inconsistent data entry. For example, the same number might be entered as 555-123-4567 or (555) 123-4567. A simple search for one format will not find a record saved with the other. This forces staff to try multiple variations, which wastes time.
The proposed solution involves:
Normalization: The system removes all non-numeric characters from the search query and the phone numbers in the database.
Matching: The search is then performed on these standardized, digit-only strings.
This process ensures that a search will succeed regardless of how the number was originally formatted.
Faster and more accurate record retrieval.
Reduced staff frustration and time spent on searches.
-
Amy Mihelich
commented
We get reports from MessgeBee of phone notices that failed to deliver and those come with the phone number as a straight 10 or 11 digit string. So instead of being able to go directly from the report to search in Leap, we have to hand-key each phone number.
For staff looking up patrons at the desk it's the same story - they have to remember to insert the space and dash as they type while the patron is telling them the number out loud. Being able to have both methods of entry work would make for quicker searches in both cases, but would also cut down on failed searches. -
Bill Taylor
commented
And it really needs to be *all* non-numeric characters, not just punctuation -- Our database includes numeric phone numbers with various punctuation, and with the numerals preceded or followed by words, abbreviations, etc.
-
Wes Osborn
commented
Specifically the issue here in leap seems to be looking for SOME sort of delimiter. So, 614.837.8533 will match 614-837-8533 but 6148378533 will NOT match either of those.