Redesign SaaS Onboarding with BPMN

Model and trace a SaaS onboarding redesign with BPMN, Jira, and UAT.

Introduction

30 Second Summary

A signed customer expects account access quickly. Manual handoffs can turn that first promise into scattered emails with no clear owner.

In this project, you will redesign BrightDesk's customer onboarding workflow as a Systems Analyst. You will publish one GitHub case study that links BPMN models from draw.io, testable requirements, Jira Cloud work items, requirements traceability, and UAT cases.

What You'll Build

Picture opening one GitHub repository for a recruiter to follow the broken onboarding workflow all the way to a modelled, traceable, testable recommendation.

By the end of this project, you'll have:

A visual process story where as-is and to-be BPMN diagrams expose the rework loop before showing the controlled future flow.
A traceability chain that lets a reviewer follow each business need through requirements, Jira tasks, acceptance criteria, and UAT cases.
A recruiter-ready case study you can open in GitHub to explain your analysis decisions from problem statement to acceptance plan.
Secret Mission: Assess an enterprise SSO request while preserving scope control and end-to-end traceability.

Are there any prerequisites?

You need a Windows computer plus an existing GitHub account. Familiarity with software delivery helps, but no analyst experience or existing Jira Cloud access is required.

Before We Start

Treating BrightDesk as a real stakeholder engagement keeps your analysis focused on the people affected by slow onboarding. This is your moment to commit to solving the business problem before you begin the hands-on work.

Set Up the Analyst Workspace

Separate artifacts quickly lose their connection to the original business problem. That gap makes it difficult to explain how a stakeholder need became a testable change.

A Jira Cloud board will hold the delivery work. A draw.io canvas will hold the process models.

A GitHub repository will connect the analysis in one shareable case study. Together, these tools create the evidence chain you will build throughout the project.

In this step, get ready to:

Create a Jira Cloud Free team-managed Kanban space for the delivery backlog.
Prepare a draw.io canvas with BPMN shapes available.
Publish the starting case study in a public GitHub repository.

Create the Jira workspace

The Jira space gives future requirements a visible route into delivery. Its Kanban board keeps work available as a continuous flow without adding sprint ceremony.

Choose the route that matches your current Jira Cloud access.

✔️ I already have Jira Cloud Free

Open your existing Jira Cloud Free site.
Confirm that the site uses the Free plan.

ⓧ I need a Jira Cloud site

This route stays on Jira Cloud Free, so the project does not require a paid plan. The Free plan supports up to 10 users.

Signup does not require a credit card.

Open the Jira Cloud Free sign-up flow.
Complete the account prompts to create your Jira Cloud Free site.
Decline any option that starts a Standard or Premium trial.

Select Spaces in the Jira navigation.
Select Create space.
Choose the Kanban template.
Select Use template.
Choose Team-managed.
Enter BrightDesk Onboarding as the space name.
Select Create.

Why Use a Team-Managed Kanban Space?

A team-managed space keeps this exercise contained within its own board. The Kanban template displays work as it moves through a continuous workflow.

This gives every requirement a future delivery destination without adding sprint planning to the case study.

Confirm that the board shows a To do column.
Confirm that the board shows an In progress column.
Confirm that the board shows a Done column.

Your delivery workspace is ready. The three columns now give each future work item a visible status.

Board Columns Look Different?

Check that you selected the Kanban template.
Check that you chose a team-managed space.
Confirm that the space name is BrightDesk Onboarding.

Ask for help if the board still does not match: help me check my Jira Kanban space setup.

Prepare the draw.io BPMN canvas

The process diagrams need an editable source file that you can revise as the analysis develops. Local device storage keeps that source under your control.

Open the draw.io online editor in a new browser tab.
Choose local device storage when prompted.
Select File in the top menu.
Select New.
Choose Blank.
Name the diagram brightdesk-onboarding.drawio.
Select Create.

You should see a blank canvas with brightdesk-onboarding.drawio as the diagram name.

The process library sits behind the shape settings, so this control is easy to miss.

Select More Shapes at the bottom of the shapes panel.
Enable the BPMN 2.0 library.
Select Apply.
Confirm that the shapes panel now includes the BPMN library.
Confirm that the canvas remains blank.

What Does the BPMN Library Add?

The library provides the standard visual language for modelling process work. You will use it to separate responsibilities from decisions throughout the onboarding flow.

Keeping the editable source preserves every shape for later changes.

Your modelling canvas is ready. You can now build both process views from the same editable file.

Can't See the BPMN Shapes?

Return to More Shapes.
Check that the BPMN 2.0 library is enabled.
Select Apply again.

Ask for help if the library still does not appear: help me enable BPMN shapes in draw.io.

Publish the GitHub repository

The repository gives the analysis one public location that a reviewer can follow. Its README.md file becomes the narrative for the case study.

Open GitHub in a new browser tab.
Select New repository.
Enter saas-onboarding-analysis as the repository name.
Choose Public for the repository visibility.
Enable Add README.
Select Create repository.

GitHub should open the new public repository with README.md rendered on its front page.

The first line uses Markdown to give the case study a clear title.

Open README.md from the repository file list.
Select the file editor control in the file toolbar.
Delete the existing README content.
Replace the content by pasting the following heading:

# BrightDesk SaaS Onboarding Analysis

What Does This Markdown Do?

The # marker creates the top-level page heading.
The heading names the fictional business case that every later artifact will support.

Select Preview.
Confirm that the preview shows BrightDesk SaaS Onboarding Analysis as the main heading.
Select Commit changes....
Choose the option to commit directly to main.
Confirm the commit.

The repository front page should now render the new heading from README.md.

README Heading Not Rendering?

Check that the line begins with one # character.
Check that you edited README.md.
Confirm that the commit appears on main.

Ask for help if the old content still appears: help me fix my GitHub README heading.

✔️ Awesome, I've got everything!

Your public repository now contains the starting case study heading on main.

ⓧ I'd like to double check the full code

Compare your complete README.md file with this version:

