Senior Maple's project load rose and fell with its clients' plans, so it used a managed team of five business analysts rather than hiring for each engagement.

1 person

Lead business analyst

Focus

Senior Maple's single point of contact; allocation, quality review and the shared playbook; leads discovery with large operators

2 people

Application business analysts

Focus

Enquiry, tour, follow-up and move-in processes; roles, journeys, data and backlogs

1 person

ERP and finance business analyst

Focus

Finance, resident billing, procurement and payroll processes; ERP requirements and data migration readiness

1 person

AI and data business analyst

Focus

AI use cases, data readiness, approval points and decision boundaries

• Analysts worked inside Senior Maple's project teams and under its direction, using its tools and templates.
• A shared playbook held approved templates and worked examples, so every analyst's output looked and read the same.
• Every deliverable was peer-reviewed by a second analyst before the lead BA signed it off for Senior Maple.
• The lead BA and Senior Maple's delivery lead agreed assignments every week, and analysts were briefed on each other's operators so absences did not stall a project.

For example

After-hours enquiry

• Given a family submits an enquiry outside office hours
• When the enquiry is received
• Then the family receives an acknowledgement with the next steps
• And the enquiry is assigned to the residence's sales lead for the next business day
• And it appears in that residence's follow-up list until someone contacts the family

Staff absence

• Given the assigned sales lead is away
• When an enquiry follow-up becomes due
• Then the follow-up is visible to the residence's backup contact
• And no enquiry depends on one person's inbox to be followed up

Preparation defined what the software had to do before any screen was drawn, so development teams could estimate and build against agreed requirements.

User roles

Head office roles (executives, regional managers, marketing leads, privacy officers, system administrators) and residence roles (general managers, sales leads, reception, care coordinators), with a permission matrix and data scoped to each residence

Family enquiry journey

First contact, information request, tour booking, tour, follow-up, care assessment, deposit and move-in, from the family's point of view

Staff journeys

Enquiry intake, tour scheduling, follow-up, handoff from sales to care, and move-in preparation

Data needed

Contact details, relationship to the future resident, preferred residence, timeframe, general care level of interest, enquiry source and consent

Data not to collect

Detailed medical history at the enquiry stage, health card numbers, social insurance numbers and financial details beyond what each step needs

Integrations

Website forms, phone and call tracking, email and calendars, existing CRM and sales tools, and resident and care management systems, with an agreed system of record for each data element

Non-functional requirements

Role-based access with multi-factor authentication, audit logs, privacy and retention rules, Canadian data hosting, availability, and accessibility under the Accessibility for Ontarians with Disabilities Act

Scoped backlog

Epics and user stories with acceptance criteria, prioritized with MoSCoW and split into a first release and later releases, ready for the development team to estimate

Several operators were replacing or extending their finance and operations systems while new applications were being specified. We prepared the ERP work with the same method, so the applications and the ERP were designed to work together instead of as separate projects.

Current-state finance processes

Procure-to-pay, record-to-report, resident billing from move-in to monthly invoice, and payroll inputs from staff scheduling, with person-dependent steps marked

Entity and reporting structure

How residences, regions and legal entities map to companies, cost centres and the chart of accounts, so head office can consolidate and each residence sees its results

Resident billing rules

Suite rates, care packages, one-off charges, rate changes, prorating at move-in and move-out, and who receives the invoice

Integrations

A confirmed move-in in the enquiry application creating the resident account in the ERP, plus links to payroll, scheduling, banking and resident care systems, with a system of record for each data element

Data migration readiness

Inventories of resident accounts, vendors, open balances and history, with data quality checks and decisions on what to migrate

Reporting

Occupancy, revenue per suite, arrears and cost per residence, defined once for both the ERP and the applications

Selection support

A requirements catalogue, demo scripts built from real residence scenarios, and a scoring model for comparing vendors

Implementation readiness

Prioritized requirements, fit-gap preparation and a handover pack for the chosen ERP partner

Independent residences rarely needed a full ERP. For them, the same analysis produced requirements for accounting and resident billing tools sized to the home.

Senior living handles personal information about older people and their families, often including health details. Privacy and accessibility were written as requirements from the first workshop, not added at the end.

Privacy

