Essential BA Discovery Questions For Pricing Discussions
Hey guys! Let's dive into the nitty-gritty of pricing discussions and how Business Analysts (BAs) can nail the discovery phase. We're going to break down a comprehensive set of questions that BAs should be asking, especially when dealing with complex systems like BRE (Business Rule Engine) control reports. Think of this as your ultimate checklist to ensure no stone is left unturned. This article aims to provide a detailed guide, making sure you’re equipped with the right questions to ask, helping you gather all the necessary information for effective decision-making and system implementation. So, buckle up and let’s get started!
1. Package Level (High-Level Eligibility)
When we talk about the package level, we're really focusing on the big picture – the high-level eligibility criteria. These questions help us understand the fundamental aspects of the package, such as the benefit type, processing frequency, and qualification triggers. Understanding these elements is crucial for setting the stage for more detailed inquiries later on. For instance, knowing whether a package offers a rate increase or fee waiver can significantly influence how you approach subsequent questions about qualification criteria and downstream impacts. It’s like laying the foundation for a building; a strong foundation ensures the rest of the structure stands firm. So, let’s get into the specifics.
1. What is the benefit type for this package (rate increase or fee waiver)?
This is the first question you should be asking. Is the package designed to give customers a rate increase on their savings or waive certain fees? This distinction is crucial because it shapes the entire customer experience and the underlying logic required to implement the package. A rate increase package might involve complex interest calculations and tracking, while a fee waiver package might focus more on identifying eligible fees and applying waivers. Imagine you're building a house; knowing whether it’s a cozy cottage or a sprawling mansion dictates the blueprint. This question sets the tone for the entire project.
2. What is the required processing frequency (daily, statement cycle, month-end)?
The processing frequency determines how often the system needs to evaluate eligibility. Is it a daily check, a monthly review at the statement cycle, or an end-of-month process? The frequency impacts system load, data storage requirements, and the complexity of the logic. Daily processing, for example, demands a robust, real-time system, while month-end processing allows for batch jobs and less frequent updates. Think of it like scheduling workouts – daily sprints versus monthly marathons require different training regimens.
3. Is full processing required every time, or only when thresholds are met?
Here, we're digging into whether the system should run the eligibility checks for every customer every time, or only when certain thresholds are met. Processing only when thresholds are met can save significant computational resources but requires a clear definition of these thresholds. For instance, if a customer's balance falls below a certain level, the system might trigger a re-evaluation of their eligibility. This is like a smart thermostat – it only kicks in when the temperature deviates from the set point.
4. What triggers a loss of qualification and when does that take effect?
Understanding what causes a customer to lose qualification and when that loss takes effect is vital for maintaining data integrity and customer satisfaction. Is it a drop in balance, a change in relationship status, or some other factor? And does the loss of qualification take effect immediately, at the end of the statement cycle, or some other time? Clear rules around this prevent confusion and ensure fair treatment. Imagine it as the rules of a game – everyone needs to know what gets them out and when.
2. Product Control (Which Products Can Participate)
Next up is product control. This category helps define which products are eligible for a particular package. It's about understanding the scope and applicability of the package across different product lines. These questions help ensure that the package is offered to the right customers with the right products, avoiding any potential misapplications or exceptions. Let's dive into the specifics.
1. Which “PRIMARY APPLICATION” products are eligible for this package?
Identifying the primary application products that qualify for the package is crucial. Are we talking checking accounts, savings accounts, credit cards, or a combination? Knowing this helps narrow down the target audience and ensures the package is relevant to their primary financial products. Think of it as choosing the right ingredients for a recipe – you need to know your base before adding the spices.
2. Which “RELATED APPLICATION” product types are allowed to qualify a customer?
Sometimes, a customer’s eligibility might depend on their holdings in related products. Which related application product types can contribute to qualification? For instance, a customer with a mortgage might qualify for a better rate on their checking account. Understanding these relationships is key to accurately assessing eligibility. It’s like understanding the supporting cast in a movie – they play a crucial role in the overall story.
3. Are any product types excluded, and why?
Equally important is knowing which product types are excluded and the reasons behind the exclusion. Are certain products excluded due to regulatory constraints, system limitations, or business strategy? Knowing this prevents confusion and ensures compliance. Imagine it as setting boundaries in a garden – you need to know what to keep out to protect what's inside.
4. If a product is sunset or converted, how do we migrate its BRE eligibility rules?
Products change over time – some are sunset, others are converted. How do we ensure the Business Rule Engine (BRE) eligibility rules are migrated correctly? This question addresses the long-term maintenance and adaptability of the system. It’s like planning for renovations in a house – you need to ensure the new additions blend seamlessly with the existing structure.
3. Relationship Code Logic (RM Link)
Relationship Code Logic focuses on how relationships between accounts and customers influence eligibility. This is particularly relevant in scenarios where family members or affiliated entities might contribute to qualification. Understanding the intricacies of relationship codes, TIN validation, and account holder changes is crucial for accurate eligibility assessments. Let's explore the specific questions in this category.
1. Which RM relationship codes are considered valid?
Which Relationship Manager (RM) relationship codes are considered valid for qualification? This question identifies the types of relationships that the system recognizes – spouse, child, business partner, etc. Knowing this ensures that the system accurately interprets and applies relationship-based rules. It’s like having a key to a secret code – you need the right code to unlock the benefits.
2. Does the package require TIN validation?
Does the package require Taxpayer Identification Number (TIN) validation? This is crucial for compliance and data integrity. TIN validation ensures that the accounts are correctly linked to the appropriate individuals or entities. There are different levels of validation – no validation, business/personal, commercial only, or personal only. This question helps determine the necessary validation level. It’s like verifying the ID before granting access – you need to make sure the person is who they say they are.
3. If TIN validation = B or P, what happens when a mismatch occurs?
If TIN validation is required for both business and personal accounts, or personal accounts only, what happens when a mismatch occurs? This question addresses the exception handling – what actions should be taken if the TIN doesn't match the account holder's information? Do we flag the account for review, deny qualification, or something else? Clear procedures are essential for handling these situations. It’s like having a backup plan – you need to know what to do if the primary plan fails.
4. What happens if the related account holder changes (e.g., RM coded incorrectly)?
What happens if the related account holder changes, or if the RM code is incorrect? This question tackles the dynamic nature of relationships. People change relationships, and sometimes coding errors occur. How does the system handle these changes? Does it automatically update eligibility, or does it require manual intervention? Understanding this ensures that the system remains accurate and up-to-date. It’s like maintaining a family tree – you need to update it as relationships evolve.
4. Qualification Criteria (What Makes Them “Earn It”)
Now, let's talk about qualification criteria. This is the heart of the matter – what does a customer need to do to “earn” the benefits of the package? Understanding the qualification methods, minimum requirements, and the logic behind them is essential for designing an effective and fair system. These criteria determine who gets the perks, so let's dig into the details.
1. Which method is used to qualify — balance, transaction count, or transfer activity?
What method is used to qualify customers? Is it based on their account balance, the number of transactions they make, or their transfer activity? The method chosen will significantly impact the system's logic and the data it needs to track. Balance-based qualification might require monitoring average daily balances, while transaction-based qualification needs to count qualifying transactions. It’s like choosing the right tool for the job – a hammer for nails, a screwdriver for screws.
2. For transaction-based qualification:
What is the minimum number of transactions?
For transaction-based qualification, what is the minimum number of transactions required? This sets the threshold for eligibility. Is it five transactions a month, ten, or more? This number needs to be realistic and achievable for the target customer segment. It's like setting a goal – it should be challenging but attainable.
Do all transaction codes count, or only “valid” ones from the control file?
Do all transaction codes count towards qualification, or only the “valid” ones specified in the control file? This clarifies which transactions are considered qualifying activities. Are we counting only certain types of purchases, or do all transactions count? This ensures that the system accurately tracks and assesses transaction-based eligibility. It’s like knowing the rules of the game – what counts as a point and what doesn’t.
3. For transfer-based qualification:
What transfer amount/severity must be met?
If qualification is based on transfer activity, what transfer amount or severity must be met? This defines the level of transfer activity needed to qualify. Is it a minimum transfer amount, a certain number of transfers, or a combination? This ensures that the system correctly evaluates transfer-based eligibility. It’s like setting a performance benchmark – you need to know what level of performance is required to succeed.
Are internal vs external transfers treated the same?
Are internal versus external transfers treated the same? This question addresses the nuance of transfer types. Do transfers between accounts within the same institution count the same as transfers from external accounts? The answer can impact how customers strategize their transfers to meet qualification criteria. It’s like differentiating between a practice run and the real deal – they might have different weights.
4. If BOTH are present, is it AND logic or OR logic?
If both transaction and transfer-based criteria are present, is it an AND logic or an OR logic? This clarifies how the criteria are combined. Does the customer need to meet both the transaction and transfer requirements (AND), or just one of them (OR)? This logic significantly impacts who qualifies for the package. It’s like choosing the right conjunction in a sentence – it changes the meaning entirely.
5. Transaction Control Codes (What Counts as Activity)
Transaction control codes are the specific codes that the system uses to identify and categorize different types of transactions. This category focuses on defining which transaction codes count towards qualification, ensuring that the system accurately tracks customer activity. Clear definitions are crucial for maintaining data integrity and fair assessment of eligibility. Let's get into the specifics.
1. Which user transaction codes count as “qualified”?
Which user transaction codes count as “qualified” for the package? This is a fundamental question that defines what activities contribute to meeting the qualification criteria. Are we talking about purchases, payments, or other types of transactions? A clear list of qualified transaction codes is essential. It’s like having a dictionary – you need to know the definition of each word to understand the sentence.
2. Which codes count as “transfer” codes?
Which codes specifically count as “transfer” codes? This is important if transfer activity is a qualification criterion. Differentiating transfer codes from other transaction codes ensures that the system accurately tracks and assesses transfer-based eligibility. It’s like sorting mail – you need to know which letters go to which address.
3. Is the list standardized across all packages or defined per package?
Is the list of transaction codes standardized across all packages, or is it defined per package? This question addresses consistency and flexibility. A standardized list simplifies management, while a per-package definition allows for customization. The choice depends on the complexity of the system and the needs of the business. It’s like choosing between a uniform and custom outfits – each has its pros and cons.
4. If new digital payment methods are added (ACH, Zelle, P2P) — how are codes updated?
With the ever-evolving landscape of digital payments, how are the transaction codes updated when new methods are added, such as ACH, Zelle, or P2P transfers? This question ensures the system can adapt to new technologies and maintain accurate tracking of customer activity. A clear process for updating codes is essential. It’s like updating software – you need to stay current to ensure compatibility and performance.
6. Affiliate & Related Account Handling
Affiliate and related account handling focuses on how the system manages accounts linked through relationships, such as family members or business partners. This is crucial for accurately assessing eligibility when multiple accounts can contribute to qualification. These questions help clarify how the system handles these complex relationships. Let’s explore the details.
1. Can more than one related account contribute to qualification?
Can more than one related account contribute to qualification? This defines whether the system allows for aggregated qualification, where multiple accounts together meet the criteria. If yes, the system needs to handle the complexity of combining data from multiple sources. It’s like pooling resources – can multiple contributors combine their efforts to reach a goal?
2. If the package allows only 1 related account, how is it selected?
If the package allows only one related account to contribute, how is that account selected? This question addresses the selection criteria – is it based on balance, transaction activity, or some other factor? A clear selection process is essential for fair and consistent application of the rules. It’s like choosing a team captain – what criteria determine the best candidate?
3. If the related account closes, does qualification drop the same cycle or next?
If a related account closes, does the qualification drop in the same cycle or the next? This defines the timing of eligibility changes. A clear rule prevents confusion and ensures accurate tracking of qualifications. It’s like knowing the expiration date – when does the benefit cease to apply?
4. Does the system use the affiliate trailer ID or RM lookup to confirm linkage?
Does the system use the affiliate trailer ID or RM lookup to confirm the linkage between accounts? This question clarifies the method used to verify relationships. The method chosen impacts data accuracy and system efficiency. It’s like verifying a connection – what evidence confirms the relationship?
7. Processing & Overrides
Processing and overrides deal with the mechanics of how the system applies the rules and what happens when manual intervention is needed. This category ensures that the system operates smoothly and that there are clear procedures for handling exceptions. Let’s delve into the specifics.
1. Who controls the processing period (statement vs month-end vs daily)?
Who controls the processing period – is it statement-based, month-end, or daily? This defines the frequency and timing of the eligibility assessments. The choice impacts system load and the customer experience. It’s like setting a schedule – when do the tasks need to be completed?
2. When forcing a package, what additional governance is needed?
When manually forcing a package qualification, what additional governance is needed? This question addresses exception handling and control. Forcing a qualification bypasses the standard rules, so additional checks and approvals are necessary to prevent misuse. It’s like using an override – what safeguards are in place to prevent errors?
3. How do we verify that forcing doesn't cause duplicate qualification posting?
How do we verify that forcing a package doesn't cause duplicate qualification posting? This ensures data integrity. Manual overrides should not result in unintended benefits or errors. Verification steps are crucial. It’s like double-checking the work – ensuring accuracy after manual adjustments.
4. Are there cutoffs (timing windows) for same-day forcing?
Are there cutoffs or timing windows for same-day forcing? This defines when manual overrides can be applied. Cutoffs prevent last-minute changes that could disrupt processing or reporting. It’s like setting a deadline – when is the last chance to make changes?
8. Downstream Impacts (What Happens After Qualification)
Downstream impacts focus on what happens after a customer qualifies for a package. This category explores how the qualification affects other systems and processes, ensuring a seamless and integrated experience. Let's dive into the questions.
1. Where is the QUALIFIED flag stored in IM/ST?
Where is the QUALIFIED flag stored in the Information Management (IM) or System Table (ST)? This defines where the qualification status is recorded in the system. Knowing this is essential for other modules to access and use the information. It’s like knowing where the key is kept – it’s essential for unlocking the benefit.
2. Which downstream modules read this flag — rate trailer, service charge routine, etc.?
Which downstream modules read this QUALIFIED flag, such as the rate trailer or service charge routine? This identifies the systems that rely on the qualification status to apply benefits or adjustments. Understanding these dependencies ensures that the qualification has the intended effect. It’s like understanding the domino effect – how one event triggers others.
3. Does qualification appear in online banking or only in back-office systems?
Does the qualification status appear in online banking, or is it only visible in back-office systems? This impacts customer transparency and communication. Customers may expect to see their qualification status online. It’s like providing feedback – customers want to know the results of their actions.
4. Is there front-line messaging when a customer loses qualification?
Is there front-line messaging when a customer loses qualification? This addresses customer communication. Timely and clear messaging helps manage customer expectations and prevent dissatisfaction. It’s like giving a warning – customers appreciate knowing when a change is coming.
9. Reporting & Audit
Reporting and audit focus on how the system's performance is tracked and monitored. This category ensures that there are clear procedures for reviewing data, tracking KPIs, and maintaining an audit history. Let's explore the questions.
1. Who receives and reviews the BRE Control Report?
Who receives and reviews the Business Rule Engine (BRE) Control Report? This identifies the stakeholders responsible for monitoring the system's performance. Regular review ensures that the rules are functioning as intended. It’s like checking the gauges – ensuring the system is running smoothly.
2. Is there a KPI tracking % of qualified vs unqualified?
Is there a Key Performance Indicator (KPI) tracking the percentage of qualified versus unqualified customers? This metric provides insights into the effectiveness of the package and the eligibility criteria. It’s like tracking the score – knowing how well the team is performing.
3. Do we retain an audit history of when/why a customer lost qualification?
Do we retain an audit history of when and why a customer lost qualification? This ensures compliance and provides data for analysis. An audit trail helps identify trends and address potential issues. It’s like keeping a logbook – recording the journey and the milestones.
4. Are exception accounts tracked separately (e.g., manual override or waiver)?
Are exception accounts tracked separately, such as those with manual overrides or waivers? This ensures that these cases are monitored and reviewed. Separate tracking prevents these exceptions from skewing the overall data. It’s like having a special category – tracking cases that deviate from the norm.
10. Change Management (Future-Proofing)
Change management focuses on how the system is maintained and updated over time. This category ensures that there are clear procedures for approving changes, refreshing rules, and handling custom packages. Let's dive into the questions.
1. Who approves updates to product, transaction, or relationship control files?
Who approves updates to the product, transaction, or relationship control files? This identifies the stakeholders responsible for authorizing changes. A clear approval process prevents unauthorized modifications. It’s like having a gatekeeper – ensuring changes are vetted before implementation.
2. How often do we revisit/refresh business rules?
How often do we revisit and refresh the business rules? This defines the maintenance schedule. Regular reviews ensure that the rules remain current and effective. It’s like tuning an engine – periodic adjustments ensure optimal performance.
3. Are there SLAs for turnaround if a rule correction is needed?
Are there Service Level Agreements (SLAs) for turnaround if a rule correction is needed? This sets expectations for response times. Timely corrections are essential for maintaining system accuracy. It’s like having a repair plan – knowing how quickly issues will be resolved.
4. Are custom packages handled the same way as standard ones?
Are custom packages handled the same way as standard ones? This addresses consistency. Custom packages might require additional procedures or controls. It’s like handling special orders – ensuring they meet the same standards as regular orders.
Quick BA Meeting Version
For those quick syncs, here's a condensed version of the key questions:
“Which products qualify, which RM relationship codes are valid, how is TIN validation enforced, which transaction codes count toward qualification, and when do these rules get applied (daily vs month-end)? Also, where is the qualified flag stored and who consumes the control report downstream?”
Final Thoughts
So, there you have it – a comprehensive set of BA discovery questions for pricing discussions. Armed with these questions, you'll be well-equipped to gather all the necessary information and ensure that your pricing strategies are implemented effectively. Happy analyzing, guys!