# BrightDesk SaaS Onboarding Analysis

What Should Match?

The file contains one top-level heading. It ends with a blank line so the next case study section can begin cleanly.

Before the final check, which of the three browser tabs do you expect to reveal a missing setup detail?

Switch back to the Jira board tab.
Confirm that BrightDesk Onboarding shows To do, In progress, and Done.
Switch back to the draw.io tab.
Confirm that brightdesk-onboarding.drawio shows a blank canvas with the BPMN 2.0 library enabled.
Switch back to the GitHub repository tab.
Confirm that the public saas-onboarding-analysis repository renders BrightDesk SaaS Onboarding Analysis from README.md on main.

That is the full analyst workspace connected. Your backlog, modelling canvas, and case study now have clear homes.

Your evidence chain is ready. Next, you will map the current onboarding process and expose where its handoffs break down.

Map the Broken Onboarding Process

Your analyst workspace is ready. The Jira board stays empty while you investigate the current process.

The sponsor's request hides missing data. It also leaves ownership unclear.

The rework disappears inside email. You will document the evidence in GitHub before modelling the current flow with BPMN in draw.io.

In this step, get ready to:

Define the onboarding problem plus its scope boundaries.
Model the manual handoffs plus exception paths.
Test the sponsor request for an unambiguous pass or fail result.

Document the problem and boundaries

Scope definition establishes where the analysis begins. It also establishes where the analysis ends.

Stakeholder analysis records who participates in the process. Decision authority shows who can settle questions about each part of the flow.

What belongs in the current-state analysis?

Problem statement: Manual email creates delay. Spreadsheet re-entry adds another manual handoff. Finance checks payment separately. IT receives provisioning work through an untracked handoff.
In scope: The process begins when Sales marks a subscription Closed Won. It ends when the Customer Administrator receives account access. It covers handoff completeness. It covers payment confirmation. It covers provisioning. It covers the welcome message.
Out of scope: Implementing the fictional onboarding system sits outside this case study. Sales activity before Closed Won sits outside the process boundary. Customer activity after access is received also sits outside the process boundary.
Assumptions: Sales starts the process after Closed Won. The spreadsheet is the current handoff record. Finance confirms payment before IT provisions access. Customer Success sends the welcome message after provisioning.

Return to the saas-onboarding-analysis repository from earlier.
Select README.md from the repository file list.
Select the file editor control above the file content.
Add a Problem and Scope section using the current-state analysis above.
Add an Assumptions section using the four assumptions above.
Select Preview to check the rendered sections.

You should see a clear process boundary from Closed Won to customer access. The problem statement should name each manual handoff that contributes to delay.

Stakeholder Row Guide

Sales Representative: The goal is a complete handoff. The responsibility is to mark the deal Closed Won. The role emails the spreadsheet. The role corrects missing information. The authority covers sales details plus customer data.
Customer Success Manager: The goal is timely onboarding. The responsibility is to re-enter handoff data. The role checks completeness. The role sends the welcome message. The authority covers accepting or returning a handoff.
Finance Analyst: The goal is to prevent unpaid onboarding from progressing. The responsibility is to check payment. The authority covers confirming payment or pausing onboarding.
IT Provisioning Specialist: The goal is to provide the correct tenant plus administrator account. The responsibility is to provision access after payment confirmation. The authority covers confirming that provisioning is complete.
Customer Administrator: The goal is to receive working account access. The responsibility is to receive the welcome message. The authority covers confirming whether customer access was received.
Executive Sponsor: The goal is faster onboarding. The responsibility is to set the business outcome. The authority covers approving the target plus the analysis scope.

Return to the file editor.
Add a Stakeholders section below the assumptions.
Create a table with columns for Stakeholder, Goal, Process Responsibility, plus Decision Authority.
Populate the six stakeholder rows using the row guide.
Select Preview to render the table.

You should see six rows. Each row should separate what the stakeholder does from what the stakeholder can decide.

Select Commit changes... above the editor.
Choose the option to commit directly to main.
Select Commit changes to save the analysis.

Model the current onboarding process

A current-state process model makes invisible handoffs observable. Pools separate participants while lanes show responsibility inside one participant.

How Do the BPMN Shapes Work?

Pool represents one process participant.
Lane divides a pool by role or function.
Task represents work in a rounded rectangle.
Gateway uses a diamond to split the process according to a decision.
Sequence Flow shows the order of work inside one pool.
Message Flow carries communication between separate pools.

Switch back to the brightdesk-onboarding.drawio canvas from earlier.
Add a Pool labelled BrightDesk.
Divide the BrightDesk pool into four lanes.
Label the lanes Sales, Customer Success, Finance, plus IT.
Add a separate Pool below the BrightDesk pool.
Label the separate pool Customer.
Save the updated brightdesk-onboarding.drawio file to local device storage.

Your canvas should now show one internal process with four owners. The customer sits outside that process as a separate participant.

Add a Task labelled Mark deal Closed Won to the Sales lane.
Add a second Sales task labelled Email spreadsheet.
Connect Mark deal Closed Won to Email spreadsheet with a Sequence Flow.
Add a Customer Success task labelled Re-enter handoff data.
Connect Email spreadsheet to Re-enter handoff data with a Sequence Flow.
Add a Customer Success task labelled Check completeness.
Connect Re-enter handoff data to Check completeness with a Sequence Flow.
Add a Gateway labelled Handoff complete? after the completeness check.

Check the Manual Handoff

The lane change from Sales to Customer Success exposes the first manual handoff. The separate re-entry task shows that the spreadsheet data is copied into another tracker.

Connect Check completeness to Handoff complete? with a Sequence Flow.
Add a Sales task labelled Correct missing information.
Draw a Sequence Flow labelled No from Handoff complete? to Correct missing information.
Draw a Sequence Flow from Correct missing information back to Email spreadsheet.
Add a Finance task labelled Check payment.
Draw a Sequence Flow labelled Yes from Handoff complete? to Check payment.
Add a Gateway labelled Payment complete? in the Finance lane.
Connect Check payment to Payment complete? with a Sequence Flow.

