How to plan a custom business system

1. Describe one workflow from start to finish

Start with a task your team handles today, such as recording sales, scheduling appointments, or following up on requests. Explain what starts the task, who handles each step, which information they use, and what marks the work as complete.

Identify where the process gets delayed, repeated, or difficult to check. Bring a sample form, spreadsheet layout, or a description of the screens you use. Define a concrete goal for the first version, such as keeping request statuses in one place so staff can see what still needs action.

• What triggers the work, and who owns the next step?
• Which steps belong in the first version?
• What does a completed record look like?

2. Define who can see and change each record

List the people who will use the system and the responsibilities of each role. For each type of record, specify who can create, view, edit, approve, cancel, or export it. Explain whether a person should see all records or only those belonging to their team, branch, or account.

For example, staff might submit a request, a manager might approve it, and a viewer might read its status without changing it. Treat those permissions as requirements to review during development. Mention whether you need a history showing who changed important fields or statuses.

• Who can change a record after it has been approved?
• Which information should be visible only to particular roles?
• Who manages user access when a team member joins or leaves?

3. List the records and existing data

Identify the main records the system needs: products, appointments, customers, requests, or another set that fits your process. For each record, list the fields your team uses, which are required, and how records connect to each other. A product code or request number may be needed to identify a record consistently.

Describe the format and approximate volume of existing data, plus duplicates, missing fields, and inconsistent values that need resolving. Agree which records will be migrated and who will review them. Use invented or anonymised sample records for the initial discussion; account credentials and private records can be handled separately when needed.

• Which fields are required, unique, or calculated?
• Which source should be used if two files disagree?
• Who will check the migrated records before the new system becomes the working source?

4. Explain business rules and exceptions

Describe what the system should allow, prevent, or calculate at each step. An inventory workflow might prevent a sale that exceeds available stock. A booking workflow might prevent overlapping appointments for the same staff member. An approval workflow needs to define which statuses can follow each other and who can make the change.

Walk through the exceptions as well as the normal process: a cancelled request, a correction to a completed record, a duplicate entry, or two people updating the same item. For each case, explain what should happen to related records and what the user should see. These details affect the development scope and the test cases.

• Which changes require approval or an explanation?
• What happens when a record is cancelled or corrected?
• Are there limits, thresholds, or calculation rules the team follows today?

5. Specify reports and connections

List the questions each report needs to answer. “Which requests are overdue and who owns them?” is more useful than “we need a dashboard.” Identify the fields, filters, date ranges, grouping, and exports your team uses to act on the information. Clarify how totals and statuses should be calculated.

Name any existing services the system must connect to and explain what data should move in each direction. Specify whether the connection is essential at launch, how often information should update, and what staff should do if the connection is unavailable. Provider accounts, available interfaces, and any ongoing service fees need to be considered when scoping the integration.

• Who uses each report, and what decision does it support?
• Do date ranges depend on a particular time zone or working day?
• What should happen when an import or connection fails?

6. Plan testing, launch, and handover

Choose people from the team to review working versions using realistic sample cases. Agree on checks for the normal workflow, role permissions, exceptions, calculations, and any data migration. Decide how you will move from the current process to the new one, who approves the launch, and what the team should do if an issue interrupts work.

Share your budget range and preferred launch date, then separate launch requirements from later additions. You can choose source-code handover and arrange deployment yourself, or have KLUMI LABS handle deployment and hosting setup. The quotation defines deliverables, account access, revision scope, responsibilities, and the support period. Ongoing hosting, domain, and other service costs are separate from development.

Also identify who will manage user accounts, routine updates, backups, and recovery after handover. Any maintenance or operational support you need should be discussed and included in the agreed responsibilities.

• Which sample cases will the team use to accept the system?
• Who owns deployment, backup checks, and recovery tasks?
• Which instructions, accounts, and source files are needed at handover?

Illustrative example

An example workflow brief you can adapt

This fictional request process shows how to describe the records, roles, rules, and checks for one workflow. Replace it with the steps your team follows and the changes you want to make.

Trigger and goal

A staff member submits an internal request. The team wants a shared record of its owner, status, and next action.

Information

Request number, requester, description, assigned reviewer, submitted date, status, and decision notes.

Roles

Staff submit and view their own requests. A manager reviews assigned requests. A viewer can read the records allowed for their role.

Normal flow

Draft → Submitted → Approved, Rejected, or Needs changes. An approved request then moves through the agreed completion steps.

Exception

If details need correcting, the manager marks the request as Needs changes with a reason. The staff member edits and resubmits it.

Report

Open requests grouped by owner, with a filter for submitted date and a list of requests waiting for review.

Acceptance check

Submit a sample request, review it with the correct role, return it for correction, and confirm that its status and report entry update.

Start with one workflow and identify the open questions. KLUMI LABS can help turn your notes into an agreed set of modules, business rules, deliverables, and test cases for quotation.