Requirements followed PIPEDA and applicable provincial privacy laws, with each operator's privacy officer confirming whether health information rules such as PHIPA applied. Consent was captured at first contact, with retention periods agreed for each data type.

Data minimization

Each field in the data model had a stated purpose. Anything without a purpose at that step was left out.

Access

Residence staff saw only their residence's enquiries and residents. Head office saw consolidated data across residences, with personal details limited to the roles that needed them.

AODA

Public-facing pages and forms had to meet the WCAG 2.0 Level AA standard that AODA requires for organizations with 50 or more employees, with WCAG 2.1 AA as the design target.

Designed for older users

Requirements included large readable text, clear contrast, simple forms and phone-based alternatives, since many family members and residents prefer to call.

AI was treated as part of the requirements, not as a separate experiment. Each AI capability had to fit the same process models, data rules and acceptance criteria as the rest of the application. The requirement was a controlled aid to the team, not an ungoverned chatbot.

Use case

What the AI does

What the AI can see

Where a person approves

Answering routine questions

Answers questions about visiting, amenities, suite types and services from approved content

Approved content for each residence only

Content leads approve the knowledge base before it goes live and review it on a regular schedule

Drafting a first response

Drafts a reply to a new enquiry for staff to edit

The enquiry text and approved residence content

Staff review and send every response. Nothing is sent automatically

Routing an enquiry

Suggests the right residence and staff member based on location, timeframe and type of enquiry

Enquiry details and routing rules

Staff can override any routing suggestion, and urgent enquiries go straight to a person

Summarizing a call

Drafts a call summary and next steps for the CRM record

The call transcript, where the caller has consented to recording

Staff review and correct the summary before it is saved

Before any assistant or agent was put in front of staff, we documented:

Data readiness

We checked whether each residence's content was complete, current and approved, and whether CRM fields were consistent enough for routing and reporting.

What the model can see

AI tools could access approved content and the enquiry in front of them. They could not access resident care records or financial information.

Decision boundaries

The AI must not give medical or care advice, quote final prices, confirm suite availability, make admission decisions or ask for health details.

Escalation rules

Messages suggesting urgency, such as a hospital discharge or a safety concern, go straight to a person. So do complaints and any question outside approved content, with a clear message to the family that a team member will follow up.

Transparency

Families are told when they are interacting with an AI assistant.

Testing

Each use case was tested with realistic question sets for each residence, including questions the AI should decline. Acceptance required correct answers from approved content and correct escalation for out-of-scope questions.

Monitoring

Requirements included logs of AI outputs and staff edits, reviewed regularly so content gaps and wrong answers could be fixed.

Development started from the signed-off baseline, and every delivered feature was traced back to its acceptance criteria.

Build support

We supported development of the applications each project needed, such as enquiry management, tour scheduling, follow-up tracking, move-in information intake and AI-assisted response drafting.

Traceability

A traceability matrix linked each requirement to user stories, test cases and releases, so the operator could see that every agreed outcome had been delivered and tested.

User acceptance testing

Residence staff and head office users tested real scenarios against the operational acceptance criteria before each release.

Implementation

We supported data migration from spreadsheets and older tools, cutover planning, and short role-based training for staff.

Change control

When scope moved during implementation, each change was assessed against the baseline, its impact was recorded, and the operator decided through Senior Maple.

Large multi-site operators needed a shared model with local variation. Independent residences needed a smaller scope that still fit how that home worked. Each was specified separately. Neither was treated as a template dropped on the other.

Area

Multi-site operator

Independent residence

Process model

One standard enquiry-to-move-in process, with defined points where residences can vary

One process designed around the home's actual routine

Roles

Separate head office, regional and residence roles

Fewer roles, with one person often covering several

Configuration

Residence-level settings for suite types, care levels, tour times, follow-up timing and local content

Simple settings managed by the general manager

Reporting

Consistent enquiry, tour and move-in definitions, compared across residences

A short set of measures the home actually uses

Integrations

Connections to corporate CRM, telephony and resident systems

Only the integrations the home needs, often email, calendar and website forms

ERP and finance

A shared ERP with residence-level cost centres, consolidated reporting and standard billing rules

Accounting and resident billing tools sized to the home, rather than a full ERP

AI scope

Shared governance, with approved content managed for each residence

A smaller set of AI use cases, such as drafting responses and answering routine questions