Check the Rework Loop

The No path should visibly return work to Sales. This loop makes the email chase part of the process evidence.

Add a Finance task labelled Pause onboarding.
Draw a Sequence Flow labelled No from Payment complete? to Pause onboarding.
Add an IT task labelled Provision tenant and administrator account.
Draw a Sequence Flow labelled Yes from Payment complete? to the provisioning task.
Add a Customer Success task labelled Send welcome message.
Draw a Sequence Flow from the provisioning task to Send welcome message.
Add a Customer task labelled Receive customer access.
Draw a Message Flow from Send welcome message to Receive customer access.

What Should the Model Show?

All Sequence Flows should remain inside the BrightDesk pool. Only the Message Flow should cross into the Customer pool.

The completed model should expose two exception paths. One returns incomplete data to Sales. The other pauses unpaid onboarding.

Save the completed brightdesk-onboarding.drawio file to local device storage.
Inspect the canvas at a zoom level where both pools plus the rework loop remain visible.

Test the sponsor request and publish the evidence

The sponsor's sentence now gets a formal testability check. Each question asks for evidence needed to judge success.

Use These Six Testability Questions

Who benefits?
What triggers the change?
Which inputs are mandatory?
What observable result is required?
What time limit applies?
What happens on failure?

Return to README.md in the GitHub repository.
Select the file editor control.
Add a Testability Check section.
Enter the sponsor request Automate onboarding and make it faster.
Create a table with columns for Testability Question plus Answer Supported by the Request.
Add the six testability questions as table rows.

Before you test it, do you think this sentence gives enough evidence for an unambiguous pass or fail result?

Read the sponsor request once without using any scenario details.
Assess each question using only the words in the request.

Every question remains unanswered. The request expresses an ambition without defining a testable outcome.

Enter Unanswered beside each testability question.
Add an Analysis Gaps section that records the missing beneficiary, trigger, mandatory inputs, observable result, time limit, plus failure handling.
Select Preview to render the testability table.

You should see six visible analysis gaps. That failed testability check is the intended result.

Select Commit changes... above the editor.
Choose the option to commit directly to main.
Select Commit changes to save the testability analysis.

A PNG provides a browser-friendly view of the process. The .drawio source preserves the editable model.

Switch back to the completed draw.io model.
Select File from the editor menu.
Select Export as.
Select PNG.
Select Export in the export dialog.
Save the exported image as as-is-onboarding.png on your local device.

The exported image should show the full BrightDesk pool plus the Customer pool. The rework loop should remain readable.

Return to the saas-onboarding-analysis repository.
Select Add file above the repository file list.
Select Upload files.
Choose brightdesk-onboarding.drawio from local device storage.
Choose as-is-onboarding.png from local device storage.
Enter Add as-is BPMN analysis as the commit message.
Choose the option to commit directly to main.
Commit the uploaded files.

Both diagram files should now appear beside README.md in the repository file list.

Return to the README.md file editor.
Add an As-Is Process section.
Embed the image using the Markdown line ![As-is BrightDesk onboarding process](as-is-onboarding.png).
Select Preview to render the image.

You should see the as-is diagram inside the README preview. The image link should display the process instead of a broken-image symbol.

Select Commit changes... above the editor.
Choose the option to commit directly to main.
Select Commit changes to publish the current-state case study.

Before the final review, which evidence do you expect to notice first in the rendered case study: the straight path or the rework loop?

Return to the front page of the saas-onboarding-analysis repository.
Review the rendered README.md beneath the file list.
Confirm that the stakeholder table contains all six roles.
Confirm that the testability table contains six Unanswered results.
Open as-is-onboarding.png from the repository file list.
Trace the incomplete-handoff path back to Sales.
Trace the unpaid path to Pause onboarding.
Trace the Message Flow from the welcome message to customer access.

You should see the manual spreadsheet handoff plus the data re-entry. You should also see the rework loop, payment pause, provisioning handoff, welcome message, plus customer access.

That current-state evidence is now working as one case study. The sponsor request also has no unambiguous pass or fail result.

Diagram or Image Not Looking Right?

Confirm that the filename in the README link exactly matches as-is-onboarding.png.
Keep every Sequence Flow inside the BrightDesk pool.
Use a Message Flow for the connector that crosses into the Customer pool.
Check that the No path from Handoff complete? returns to the Sales correction task.

Help me troubleshoot my BrightDesk as-is BPMN model or GitHub image link.

You have exposed where BrightDesk onboarding breaks down. Next, you will turn the unanswered questions into traceable requirements.

Define Traceable Requirements

Your as-is BPMN model now exposes the incomplete-handoff loop. It also shows the provisioning delays hidden inside the sponsor's request.

The request still cannot guide delivery because the six testability questions have no agreed answers. In this step, you will turn simulated stakeholder decisions into classified requirements with visible destinations in the future process.

In this step, get ready to:

Record the agreed stakeholder decisions.
Classify seven measurable requirements.
Publish a future-state BPMN model that reflects the requirements.

Record the agreed stakeholder decisions

A decision log closes each analysis gap with an agreed rule. Keeping these decisions in GitHub preserves the reasoning behind every requirement.

Return to README.md in the saas-onboarding-analysis repository.
Select the edit control above the rendered README.
Add the agreed answers beneath the as-is process section by pasting this Markdown:

## Clarified Stakeholder Decisions

- Mandatory handoff fields: customer name, subscription plan, administrator email, and payment reference.
- Service clock: starts after a complete handoff.
- Target: account access within one business day after a complete sales handoff.
- Provisioning owner: IT.
- Welcome notification rule: send only after onboarding status is Ready.
- Cutover ownership rule: every open onboarding record must have an owner before cutover.

Why These Decisions Matter

The mandatory fields give completeness an objective definition.
The clock rule establishes the exact trigger for measuring the target.
The ownership rules identify who controls provisioning before launch.
The Ready rule prevents a welcome message from promising access too early.
The cutover rule prevents open records from entering the new process without an owner.

