Skip to content

App does not support clients who do not want to give a phone number #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
zwliew opened this issue Apr 11, 2025 · 1 comment
Open

Comments

@zwliew
Copy link
Owner

zwliew commented Apr 11, 2025

Some clients may prefer not to be contacted via phone, but would rather be contacted via email. The app currently does not support this use case since clients are required to have phone numbers and not required to have email addresses.

I would prefer if both phone and email are optional but at least one must exist.

@zwliew zwliew changed the title App does not support users who do not have want to give a phone number App does not support users who do not want to give a phone number Apr 11, 2025
@zwliew zwliew changed the title App does not support users who do not want to give a phone number App does not support clients who do not want to give a phone number Apr 11, 2025
@nus-se-bot
Copy link

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

Team's Response

We reject this report.

Our target user group are artists who manage their client contacts, and the decision to require a phone number reflects the typical communication patterns observed in this context. Artists often need to reach out quickly and directly to confirm commission details, arrange meetups, or clarify expectations — tasks that are far more efficiently handled via phone than email.

While we acknowledge the tester’s suggestion, the current application design intentionally requires a phone number for every client.
Therefore, the decision to make phone numbers mandatory is a conscious product decision based on expected user needs and workflow.

As such, we do not consider this a feature flaw but rather an intentional constraint.

Items for the Tester to Verify

❓ Issue response

Team chose [response.Rejected]

  • I disagree

Reason for disagreement: [replace this with your reason]


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants