Improve onboarding
Improve the end-to-end customer onboarding process.
Home / Projects / Radiant Solution
From a stakeholder requirement to a tested user story.
Radiant Solution is a financial consultancy scenario from my Business Analysis course, whose bespoke CRM could not keep up with onboarding. Our BA team of seven designed its replacement, a Salesforce CRM connected to the website, HubSpot and SAGE. I wrote the user stories, drew the wireframes, rebuilt the BPMN models, took my turn running workshops and owned UAT.
- MY ROLE
- Business Analyst in a team of seven
- I OWNED
- User stories, wireframes, BPMN models, UAT, and my turn running workshops
- APPROACH
- Hybrid: written requirements, then Agile sprints
- DELIVERY AND TOOLS
- Jira, Azure DevOps, Lucidchart
Website contact formWhere a lead first appears
HubSpotCaptures the lead and reports on campaigns
SalesforceThe single record of the lead, case and status
SAGE and the payment gatewayInvoice, payment link, receipt and refunds
Every hand-off depended on a person
Radiant Solution offers financial training, staff resource services and financial technology platforms. Its existing bespoke CRM was no longer fit for purpose.
Lead details moved from the website to the CRM team by hand. Invoices passed between the Account Team, the CRM team and the lead. Payments were taken by phone. Each manual step was a chance to lose a lead or make a mistake, so the aim was to automate the process and remove those errors.
Five project objectives
Migrate existing records
Migrate existing records to the new platform.
Report on sales and campaigns
Give marketing and sales teams reports on sales and campaigns.
Capture leads from the website
Integrate the website with the new CRM so new leads are captured automatically.
Connect HubSpot and SAGE
Integrate HubSpot and SAGE with the Salesforce CRM.
Five pieces of the work, one thread through them
The team worked in sprints, with Jira for the backlog and Azure DevOps for estimating. My pieces sit at both ends of the chain: the user stories that turn a requirement into something buildable, and the UAT that proves it.
OWNED
User stories
Written in the form "As a lead, I want to receive payment options so that I can pay", each with Given, When, Then acceptance criteria. Grouped under epics such as Salesforce CRM Integration, Payment Options, Reports and Admin Portal.
REBUILT
BPMN models
Rebuilt the team's as-is and to-be models in Lucidchart, with separate sub-processes for payment, fulfilment and refunds.
OWNED
Wireframes
Low fidelity screens for the admin user form and the marketing report, so the stories could be discussed against something visible.
OWNED
UAT
Test cases for each sprint, written against the Jira stories, with expected result, actual result and pass or fail.
OWNED
Workshops and elicitation
Took turns running workshops with the team, and helped prepare the elicitation questions for the business case.
From the as-is to a to-be with four sub-processes
The team analysed the current process and designed the to-be as a main flow with sub-processes for payment, fulfilment and refunds. I rebuilt these models in Lucidchart, and my user stories and UAT were written from them. Choose a view below.
- {{ p.text }}
Stage by stage, before and after
STAGE
AS-IS
TO-BE
{{ c.stage }}
AS-IS{{ c.before }}
TO-BE{{ c.after }}
Timers we proposed in the to-be
These are proposed service levels, set in the design for the client to confirm. Each one is measurable, which is why it can be tested.
{{ s.value }}
{{ s.label }}
{{ s.note }}
From requirement to test, and where the chain breaks
I built this matrix afterwards from the requirements document, the Jira stories, the wireframes and both UAT sheets. The team did not keep one during the project. Tracing it showed {{ traceSummary }}.
| REQ | REQUIREMENT | OBJECTIVE | STORY | WIREFRAME | UAT | COVERAGE |
|---|---|---|---|---|---|---|
| {{ r.id }} | {{ r.req }} | {{ r.obj }} | {{ r.story }} | {{ r.wf }} | {{ r.uat }} | {{ r.cov }}{{ r.note }} |
The artefacts, from screen to test
Real project artefacts, shown as they were produced.
Nine wireframe screens that I drew: the lead's path from enquiry to payment, then the internal CRM, invoice, reporting and admin screens. Each one names the requirement or story it supports.
SCREEN {{ wfCur.n }} OF {{ wfCur.total }}
{{ wfCur.title }}
{{ wfCur.text }}
{{ wfCur.supports }}
How the team delivered
UAT I ran
I wrote the UAT test cases for both sprints. Sprint 1 covered the lead capture, notification, leads report and HubSpot stories. Sprint 2 covered the marketing report, user management, payment options, payment methods and automatic invoicing.
Each case records the story, the steps, the expected result, the actual result and a pass or fail, so any failed case points back to one story.
When I traced the matrix afterwards, the payment requirements had gaps. I wrote the missing stories and tests, and marked them "designed, not run" because the project had ended and I will not claim results I do not have.
A TEST THAT FAILED
MSTA2-7 Email notification of new leads
Sprint 1, scenario TS101.2. Steps 1 to 4 open the browser and the contact form. Steps 5 to 7 are shown.
| STEP | EXPECTED | ACTUAL | RESULT |
|---|---|---|---|
| 5. Enter lead details | System should accept lead details | System accepted lead details | Pass |
| 6. Click submit | System should submit the application | Application submitted successfully | Pass |
| 7. CRM sends notification | System should send email notifications | System did not send email notifications | Fail |
A lead was captured but the CRM team was not notified, which is the whole point of the story. The defect was logged. The sprint ended before the story could be retested.
A TEST THAT CHECKS A LIMIT
MSTA2-12 Generating marketing report
Sprint 2, scenario TS104.2. It tests the date range filter on the Marketing report wireframe.
| STEP | EXPECTED | ACTUAL | RESULT |
|---|---|---|---|
| 1. Log in to the admin portal | Log in succeeds | Admin user logged in | Pass |
| 2. Open the report section | Report section displays | Report section displayed | Pass |
| 3. Select marketing report | Marketing report is selected | Marketing report selected | Pass |
| 4. Choose an invalid date range | System says the date range is invalid | System indicated the date range is invalid | Pass |
The happy path shows the report works. This case shows it refuses bad input, which is what a hiring manager looks for in test design.
And what I took from it
The team handed over an as-is model, a to-be model with three sub-processes and proposed timers, a requirements document, user stories, wireframes and a two-sprint UAT. I do not claim business results for it, only the work above.
Lessons we recorded
- Get stakeholders to define their objectives clearly, in writing.
- Map the data flow between SAGE, HubSpot and Salesforce before writing stories about it.
- Test and validate effectively, and document the integration process.
- Communicate with all stakeholders, and facilitate sprint planning and refinement as a team.