Select Preview above the README editor.
Review the six decisions in the rendered section.

You should see a named rule for each analysis gap from the previous step.

Select Commit changes....
Use the option that commits directly to main.
Complete the commit with the confirmation control.

That closes the ambiguity gap. Your case study now records the decisions that shape the proposed process.

Decisions Missing From the Preview?

Confirm that you pasted the section inside the README.md editor. Check that the heading begins with two hash characters.

Ask for help to repair the Markdown section.

Classify the measurable requirements

Requirement classification separates the business outcome from stakeholder needs. It also distinguishes system behaviour from quality expectations and cutover work.

Adding a source plus a process destination creates the first layer of requirements traceability. Each row can now be followed backward to a stakeholder and forward to the future process.

Return to the README.md file editor.
Add the requirements table beneath the clarified decisions by pasting this Markdown:

## Classified Requirements

| Requirement ID | Type | Stakeholder Source | Measurable Requirement | To-Be Process Destination |
| --- | --- | --- | --- | --- |
| BR-01 | Business | Executive Sponsor | Achieve account access within one business day after a complete sales handoff. | Complete onboarding within the target. |
| SR-01 | Stakeholder | Customer Success Manager | Customer Success receives complete handoff data containing customer name, subscription plan, administrator email, and payment reference. | Validate required fields. |
| FR-01 | Functional | Customer Success Manager | Block incomplete submissions. | Return invalid handoffs to Sales. |
| FR-02 | Functional | IT Provisioning Specialist | Create and assign provisioning work after validation and payment confirmation. | Create and assign provisioning work. |
| FR-03 | Functional | Customer Success Manager | Send the welcome message only after onboarding status is Ready. | Send the welcome message after Ready. |
| NFR-01 | Non-functional | Executive Sponsor | Record who changed onboarding status and when. | Record the Ready status change. |
| TR-01 | Transition | Customer Success Manager | Review and assign every open onboarding record before cutover. | Complete the cutover readiness review. |

How the Table Creates Traceability

BR-01 defines the business result that the complete change must support.
SR-01 captures what Customer Success needs from the sales handoff.
FR-01 through FR-03 define observable process behaviour.
NFR-01 defines the audit information that must exist around a status change.
TR-01 defines the temporary work required before the new process starts.

Select Preview above the README editor.
Audit each row for a requirement ID.
Audit each row for a type.
Audit each row for a stakeholder source.
Audit each row for a measurable statement.
Audit each row for a future-process destination.

You should see seven complete rows from BR-01 through TR-01.

Select Commit changes....
Commit the requirements table directly to main.

Your vague sponsor request is now a testable requirement set. Every requirement has an owner in the analysis and a destination in the proposed process.

Table Columns Not Rendering?

Check that every table row starts with a pipe character. Confirm that the separator row remains directly below the header row.

Ask for help to fix the requirements table.

Build the future-state BPMN model

The to-be model turns each requirement into a visible process response. A dedicated automation lane makes validation and work assignment explicit.

The open draw.io source will hold both process states. This keeps the original evidence beside the recommended design.

Switch back to the draw.io tab from earlier.
Add a second diagram page using the page controls below the canvas.

You should see a blank second canvas while the as-is model remains on its original page.

Rename the second page To-Be Onboarding.
Add a BPMN Pool shape for BrightDesk.

You should see the new BrightDesk participant on the future-state page.

Divide the BrightDesk pool into five lanes.

Use This Lane Order

Sales.
Customer Success.
Finance.
IT.
Onboarding Automation.

Apply the listed lane order from top to bottom.
Add a separate BPMN Pool for Customer.

You should see five BrightDesk responsibilities inside one participant. The Customer remains a separate participant.

Keep Flows Inside Their Boundaries

A Sequence Flow connects work performed inside the BrightDesk pool. A Message Flow crosses the participant boundary to the Customer pool.

These boundaries show who controls each action. They also prevent the customer interaction from looking like internal BrightDesk work.

Place a Start Event labelled Complete sales handoff in the Sales lane.
Place an Activity labelled Validate required fields in the Onboarding Automation lane.

You should see the agreed handoff trigger beside the first automated control.

Connect the Start Event to Validate required fields with Sequence Flow.
Attach a text annotation listing customer name, subscription plan, administrator email, payment reference to the validation Activity.

The model now shows the exact fields that make a handoff complete.

Attach a text annotation stating Service clock starts here. Target: account access within one business day. to the Start Event.
Place a Gateway labelled Handoff complete? after validation.

The process now has an explicit measurement trigger and a completeness decision.

Place an Activity labelled Correct missing handoff data in the Sales lane.
Connect the No branch from the Gateway to the correction Activity.

You should see invalid handoffs returning to Sales with a named owner.

Connect Correct missing handoff data back to Validate required fields.
Place an Activity labelled Confirm payment in the Finance lane.

The invalid path now forms a controlled correction loop. Finance owns the next check on the valid path.

Connect the Yes branch from the Gateway to Confirm payment.
Place an Activity labelled Create and assign provisioning work in the Onboarding Automation lane.

You should see provisioning work positioned after both completeness validation and payment confirmation.

Connect Confirm payment to Create and assign provisioning work.
Place an Activity labelled Provision tenant and administrator account in the IT lane.

The automated handoff now gives IT a clearly assigned unit of work.

Connect Create and assign provisioning work to Provision tenant and administrator account.
Place an Activity labelled Set onboarding status to Ready in the Onboarding Automation lane.

You should see the provisioning result feeding a controlled readiness state.

Connect Provision tenant and administrator account to Set onboarding status to Ready.
Place an Activity labelled Send welcome message in the Customer Success lane.

The welcome message now sits after the Ready state required by FR-03.

Connect Set onboarding status to Ready to Send welcome message.
Place an End Event labelled Complete onboarding after the welcome Activity.

You should see one controlled route from a complete handoff to completed onboarding.

Connect Send welcome message to the Complete onboarding End Event.
Place an Activity labelled Receive account access inside the Customer pool.

