Custom software: describe the workflow before the features

Observe a real case

A request such as “we need a management system” leaves too many decisions open. Start with a specific activity: receiving an enquiry, preparing a quote, assigning a visit or closing a case. Follow one example from beginning to end and note the people involved, information required, tools used and handovers between roles. Look especially for places where someone retypes data, a decision has no owner or work stops while a confirmation is pending. These observations provide a stronger starting point than a catalogue of screens.

Separate rules from exceptions

Not every habit needs to become a feature. Ask which steps genuinely protect the service and which exist only because current tools do not communicate. Then describe the exceptions: an incomplete request, a change after approval, a cancellation or an absent owner. A workflow that handles only the ideal case may simply move the problem from a spreadsheet into a new system. Involve people doing the daily work, not only those approving the project. Their examples can expose assumptions before they become expensive design decisions.

Your scope checklist

• Identify the starting event and the outcome that closes the process.
• List roles, permissions and approval responsibilities.
• Define necessary data, where it comes from and who can correct it.
• Mark integrations, exports and tools that must remain in use.
• Write down what is excluded from the first release and how it will be handled meanwhile.

Make each priority testable

For each important feature, prepare a concrete example using non-sensitive test data. A useful criterion might be: a manager assigns a request, an operator sees only authorised tasks and a change remains traceable. Avoid vague phrases such as “quick and easy” without describing the expected behaviour. A screen prototype can help discuss terminology, steps and permissions before committing to full development. Agree who decides when a feature is accepted, how outstanding issues are recorded and which changes require a fresh scope discussion.

Prepare the transition

The project includes data import, training and support, not just code. Before migration, check duplicates, missing fields and export options in the previous system. Establish a test plan, a recovery procedure and a named contact for problems. Begin with a bounded workflow, observe where people need help and collect later requests in a separate backlog. For a discussion with CBF E-Social, bring an example case, the current steps and the desired outcome. These are more useful foundations than a long list of generic functions, and they make it easier to distinguish essential work from a future improvement.