Clients with the same name cannot be added

[yongkheehou]

Description

I am unable to add 2 people called John Doe into the app even though all the other fields are different. The UG mentioned that people with the same name must be differentiated by changing the name inputted into the app, but this is not very feasible for common names in Singapore like Alex Tan or Alan Lee.

Steps to Reproduce

1. add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01 d/likes bubble tea c/Investment
2. add n/John Doe p/90799332 e/johd@example.com a/Jon street, block 123,#01-01 d/lies bubble tea c/Invetment

Expected Output

2 clients with the same name should be able to be added into the database, and be differentiated with another more unique field

Actual Output

[nus-se-script]

Team's Response

Thank you for pointing this out!

However, we decided not to use any other unique fields to differentiate clients with the same name due to the following reasons:

• More intuitive for a FA to identify a client with multiple clients of the same name is the additional details added in the name (e.g John (NUS), John (SMU))

• It will be inefficient for FAs to look at anything other than the name to differentiate two clients of the same name based on their PHONE_NUMBER or EMAIL. Doing what you suggested would diminish the efficiency that we are trying to provide to our FAs.

Therefore, we have to reject this issue as we believe that the current version is more optimized than the suggested implementation because it will increase the efficiency of the FA's workflow.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: Thank you for your response. While I understand the rationale, the current implementation creates significant usability challenges for financial advisors (FAs).

Firstly, appending identifiers like John (NUS) or John (SMU) is impractical when dealing with multiple clients with the same name, especially in scenarios where there are tens or hundreds of clients named John. It is likely that there are many people with names like John in NUS, and differentiating all of them with arbitrary identifiers like John (NUS) 1, John (NUS) 2, etc., is inefficient and confusing for financial advisors. For example, in official investment documents, financial advisors will likely require the client's full name, so it makes sense for financial advisors to want to save their clients' full names in their contact book.

Furthermore, since this app is for financial advisors whose clients are mainly Singaporean, it is common for multiple clients to share common names like Alex Tan or Alan Lee. It is uncommon in practice to deduplicate entries using peoples' names. Many client management systems allow non-unique names, relying on unique fields like phone numbers or emails to differentiate records, which is a more practical and professional approach.

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I believe that financial advisors in Singapore may input or retrieve data quickly during meetings, and requiring artificial name modifications adds inefficiencies. For example, in official investment documents, financial advisors will likely require the client's full name, so it makes sense for financial advisors to want to save their clients' full names in their contact book. This occasional inconvenience can disrupt workflows, especially for FAs managing large client bases (the UG introduction states that the target audience is financial advisors with >50 clients). The inability to handle non-unique names is particularly disruptive and can lead to **occasional inconveniences** for financial advisors because it complicates what should be a seamless task of retrieving client records. Financial advisors have to store an external mapping between the names they saved in ClientHub and the official names of their clients when drafting legal financial documents that require a client's full name. For a professional tool relied upon by FAs, this is a significant limitation. The occasional inconvenience caused by these inefficiencies can lead to inaccuracies in recording legal documentation, which could impact the FA’s business operations. As such, allowing non-unique names and differentiating clients using unique identifiers like phone numbers or emails aligns better with user expectations. This issue should be classified as a **medium-severity** bug and should be a **feature flaw**, as it introduces occasional and avoidable inefficiencies for FAs.

---