The internal process now ends beside the customer outcome it is designed to produce.

Connect Send welcome message to Receive account access with Message Flow.
Attach a text annotation stating Record who changed onboarding status and when. to the Ready Activity.

The customer notification crosses the participant boundary correctly. The Ready change now carries the audit expectation from NFR-01.

Add a text annotation stating Before cutover, review and assign every open onboarding record. near the Start Event.
Connect the annotation to the Start Event with an Association.

The future-state model now includes the transition control from TR-01.

Save the editable source back to brightdesk-onboarding.drawio using the editor's save control.
Confirm that the source contains the as-is page and the To-Be Onboarding page.

You should see both process states available from the page controls.

Keep the To-Be Onboarding page active.
Select File.
Select Export as.
Select PNG.
Select Export.
Save the export as to-be-onboarding.png on your local device.

You should see to-be-onboarding.png in the location you selected.

Return to the saas-onboarding-analysis repository.
Select Add file.
Select Upload files.
Choose the updated brightdesk-onboarding.drawio file.
Choose to-be-onboarding.png.

You should see both diagram files listed in the upload area.

Enter Add traceable requirements and to-be process in the Commit message field.
Use the option that commits directly to main.
Complete the upload with the commit control.

Your repository should now list README.md, brightdesk-onboarding.drawio, as-is-onboarding.png, and to-be-onboarding.png.

Return to the README.md file editor.
Add the future-state process section beneath the requirements table by pasting this Markdown:

## To-Be Process

The future-state BPMN model shows validation, ownership, provisioning, and controlled customer notification.

![To-be BPMN model showing automated validation, invalid-handoff return, payment confirmation, assigned provisioning work, provisioning, Ready status, controlled welcome notification, and completion](to-be-onboarding.png)

What This Section Adds

The image reference renders the uploaded PNG inside the case study. Its description explains the process content when the image cannot be viewed.

The README now connects the written requirements to the future-state model in the same repository.

Select Preview.
Confirm that the future-state diagram renders beneath the requirements table.
Select Commit changes....
Commit the finished README directly to main.

Diagram Missing From the README?

Confirm that the uploaded filename is exactly to-be-onboarding.png.

Check that the image reference uses the same lowercase filename. Ask for help to repair the rendered diagram link.

Before you run the final audit, do you expect every requirement to have a complete route from stakeholder source to future-process destination?

Return to the rendered README.md.
Audit every requirement row for its ID.
Audit every requirement row for its type.
Audit every requirement row for its source.
Audit every requirement row for its measurable statement.
Audit every requirement row for its future-process destination.
Select the rendered to-be-onboarding.png image.

You should see validation followed by invalid-handoff return and payment confirmation. You should also see assigned provisioning work followed by provisioning and the Ready-gated welcome message.

The diagram should end with completed onboarding and customer access. The audit annotations should cover status changes plus cutover ownership.

Your proposed process now rests on classified requirements with visible lineage. Next, you will turn the solution requirements into Jira work items and extend that lineage into a traceability matrix.

Build the Jira Backlog and Traceability

Your future-state process now shows how onboarding should flow. Delivery can still drift when approved requirements never become owned backlog items.

You will create five testable tasks in Jira Cloud. A requirements traceability matrix in GitHub will expose any requirement with no process step, backlog key, acceptance reference, or planned test.

In this step, get ready to:

Create five Jira tasks with measurable acceptance criteria.
Link each task to the business need in a traceability matrix.
Audit the backlog with INVEST.

Create five testable Jira tasks

A user story states who needs a capability. Its acceptance criteria define the observable conditions that make the work complete.

Task Specifications

For FR-01, use the title Block incomplete onboarding submissions. Use the story As a Customer Success Manager, I want incomplete submissions blocked so that only complete handoffs enter onboarding. The first criterion rejects a submission when the customer name is missing. The same rule applies when the subscription plan is missing. The same rule applies when the administrator email is missing. The same rule applies when the payment reference is missing. The second criterion identifies every missing field. The third criterion advances a complete submission to payment confirmation.
For FR-02, use the title Create and assign provisioning work after validation and payment. Use the story As an IT Provisioning Specialist, I want provisioning work created after validation and payment so that I receive an owned task at the correct time. The first criterion creates exactly one provisioning task after validation passes. Payment must also be confirmed. The second criterion assigns the task to IT. The third criterion links the task to its onboarding record.
For FR-03, use the title Send welcome notification only after Ready. Use the story As a Customer Administrator, I want the welcome notification sent after Ready so that I receive access at the correct time. The first criterion prevents a notification before Ready. The second criterion sends exactly one notification when the status becomes Ready. The third criterion records that the notification was sent.
For NFR-01, use the title Audit onboarding status changes with actor and timestamp. Use the story As an Executive Sponsor, I want every onboarding status change recorded so that the process can be audited. The first criterion records the actor for every status change. The second criterion records the timestamp for every status change. The third criterion displays both values in the onboarding history.
For TR-01, use the title Review and assign all open records before cutover. Use the story As a Customer Success Manager, I want every open record reviewed before cutover so that no onboarding loses its owner. The first criterion identifies every open onboarding record. The second criterion gives every identified record a named owner. The third criterion blocks cutover while any open record has no owner.

Switch back to the BrightDesk Onboarding board in Jira.
Select Create (+) in the top navigation.
Choose Task as the work type.
Enter the next specification title in Title.
Enter its requirement ID at the top of Description.
Add its user story on a new line.
Add its acceptance criteria below the user story.
Select Create.

Jira creates the first task. Your site may show Summary as the legacy equivalent of Title.

Repeat the creation flow for the remaining four task specifications.

Jira generates a unique key for every task. Capture those keys now because the traceability matrix uses them as forward links.

Record the generated key for FR-01 here: your FR-01 Jira key.
Record the generated key for FR-02 here: your FR-02 Jira key.
Record the generated key for FR-03 here: your FR-03 Jira key.
Record the generated key for NFR-01 here: your NFR-01 Jira key.
Record the generated key for TR-01 here: your TR-01 Jira key.
Return to the Jira board.
Confirm that five Task work items are visible in To do.

