From a US client's request to UAT

The problem

The client is a SaaS company in the US; the development team is in Vietnam. Requirements usually arrive as a short email or one or two sentences in a meeting. If they go straight to Dev, each requirement triggers several rounds of questions.

When a request goes straight to DevEach round of questions costs a full day

1. 1Three-line emailfrom the client’s PM
2. 2Dev reads and guesses
3. 3Asks the client
   11–12 hour time difference
4. 4Client repliesnext morning

Client replies → Dev reads and guesses · repeat until it is clear enough

Context and role

• I am the point of contact who receives requirements, analyses them, designs the solution and hands it over to Dev. Every meeting, email, ticket and document is in English. The client chose me as the team’s single point of contact.
• I cover part of the Scrum Master role: backlog, sprint planning, blockers, progress.
• I take part in testing and UAT.
• Constraints: the time difference, no BA on the client side, and no change to payment behaviour without approval.

The real scale of the project

A SaaS platform for residential construction in the US, 15 repositories: admin web app, field-worker app, supplier portal, finance and reporting services. The figures are counted from the project’s documentation repository and Jira, 06/2026 to 09/2026.

JiraTickets I created across the board

• Created by me
• Rest of the team

• 1,333 issues47%, the most on the team

  624709

The rest of this page uses a simulated request to show the exact process I apply to each requirement in the project.

Step 1: Receiving the original request

CPClient PMTo BA

Plan expiry

“We need customers to get reminded before their plan expires, and lose access if they don’t pay. Sales also wants to know who is about to churn. Can we have this next sprint?”

Three sentences, but they contain at least three features, two affected systems (billing and access permissions) and a reporting need for Sales.

Step 2: The clarifying questions

Each question comes with a default assumption, so the client only has to confirm or correct it.

Clarifying questionsNine questions, one round of answers

7/9

• How many days in advance should we remind, and how many times?Client correction: add a 3-day reminder, so 7, 3 and 1 daysQ1
• Email, in-app, or both?Assumption: bothQ2
• Only the account owner, or secondary admins as well?Assumption: account owner and billing adminQ3
• Once overdue, lock immediately or allow a grace period?Assumption: 7-day grace period, warnings onlyQ4
• Lock everything or only paid features?Client correction: read-only, and also block API accessQ5
• What about accounts already overdue at release?Assumption: grace period counted from the release dateQ6
• Can internal admins extend manually?Assumption: yes, and it must be loggedQ7
• Which timezone defines "expired"?Assumption: the account’s timezoneQ8
• Where does Sales see it, which columns, how often?Assumption: a list in the CRM, updated dailyQ9

Step 3: Impact assessment and business rules

Before designing, I read the codebase and the dev database to find out which components are affected.

Impact assessmentFive existing components affected

The client approved the business rules in writing before the flows were drawn. The first three rules sit on one timeline:

BR-01 to BR-03One plan, from almost expired to read-only

7-day grace period · warning at every sign-in

T−7reminder 1T−3reminder 2T−1reminder 3T0expiresT+7read-only, API returns 402

T−8T+9

1. T−7reminder 1
2. T−3reminder 2
3. T−1reminder 3
4. T0expires
5. T+7read-only, API returns 402
6. 7-day grace period · warning at every sign-in

Business rulesApproved by the client in writing

7/7

• Renewal reminders 7, 3 and 1 days before expiryBR-01
• 7-day grace period, warning at every sign-inBR-02
• Grace period over: read-only, API rejected with code 402BR-03
• A successful payment makes the account active again within 5 minutesBR-04
• Admins can extend manually by up to 30 days, reason mandatory, loggedBR-05
• Accounts overdue before release: grace period from the release dateBR-06
• "About to churn": expiring or in grace period, no payment in 30 daysBR-07

Step 4: State lifecycle, user stories and tickets

Status of a plan

1. 1Active
2. 2Expiring7 days left
3. 3Grace7-day grace period
4. 4Suspendedread-only

Suspended → Active · a successful payment in any status reopens the account within 5 minutes (BR-04)

US-02Ready

Grace period and read-only mode

As a billing admin of an expired account, I want a 7-day grace period with clear warnings so that I can renew without losing my data or being locked out unexpectedly.

• Given the subscription expired less than 7 days ago, when the user signs in, then a warning banner shows the expiry date and the days left, and every feature still works.
• Given the subscription expired 7 or more days ago, when the user calls any write endpoint, then the response is 402 with renewal instructions, and read endpoints still return 200.
• Given a suspended account, when a successful payment webhook arrives, then the account is active again within 5 minutes.
• Given an account that expired before the release date, when the release goes live, then the grace period starts on the release date.

Epic

Subscription expiry

Rules

BR-02, BR-03, BR-04, BR-06

Sprint

Current

JiraOne Epic, four Stories, split by sprint capacity

	This sprint	Next sprint
US-01 · Renewal reminders by email and in-app	Planned
US-02 · Grace period and read-only mode	Planned
US-03 · Admin manual extension with audit log		Planned
US-04 · "About to churn" list synced to CRM		Planned

Step 5: Testing and UAT

Test cases are written from the acceptance criteria. Agents run the cases that can be automated first; I verify the failed cases and the webhook-related cases myself.

Test casesExcerpt from the test sheet

	How it ran	Result
TC-01 · 7 days left: email and notification with the right content	Agent	Pass
TC-02 · Other timezone: reminder on the right local date	Agent	Fail: job runs on UTC time
TC-04 · Suspended: writes return 402, reads return 200	Agent, API	Pass
TC-05 · Payment while suspended: reopened within 5 minutes	Manual	Pass
TC-06 · Payment webhook arrives twice	Manual	Fail: double renewal

UAT

1. 1UAT checklistfollows BR-01 to BR-07
2. 2Client runs it on stagingduring the meeting
3. 3Sign-off through a ticket

Results

From email to acceptance

1. 11 emailthree lines
2. 29 questionsone round of answers
3. 37 business rulesapproved by the client
4. 41 Epic, 4 Storieswith acceptance criteria
5. 5Test cases and UATsigned off

• The “questions with default assumptions” way of clarifying was reused for later requirements.
• The development team receives tickets that are ready, and does not have to wait for answers across timezones.

What I learned

• With a client in a different timezone, the quality of the questions decides sprint speed more than coding speed does.
• Reading the dev database before designing makes it possible to challenge a requirement with data.
• Acceptance criteria never list everything. The BA has to add tests based on their understanding of the system.