Custom solutions
Clear follow-up, even when work changes hands.
Nordis builds tools around your team to bring information together, assign follow-up and make the next action clear.
Describe my workflowExplore the needsFictional example · request follow-up
A visit to arrange. A follow-up to keep track of.
- Today
- A visit request arrives by email. The date is in a conversation, the instructions in a note. It is unclear who should confirm.
- With a custom tool
- Nordis can bring the request, instructions and follow-up into one record. One person is responsible for confirming the date.
- What changes for the team
- The person picking up the request knows what to do and finds the context in the same place.
View the exampleBack to the summary
Visit request
- To prepare
- Site visit · Tuesday morning proposed
- Follow-up owner
- Coordination
- Next action
- Confirm availability with the person who requested the visit.
The visit still needs confirmation. This example shows one possible workflow, not a completed action.
Customer relationships and CRM
Keep the context of a relationship and make the next follow-up someone’s responsibility.
A contact is in one file, conversations are elsewhere, and someone has to remember the next reminder. Before choosing screens, we work out what your team needs to pick up a record without starting over.
What the scope can cover
- A record structure and fields that use your team’s vocabulary.
- The follow-up stages, responsibilities and views selected during scoping.
- Access rules and, if included in the project, an import of prepared data.
What needs clear boundaries
- Bringing over history depends on the quality of the files and the export options in your current tools.
- Email synchronization, campaigns and automated messages need their own scope and authorizations.
Operations and internal tools
Give people the information they need to move the work forward.
A record changes hands, but the instructions stay in a conversation. People have to ask where things stand and which version to use. We examine the handoffs before turning the process into a tool.
What the scope can cover
- The selected workflow, including the approvals and exceptions it needs to handle.
- The forms, task views and statuses specified for the project.
- Defined roles and instructions for the delivered workflows.
What needs clear boundaries
- The tool does not replace management decisions or the responsibilities of the people approving the work.
- Historical records, documents and offline use need separate consideration if they are part of the requirement.
Workflow automation
Let the system handle a repeated action once its rule and exceptions are clear enough.
Someone copies the same information or creates the same task whenever a status changes. We first check what triggers the action, what it can change and what needs to remain under human control.
What the scope can cover
- The triggers, conditions and actions described in the scope.
- Duplicate checks and validations needed for the selected workflow.
- The agreed test cases and error handling for the rules being built.
What needs clear boundaries
- Automation follows the data it receives; incorrect information can lead to an incorrect action.
- External messages, payments and other sensitive actions are not assumed to be authorized. Outside services may impose their own limits.
Overview and reporting
See which records need a decision, with information you can trace to its source.
Preparing an update means comparing several lists and asking what each status means. We start with the decisions to make, then define the useful data and calculation rules.
What the scope can cover
- Definitions of the selected indicators or statuses and their sources.
- The lists, filters or dashboards included in the project.
- Agreed checks and export options, subject to the data available.
What needs clear boundaries
- An overview does not fix missing or contradictory data on its own.
- Update frequency depends on the selected sources and connections. Live updates and forecasts are not assumed to be included.
Connections between systems
Move useful information between the tools that need to keep working together.
Two tools hold part of the same record, and someone has to keep both updated. We check what each tool can read or change, then choose which source takes precedence for each piece of information.
What the scope can cover
- A description of the data to exchange and each tool’s responsibilities.
- The selected connection or import-export mechanism, if its feasibility is confirmed.
- The tests and recovery instructions included for that exchange.
What needs clear boundaries
- A connection depends on the access rights, terms and capabilities of the provider involved.
- A subscription, usage fees or a change at that provider can affect the project. Universal compatibility is not promised.
Project handover
You own the entire custom project.
Construction and setup are a defined, paid initial project. You receive the source code, project-specific configurations, documentation and deployment instructions.
You can change teams or hosting providers without mandatory dependency on Nordis. Hosting, support and future changes still need to be planned; outside services retain their terms and fees.
Rights, outside services and costs
You receive the source code specific to the project, custom configurations, documentation and deployment instructions. You control your data and access. Access is handed over through the project’s authenticated mechanisms, never through the public brief.
You can take over the project, host it elsewhere and have another team develop it further. There is no mandatory dependency on Nordis or hidden Nordis usage royalty. Your custom project is not published without your agreement.
Construction and setup are a defined, paid project. After delivery, you don’t pay a Nordis subscription to use your instrument. Hosting remains a cost. Support and changes are separate work, with stated terms and costs.
Open source dependencies retain their licences; outside services retain their terms and fees. We identify them before the project. These licences do not hold back your specific code: they avoid pretending to transfer ownership of a public framework or an outside account without respecting its terms.
Examine subscriptions before replacing them.
We review what is used, what overlaps and what needs to stay. A custom project also needs to be assessed against its build, hosting and maintenance costs.
How to compare costs
Possible gross savings are the subscriptions actually removed over a time horizon chosen with you. To assess net savings and the break-even point, we also count the paid initial build and migration, then hosting, retained services, maintenance and relevant changes over that same horizon.
No project price, hosting cost or payback period is assumed here. A custom tool cannot replace all software and is not cost-effective in every situation. Scoping also helps recognize when keeping an existing tool is the better choice.