That closes the delivery gap. Every solution requirement now has a testable backlog item.

Missing a Task or Jira Key?

Open each task from the board to confirm its requirement ID appears in Description. Create any missing requirement before you continue.

If your site shows Summary, use it for the task title. Help me check my five BrightDesk Jira tasks.

Build the traceability matrix

A traceability row should answer where a requirement came from. It should also reveal where the requirement appears in the process, backlog, acceptance criteria, and planned UAT coverage.

Your README.md will use Markdown tables to keep those links visible. Each row connects one solution or transition requirement back to both BR-01 and SR-01.

Backlog Entries to Record

List FR-01 with your FR-01 Jira key and the title Block incomplete onboarding submissions.
List FR-02 with your FR-02 Jira key and the title Create and assign provisioning work after validation and payment.
List FR-03 with your FR-03 Jira key and the title Send welcome notification only after Ready.
List NFR-01 with your NFR-01 Jira key and the title Audit onboarding status changes with actor and timestamp.
List TR-01 with your TR-01 Jira key and the title Review and assign all open records before cutover.

Return to the saas-onboarding-analysis repository from earlier.
Open README.md in the file editor.
Add a ## Jira Backlog heading after the requirements section.
Add the five backlog entries from the reference above.
Select Preview.

You should see a Jira Backlog section with five requirement IDs. Each entry should show its captured Jira key.

Traceability Rows to Record

For the FR-01 row, use BR-01 / SR-01 for Business Need. Use FR-01 for Requirement ID. Use Customer Success Manager for Stakeholder Source. Use Validate required fields for To-Be Process Step. Use your FR-01 Jira key for Jira Key. Summarize the acceptance criteria as Reject incomplete handoff. Identify every missing field. Advance complete handoff to payment confirmation. Use UAT-01 for UAT ID.
For the FR-02 row, use BR-01 / SR-01 for Business Need. Use FR-02 for Requirement ID. Use Finance Analyst / IT Provisioning Specialist for Stakeholder Source. Use Create and assign provisioning work for To-Be Process Step. Use your FR-02 Jira key for Jira Key. Summarize the acceptance criteria as Create one task after validation plus payment confirmation. Assign the task to IT. Link the onboarding record. Use UAT-02 for UAT ID.
For the FR-03 row, use BR-01 / SR-01 for Business Need. Use FR-03 for Requirement ID. Use Customer Administrator / Customer Success Manager for Stakeholder Source. Use Send welcome message after Ready for To-Be Process Step. Use your FR-03 Jira key for Jira Key. Summarize the acceptance criteria as Prevent notification before Ready. Send one notification at Ready. Record the send event. Use UAT-03 for UAT ID.
For the NFR-01 row, use BR-01 / SR-01 for Business Need. Use NFR-01 for Requirement ID. Use Executive Sponsor for Stakeholder Source. Use Set status to Ready for To-Be Process Step. Use your NFR-01 Jira key for Jira Key. Summarize the acceptance criteria as Record the actor. Record the timestamp. Display both values in status history. Use UAT-04 for UAT ID.
For the TR-01 row, use BR-01 / SR-01 for Business Need. Use TR-01 for Requirement ID. Use Customer Success Manager / Executive Sponsor for Stakeholder Source. Use Pre-cutover review and ownership assignment for To-Be Process Step. Use your TR-01 Jira key for Jira Key. Summarize the acceptance criteria as Identify every open record. Assign every record. Block cutover while ownership is blank. Use UAT-05 for UAT ID.

Return to the README.md file editor.
Add a ## Requirements Traceability Matrix heading below the Jira Backlog section.
Build the table header with Business Need, Requirement ID, Stakeholder Source, To-Be Process Step, Jira Key, Acceptance Criteria, and UAT ID. Separate the columns with |. Place at least --- beneath each heading.
Add the five rows from the traceability reference.
Select Preview.

You should see a rendered matrix with five rows. Every row should contain values across all seven columns.

Return to the file editor.
Select Commit changes....
Enter Add Jira backlog and traceability matrix as the commit message.
Complete the commit directly on main.

Table Not Rendering?

Confirm that a blank line sits between the heading and the table. Check that every header has at least --- in the separator row.

Count seven cells in every row. Help me repair my README traceability table.

Audit the backlog with INVEST

The INVEST check tests whether a backlog item is independent, negotiable, valuable, estimable, small, and testable. The audit also makes sequencing dependencies visible before delivery begins.

How to Apply INVEST

Independent checks whether the task can be delivered without being bundled into unrelated work.
Negotiable checks whether the implementation can change while the requirement outcome stays intact.
Valuable checks whether the task contributes to a stakeholder or business need.
Estimable checks whether a delivery team has enough detail to size the task.
Small checks whether the task has a focused outcome.
Testable checks whether the acceptance criteria produce an objective pass or fail result.

Return to the README.md file editor.
Add a ## INVEST Audit heading below the traceability matrix.
Create columns for Work Item, Independent, Negotiable, Valuable, Estimable, Small, Testable, and Refinement.
Select Preview.

You should see the empty INVEST table beneath the traceability matrix. The next entries record the audit result for every task.

Audit Findings to Record

Record Yes across all six INVEST checks for FR-01. Record No change needed under Refinement because every criterion has an observable result.
Record No. Sequenced after validation and payment confirmation. under Independent for FR-02. Record Yes for the other five checks. Record Keep as one small task. Document the sequencing dependency. under Refinement.
Record No. Sequenced after Ready status. under Independent for FR-03. Record Yes for the other five checks. Record Keep as one small task. Document Ready as the trigger. under Refinement.
Record Yes across all six INVEST checks for NFR-01. Record No change needed under Refinement because actor plus timestamp creates an objective audit check.
Record Yes across all six INVEST checks for TR-01. Record No change needed under Refinement because blank ownership creates an objective cutover check.

