Use this checklist to assess whether a process is a good candidate for F2 Service Builder.
The checklist is not a final approval. It is a practical starting point for discussing the process with business units, process owners, superusers, and your digitalization team.
You can also download the checklist in a printer-friendly version.
How to use the checklist
Go through the questions below before you start building.
For each question, mark the process as:
- Clear — this has been clarified and supports using F2 Service Builder
- Needs clarification — more information is needed before you build
- Not relevant — this does not apply to the process
If several areas need clarification, start with process clarification before configuration.
1. Purpose and value
Start by defining why the process should be built.
- Is the purpose of the process clearly described?
- Is there a clear problem the process should solve?
- Will the process help standardize case handling?
- Will the process reduce manual work or coordination?
- Will the process make it easier to maintain or reuse knowledge?
- Will the process provide better overview for users, process owners, or management?
Good sign:
The process has a clear purpose and there is agreement on the value it should create.
Pause if:
The process is being built without a clear owner, purpose, or expected benefit.
2. Volume, risk, and priority
A process does not have to involve a large number of cases to be relevant. Volume matters, but so do risk, documentation needs, and organizational value.
- Does the process happen more than once?
- Are similar cases handled repeatedly?
- Is the process important or risk-sensitive?
- Does the process involve payments, grants, legal requirements, or formal decisions?
- Would standardization reduce risk or improve quality?
- Is the process important enough to prioritize even if volume is low?
Good sign:
The process is repeated often, or it is important enough that consistent handling and documentation create value.
Pause if:
The process is rare, low-risk, and does not require standardization, documentation, or better overview.
3. Process clarity
Before configuration begins, the process should be clear enough to translate into phases, tasks, roles, and decisions.
- Is there a process owner?
- Are the main phases of the process known?
- Are the main tasks described?
- Are roles and responsibilities clear?
- Are key decisions and outcomes described?
- Is it clear when the process starts and ends?
- Is the process stable enough to be configured?
Good sign:
The process can be described clearly enough that another person can understand what happens, who does what, and what should happen next.
Pause if:
The process only exists as a high-level diagram or idea and is not yet detailed enough to build from.
4. Documents and communication
Many processes depend on standard documents, templates, emails, receipts, or merge fields. These should be identified early.
- Are required document templates known?
- Are standard letters, decisions, or responses needed?
- Are merge fields required?
- Are email templates needed?
- Should users or applicants receive receipts?
- Is ownership of document and text content clear?
Good sign:
The documents and communication needed in the process are known and can be prepared before or during the build.
Pause if:
The process depends on documents or communication that have not yet been defined or approved.
5. Data and overview
Consider what information should be captured during the process and what users or managers need to follow up on.
- Is it clear what data should be registered?
- Is there a need for management overview or reporting?
- Should users be able to track progress or workload?
- Are calculations needed?
- Are there documentation, archive, or handover requirements?
- Is it clear how the data will be used after the process is running?
Good sign:
The process supports a clear need for overview, follow-up, reporting, documentation, or management information.
Pause if:
Reporting or data needs are important but not yet defined.
6. Dependencies and limitations
Some processes depend on other systems, specific configurations, integrations, or functionality that should be assessed before building.
- Does the process require input from another system?
- Does information need to be sent to another system?
- Are there integrations or dependencies that must be assessed?
- Are there manual steps that will remain outside F2 Service Builder?
- Are there known limitations that affect the process design?
- Has your digitalization team or cBrain been involved if needed?
Good sign:
Dependencies are known and can be handled within the chosen process design.
Pause if:
The process depends on functionality, integrations, or assumptions that have not been clarified.
7. Testing and maintenance
A process should be tested and maintained after it is built. Agree on responsibilities before production.
- Is it clear who will review the first version?
- Is it clear who will test the process?
- Are key test scenarios known?
- Is it clear who approves the process before use?
- Is it clear who maintains the process after launch?
- Is there a plan for updating the process when requirements change?
Good sign:
There is a clear plan for review, testing, approval, and maintenance.
Pause if:
No one has been assigned responsibility for testing, approval, or future maintenance.
Suitability summary
Use the summary below after completing the checklist.
Strong candidate
The process is likely a strong candidate for F2 Service Builder if:
- The purpose and value are clear
- The process is repeated or important enough to standardize
- Phases, tasks, roles, and decisions are understood
- Documents, communication, and data needs are known
- Dependencies have been assessed
- Testing and maintenance responsibilities are clear
Recommended next step:
Use the before-you-start checklist and prepare the process for configuration.
Open before-you-start checklist
Needs clarification
The process may still be a good candidate, but more clarification is needed if:
- The process is only described at a high level
- Roles or responsibilities are unclear
- Documents, data, or reporting needs are not defined
- Integration needs or limitations have not been assessed
- Testing and maintenance are not planned
Recommended next step:
Clarify the process with the business unit and digitalization team before building.
Lower priority or not ready
The process may be lower priority or not ready if:
- The value is unclear
- The process is rarely repeated and low-risk
- The process changes significantly from case to case
- No process owner has been assigned
- Required dependencies or limitations cannot be clarified
- There is no plan for review, testing, or maintenance
Recommended next step:
Revisit the process scope or consider whether another approach is more appropriate.
Next step
If the process appears suitable, continue by preparing the information needed to build the first version.
Open before-you-start checklist
For detailed configuration guidance, use the F2 Service Builder manual in F2 Docs.
