AgeSA Mobile: BES application process
Illustrative business analysis deliverable / portfolio reconstruction Prepared October 2026
Scope and evidence
The author worked on the individual pension (BES) application process in AgeSA Mobile as a Senior Business Analyst at Adesso Turkey (2024–2025). The example below illustrates BA techniques and possible acceptance tests for a digital application journey. It is NOT original AgeSA documentation and does not disclose internal business rules, systems, screens or customer data.
Business goal
Define a coherent, testable individual BES application experience in which an applicant can enter information, review requirements, submit an application and receive an appropriate processing state.
In scope for this illustrative exercise
- Application initiation and identification of required fields
- Validation of submitted information
- Applicant review before final submission
- Error and exceptional-state handling
- Functional acceptance and regression scenarios
Stakeholder / actor matrix
| Actor | Responsibility |
|---|---|
| Applicant | Enters and checks information, submits the application |
| Mobile application | Collects and displays information; presents validation messages |
| Application service | Applies server-side business validation and persists an application state |
| Business reviewer | Confirms product rules and evaluates exceptions |
| QA / BA | Maps requirements to acceptance tests and validates edge cases |
All actors and states here are reconstructed examples, not claims about AgeSA's actual application architecture.
Illustrative process map
- Applicant starts an individual BES application.
- Mobile interface requests the necessary information and acknowledgments.
- Required fields are checked locally and by the service.
- Invalid or incomplete information is returned for correction.
- Applicant reviews a summary and submits.
- The service returns an accepted, pending or rejected result.
- The mobile app shows a state-appropriate message and next action.
Decision and exception logic
- Missing required information: prevent submission and show precise field-level feedback.
- Invalid server-side business rule: reject the request with an actionable result.
- Network timeout: show uncertainty; do not present the application as accepted without confirmation.
- Repeat tap: avoid unintended duplicate submissions.
Sample user stories
US-BES-01: Validate mandatory fields
As an applicant, I want to know which required details are incomplete before submission so I can correct them.
Acceptance criteria
- Given a mandatory field is empty, when the applicant submits, then the application is not sent and the affected field is identified.
- Given all mandatory fields are present, when the applicant proceeds, then the system allows the next configured step.
- Errors do not erase valid information already entered in the form.
US-BES-02: Review application summary
As an applicant, I want to review my entered information before final submission so I can detect mistakes.
Acceptance criteria
- The summary presents the information relevant to this step.
- The applicant can return to editable fields before submitting.
- The final submission is unambiguous and requires a deliberate user action.
US-BES-03: Handle uncertain submission result
As an applicant, I want a clear message when the service cannot confirm submission so I do not mistakenly assume the application succeeded.
Acceptance criteria
- A confirmed acceptance state is shown only when returned by the service.
- Network failure or timeout is distinguished from a confirmed rejection.
- A retry path must account for duplicate-submission prevention.
Illustrative functional test matrix
| Test ID | Scenario | Expected result |
|---|---|---|
| BES-T01 | Required inputs are complete and valid | The request progresses to review or submission |
| BES-T02 | Required field omitted | Field-level feedback; no valid submission created |
| BES-T03 | Server rejects a business condition | Applicant sees an appropriate error state |
| BES-T04 | Submission times out | No false success confirmation; safe recovery |
| BES-T05 | Repeated submission attempt | No unintended duplicate application |
| BES-T06 | Back navigation after validation | Previously entered valid input is retained |
Traceability example
| Requirement | User story | Test scenario |
|---|---|---|
| Mandatory field validation | US-BES-01 | BES-T01, BES-T02 |
| Pre-submission review | US-BES-02 | BES-T01 |
| Safe error messaging | US-BES-03 | BES-T03, BES-T04, BES-T05 |
Exclusions and provenance
This example does not claim specific AgeSA screens, identity verification flows, pension product pricing, regulatory consent language, backend contracts, operational SLAs, or measurable conversion improvements. Review with the original client would be required before describing any such facts.