Return to the file editor.
Populate all five INVEST rows with the audit findings.
Select Preview.

You should see five audit rows. The two sequencing dependencies should be visible without weakening their acceptance criteria.

Return to the file editor.
Select Commit changes....
Enter Add INVEST backlog audit as the commit message.
Complete the commit directly on main.

Before the final check, do you expect every mapped requirement to have a process step, Jira key, acceptance reference, and planned UAT ID?

Switch back to the BrightDesk Onboarding board.
Confirm that five Task work items remain in To do.
Compare the five visible Jira keys with the keys in README.md.
Return to the rendered repository front page.
Confirm that every traceability row links BR-01 plus SR-01 to one solution or transition requirement.
Confirm that no row has a blank process step, Jira key, acceptance reference, or UAT ID.
Confirm that the INVEST audit covers all five Jira tasks.

Strong work. Your case study now shows a complete path from business intent to delivery work with every gap exposed.

Your backlog is linked and testable. Next, you will design the UAT cases that decide whether BrightDesk accepts the proposed process.

Design UAT and Publish the Case Study

Your Jira backlog now turns each approved requirement into measurable delivery work. The remaining question is whether a business stakeholder could judge the proposed outcome without interpretation.

User acceptance testing (UAT) answers that question with observable scenarios derived from acceptance criteria. In this step, you will link five UAT cases to requirements before publishing the complete GitHub case study.

In this step, get ready to:

Design five UAT cases with observable expected results.
Connect every requirement to acceptance evidence through requirements traceability.
Publish the finished case study with both BPMN images.

Build the UAT matrix

A UAT matrix turns each requirement into a business-facing decision. A useful case produces an objective pass or fail result from a defined starting situation.

What should each case prove?

Each scenario uses Given to establish its precondition. When identifies the business action. Then states the observable result.

Link UAT-01 to FR-01. Use the Sales Representative as the business role. Establish a handoff that is missing the administrator email. Submit the handoff. Block the submission. Identify the missing field.
Link UAT-02 to FR-02. Use the IT Provisioning Specialist as the business role. Establish a complete handoff with confirmed payment. Complete validation. Create provisioning work. Assign that work to IT.
Link UAT-03 to FR-03. Use the Customer Success Manager as the business role. Establish an account whose status is not Ready. Attempt to send the welcome message. Prevent the notification.
Link UAT-04 to NFR-01. Use the Customer Success Manager as the business role. Establish an active onboarding record. Change its status. Record the actor. Record the timestamp.
Link UAT-05 to TR-01. Use the Customer Success Manager as the business role. Establish open onboarding records before cutover. Perform the cutover review. Assign an owner to every open record.

Return to README.md in the saas-onboarding-analysis repository.
Select the edit control above the file.
Create a UAT section after Traceability with columns for UAT ID, Requirement ID, Business Role, Preconditions, Given/When/Then Scenario, Expected Result, and Status.
Add the five cases from the coverage map to the UAT matrix.
Set every case status to Not Run.

Before you preview the matrix, do you expect every case to end with an outcome that a stakeholder can observe?

Select Preview above the file editor.

You should see five UAT rows covering incomplete handoff rejection, provisioning assignment, notification prevention, status auditing, and cutover ownership.

Return to the file editor.
Update the existing traceability matrix so FR-01, FR-02, FR-03, NFR-01, and TR-01 point to their matching UAT IDs.

Before you check again, can every delivery requirement now reach one observable expected result?

Select Preview again.

You should see a UAT reference for every mapped solution requirement and transition requirement. That is the testing backbone complete: every delivery requirement now has acceptance evidence.

Missing a UAT link?

Check that each requirement ID uses the same spelling in the traceability matrix and UAT matrix.
Confirm that each UAT ID appears beside the requirement it tests.

If a link is still missing, help me audit my UAT coverage.

Test each case against acceptance criteria

Acceptance criteria define when each backlog item is complete. Its linked UAT case must test the same intent from the named business role.

Switch back to the BrightDesk Onboarding Jira board from earlier.
Open the FR-01 Task in To do.
Compare its acceptance criteria with the expected result in UAT-01.
Repeat the comparison for FR-02, FR-03, NFR-01, and TR-01.

What makes the result testable?

The Given statement names the starting condition required to run the case.
The When statement names one business action that triggers the behavior.
The Then statement names a visible result that supports an objective decision.
The expected result matches the corresponding acceptance criteria without relying on interpretation.

Return to the README.md file editor.
Refine all five scenarios using the three-part audit above.
Keep every case at Not Run because the fictional onboarding system has not been implemented.

Before you inspect the result, do you expect any row to depend on words such as faster, easy, or correctly?

Select Preview.

Each row should now state a concrete precondition, one business action, and an observable expected result. Every status should remain Not Run.

Expected result still feels vague?

Replace subjective wording with an outcome that a stakeholder can see in a record, status, assignment, notification, or audit entry.

For another review, help me make this UAT result measurable.

Publish the finished case study

Publishing turns the separate analysis artifacts into one evidence chain. A reviewer should be able to move from the business problem to the proposed process before reaching its acceptance cases.

The section order is a little fiddly because most of the content already exists in different parts of the file.

Return to the README.md file editor.
Arrange the existing material under Executive Summary, Problem and Scope, Stakeholders, As-Is Process, Findings, Requirements, To-Be Process, Jira Backlog, Traceability, UAT, Recommendation, Assumptions, and Next Steps.
Write an Executive Summary that states the onboarding problem, the one-business-day target, and the recommended future-state workflow.
Select Preview to confirm that the ordered headings render above their matching content.

You should see a clear narrative beginning with the business decision. The supporting analysis should follow in the same order as the evidence chain.

Return to the file editor.
Add as-is-onboarding.png to As-Is Process with a description that names the manual spreadsheet handoff, rework loop, payment pause, and provisioning handoff.
Select Preview to confirm that the as-is diagram renders below its description.

You should see the current-state diagram with text that explains the bottleneck before the image.

