Case study ·
Service Management Software, UK
Service Geeni: Business Analysis for Asset-Centric Service Management Software
Software
UK
Service management
BRDs and specifications
Business Analysis
How Business Analysis Canada supported Service Geeni's product projects under NDA, from stakeholder elicitation and BRDs to specification and delivery.
- 9 areas checked in every impact assessment, from assets to reporting
- 1 approved BRD per project before specification started
- 10 types of requirements artifact, from request briefs to decision logs
- 100% of requirements confirmed as covered by testing before release
Project at a glance
- Client
Service Geeni, a UK software company. Its asset-centric service management platform is used by businesses that service, maintain and hire out complex equipment, from forklifts and lifting equipment to aviation ground support and medical devices. - Engagement
Business analysis support across several product projects, under NDA - Delivery
Remote from Canada, with working hours overlapping UK business hours - Model
BA support assigned to each project and carried from the first request through specification and delivery - Our role
The analytical layer: stakeholder elicitation, business requirements documents, specifications and ongoing project support. - Confidentiality
Project names, scope and commercial terms stay confidential under NDA. This case study describes how we worked, not what was built.
The challenge
What problem was the client trying to solve?
What did Service Geeni need?
Service Geeni's platform serves many specialist industries, and every new request touches a product that thousands of businesses rely on every day. The product team needed analysis capacity that could turn requests into clear requirements without slowing the roadmap.
- Requests from every direction
Requests came from customers, sales, support and the product team, in very different forms and levels of detail. - Every industry speaks its own language
Each industry served brings its own vocabulary, rules and compliance needs, so the same feature can mean different things to different customers. - Several projects in parallel
Several projects ran in parallel, and each needed someone to own the requirements from the first request to release. - One change ripples across modules
In an asset-centric platform, one change can ripple across jobs, service history, maintenance schedules, stock, hire, billing and customer portals. Requirements had to show those knock-on effects before development started. - Capacity that fits the team's standards
The team wanted outside BA capacity that worked to its standards, while product decisions stayed in-house.
Domain questions
Why does asset-centric service management need strong requirements?
In an asset-centric platform, the asset record sits at the centre of almost every workflow. That makes requirements work more about dependencies than about individual screens. These are the kinds of questions our analysts worked through. The specific projects, and the answers, remain confidential.
Assets and service history
- How are assets identified, grouped and tracked across owners, sites and hire periods?
- What history must stay attached when an asset moves?
Jobs and engineer scheduling
- How are reactive, planned and inspection jobs created, prioritized and assigned?
- What happens when a job cannot be completed on the first visit?
Planned preventive maintenance
- Are schedules driven by time, usage or condition?
- How are missed and overdue visits handled?
Mobile engineer app
- What must work offline?
- What evidence, such as photos, signatures and checklists, must be captured before a job can close?
Stock and parts
- How are parts reserved, used on jobs, returned and replenished?
- How is van stock handled differently from warehouse stock?
Hire and rental
- How are on-hire, off-hire, inspections and damage handled, and how does hire interact with servicing?
Customer communication
- What do customers see in portals, e-signatures and SMS notifications, and when?
Integrations
- Which system owns customers, prices, invoices and stock when the platform connects to accounting, ERP or CRM systems?
Reporting
- Which measures matter to service managers, and how is each one defined?
Our business analysis approach
How did we approach the engagement?
Every project followed the same path from request to release, so product owners always knew where a piece of work stood and what was needed from them.
- Intake and triage
Each new request was logged with its source, problem statement, affected users and urgency. We clarified the underlying need before anyone discussed solutions, because customer requests often describe a workaround rather than the real problem. - Stakeholder elicitation
We ran interviews and workshops with Service Geeni's product owners, customer success and support staff, and implementation consultants. Where it helped, we also spoke with selected customer users, such as service managers, planners and field engineers, arranged through Service Geeni. - Current-state analysis
We mapped how the relevant process works today, in the product and at customer sites, using BPMN. The maps showed pain points, workarounds and rules that had never been written down. - Business requirements documents
Each project had a BRD covering business objectives, scope and exclusions, stakeholders, business rules, assumptions, constraints, dependencies and success criteria. Product leadership approved each BRD before specification started. - Impact analysis
Every BRD included an impact assessment across assets, jobs, maintenance schedules, mobile, stock, hire, customer communication, integrations and reporting. It also covered effects on existing customers, so changes could be released as configurable options without disrupting how current customers work. - Specification
Approved BRDs were turned into functional specifications and user stories with acceptance criteria. Specs covered data definitions, status models, permission rules, notification rules, integration behaviour and non-functional requirements. - Delivery support
We took part in backlog refinement and sprint planning with Service Geeni's developers, answered questions on business rules, updated specs as edge cases came up, and kept a decision log. - Testing and acceptance
We wrote test scenarios from the acceptance criteria, supported QA and user acceptance testing, and confirmed that every requirement was covered before release. - Release and handover
We provided input for release notes and product documentation, and handed the full requirements set to the product owner for future reference.
Deliverables
What did we deliver?
Artifact
What it covered
Who used it
Request briefs
Problem statement, source, affected users and urgency
Product owners deciding what to take forward
Interview and workshop notes
Needs, rules and pain points by user group
Product owners and designers
Current-state process maps
How the work happens today, including workarounds
Product and development teams
Business requirements documents
Objectives, scope, business rules, constraints and success criteria
Product leadership, for approval
Impact assessments
Effects across modules, integrations and existing customers
Product, development and customer success teams
Functional specifications
Screens, fields, statuses, permissions, notifications and integration behaviour
Developers and QA
User stories with acceptance criteria
Implementation-ready backlog items
Development team
Test scenarios
Coverage of acceptance criteria and edge cases
QA and user acceptance testing
Requirements traceability matrix
Links from each request to its BRD, spec, stories, tests and release
Product owners and QA
Decision log
What was decided, by whom and why
The whole project team
Discuss a similar project
Governance
How did we work within Service Geeni's NDA?
An outside analyst on a product team has to strengthen product decisions without taking them over. We agreed these rules at the start.
- All work was covered by NDA. Project names, scope, customer information and commercial terms stay confidential, including in this case study.
- Analysts worked in Service Geeni's tools and repositories, following its templates and conventions.
- No product or customer data was kept on Business Analysis Canada systems, and any customer information seen during analysis was handled under Service Geeni's data protection and information security policies.
- Contact with Service Geeni's customers went through Service Geeni and its account owners.
Which BA techniques and tools did we use?
Techniques
- Stakeholder analysis
- Interviews and workshops
- BPMN process modelling
- Current and future state analysis
- BRD authoring
- Impact analysis
- Business rules analysis
- State modelling
- Functional specification
- User stories with acceptance criteria
- Data definition
- Test scenario design
- Requirements traceability
- Decision logging
Tools
- Jira
- Confluence
- Microsoft Visio
- Miro
- Figma
- Microsoft Office
Results
What were the results?
- 9 areas checked in every impact assessment, from assets to reporting
- 1 approved BRD per project before specification started
- 10 types of requirements artifact, from request briefs to decision logs
- 100% of requirements confirmed as covered by testing before release
Cross-module impacts found during analysis instead of during testing or after release.
- Requests turned into clear, approved requirements before development started.
- Developers working from testable specifications and acceptance criteria, with fewer rounds of clarification during sprints.
- A consistent BRD and specification format across projects.
- Product team time freed for product strategy and customer relationships.
- A traceable requirements history Service Geeni can use for future changes.
Get a free assessment
“
Lessons learned
What can other software product teams learn from this engagement?
- Start every request with the problem, not the solution. Customer requests often describe a workaround.
- In an asset-centric product, analyze dependencies first. A small change to the asset record can affect jobs, hire, stock, billing and reporting.
- Protect existing customers. Changes to a shared platform need configuration options and backward compatibility.
- Keep the BRD and the specification separate. The BRD agrees why and what. The specification tells developers how the product should behave.
Does your product team need more analysis capacity?
Talk to a senior business analyst about BA support that turns requests into clear, approved requirements.
Book your free consultation
Industry & Location
Service Management Software, UK
Service Geeni: Business Analysis for Asset-Centric Service Management Software
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Oops! Something went wrong while submitting the form.