Return to the file editor.
Add to-be-onboarding.png to To-Be Process with a description that names validation, assigned provisioning, Ready status, and controlled notification.
Select Preview to confirm that the to-be diagram renders below its description.

You should now see both diagrams inside the case study. Their descriptions make the process change understandable before a reviewer reads every symbol.

Images not rendering?

Check that the image references match as-is-onboarding.png and to-be-onboarding.png exactly.
Confirm that both image files sit beside README.md on main.

If an image remains broken, help me fix my README image reference.

Switch back to the BrightDesk Onboarding Jira board.
Copy the board address from your browser into your BrightDesk Onboarding Jira space URL.
Return to the README.md file editor.
Add your BrightDesk Onboarding Jira space URL to the Jira Backlog section.
Write the Recommendation section with approval of the validated future-state workflow as the proposed next delivery direction.
Select Preview to confirm that the Jira link opens the BrightDesk Onboarding board.

The backlog link should lead to the five existing Tasks. The Recommendation should connect the future-state controls to the one-business-day target.

Return to the file editor.
Write the Next Steps section with stakeholder approval, implementation planning, and future UAT execution.
Review the Assumptions section for statements that still require stakeholder confirmation.

Before you preview the full case study, could a reviewer follow every requirement from its business source to its UAT result?

Select Preview.
Confirm that all thirteen case-study sections render in the required order.
Confirm that both BPMN images render with meaningful descriptions.
Confirm that FR-01, FR-02, FR-03, NFR-01, and TR-01 each reach at least one UAT case.
Confirm that every UAT case has an observable expected result.

You should see the complete BrightDesk analysis from Executive Summary through Next Steps. The evidence chain should include both process models, five Jira Tasks, the traceability matrix, and five Not Run UAT cases.

Return to the file editor.
Select Commit changes....
Enter Publish BrightDesk onboarding case study in the Commit message field.
Select the option to commit directly to main.
Confirm the commit.

Before you perform the final check, do you expect the repository front page to present the complete case study without opening another document?

Return to the front page of the saas-onboarding-analysis repository.

GitHub should render the finished README.md with every required section. You should see both diagrams plus complete links from requirements to UAT cases.

README still shows the older version?

Check that the repository branch selector shows main.
Confirm that the latest commit uses the message Publish BrightDesk onboarding case study.
Refresh the repository front page after the commit finishes.

If the update is still missing, help me find my GitHub README commit.

You made the full analysis chain visible. A reviewer can now follow the BrightDesk problem from process evidence through testable acceptance.

Secret mission

Secret Mission: Assess an Enterprise SSO Change Request

An enterprise SSO request arrives after the BrightDesk onboarding design is approved. You will assess its scope impact. You will defer it without creating unapproved delivery work.

Clean Up Your Resources

Your Jira Cloud Free space has no charge while the site stays within the documented limit of 10 users. Decide whether to keep the evidence available, pause active use, or delete every project-specific resource.

Resources you used:

One team-managed Kanban space named BrightDesk Onboarding with five Task work items.
One public GitHub repository named saas-onboarding-analysis containing the finished README.md case study plus the diagram files.
One editable draw.io source file named brightdesk-onboarding.drawio containing the BPMN models.
Two local diagram exports named as-is-onboarding.png and to-be-onboarding.png.

Keep everything running

No action needed. Choose this if you want to keep using the case study for interviews or future analysis practice.

Keep the BrightDesk Onboarding Jira space available for future walkthroughs.
Keep the public saas-onboarding-analysis repository available as your portfolio case study.
Retain brightdesk-onboarding.drawio as the editable source for both process models.
Retain as-is-onboarding.png and to-be-onboarding.png as viewable diagram exports.

Pause - I'll come back to this later

Step away while preserving the evidence needed to return. There are no running local processes to stop.

Leave the BrightDesk Onboarding Jira space idle.
Keep the public saas-onboarding-analysis repository available.
Retain brightdesk-onboarding.drawio as your editable diagram source.
Retain both PNG exports as local evidence of the approved process models.

Atlassian may deactivate inactive Free sites. Your README.md preserves the generated Jira keys if that happens.

Delete - I don't want to use this again

Deleting your online evidence can feel final. This option removes every project-specific resource listed above.

Switch back to Jira Cloud from earlier.
Select Spaces.
Select More actions.
Select Manage spaces.
Find BrightDesk Onboarding.
Select More actions for the BrightDesk Onboarding space.
Select Move to trash.
Confirm the cleanup by selecting Move.

You should see BrightDesk Onboarding move out of your active spaces. Jira retains the trashed space for 60 days before permanent deletion.

The public repository is the next project-specific resource.

Return to the saas-onboarding-analysis repository in GitHub.
Select Settings.
Scroll to Danger Zone.
Select Delete this repository.
Choose I want to delete this repository.
Choose I have read and understand these effects.
Enter saas-onboarding-analysis as the repository name.
Select Delete this repository to complete the deletion.

You should no longer be able to open the public repository page. The online case study has now been removed.

The remaining copies are stored in the folder you chose when saving the local diagram files.

Delete brightdesk-onboarding.drawio, as-is-onboarding.png, and to-be-onboarding.png from that folder.

You should no longer find the three BrightDesk diagram files in that folder. Your project-specific resources are now cleaned up.

Nice Work!

You did it! Your published GitHub case study now shows how you transformed BrightDesk's broken onboarding workflow into a scoped change proposal with testable outcomes.

You've learned how to:

Create as-is and to-be BPMN models in draw.io. Expose manual rework in the current process. Show validation, ownership, provisioning, and controlled notification in the future process.
Convert an ambiguous sponsor request into classified requirements with measurable outcomes. Build five testable Jira work items with objective acceptance criteria.
Build a requirements traceability matrix that connects the business need to process steps, Jira keys, acceptance criteria, and UAT cases. Publish the full analysis as a recruiter-ready case study.
Secret Mission: Assess an enterprise SSO change request without expanding the approved scope. Defend a Defer recommendation through backward and forward traceability.

Ready to quiz yourself?