Start with what you already have
You do not need a software specification.
A recent job, a scheduling spreadsheet and an example customer report can explain more than a long feature list. Show us where the information starts, who changes it and what someone has to check before the next step. Include the cases that do not follow the usual route.
Bring an operations decision-maker and people who know dispatch, field work and administration. They do not all need to attend every session. Existing documents and written answers can replace meeting time where they already explain the process clearly.
- A representative job from enquiry to invoice
- The systems and spreadsheets involved
- An example of a delay, exception or repeated manual task
- The first improvement that would make the project worthwhile
A practical conversation
Five areas to work through together.
We combine or extend sessions according to the business. The output matters more than the meeting count: a shared understanding of what to build and how to tell whether it works.
Business and responsibilities
Map your service types, customers, locations, departments and roles. Identify the operational problems worth solving first and who can make decisions about them.
The path of a job
Follow intake, quoting, assignment, site work and completion. Record cancellations, unavailable workers, additional work and repeat visits alongside the normal flow.
Money and connected systems
Trace invoices, payments, stock and accounting handoffs. Name the source of truth for each record and decide how missing or inconsistent data should be handled.
Rules and constraints
Discuss permissions, qualifications, approvals, reporting, connectivity and operating hours. Turn important requirements into observable acceptance criteria.
Review the proposed solution
Walk through the prototype with representative users. Adjust it, separate the first release from later work and agree the implementation and rollout scope.
Make the decisions visible
Review a prototype before building the solution.
The prototype makes the proposed workflow concrete: what the dispatcher sees, what the field worker records and what the customer receives. It is the place to question a missing step or simplify an approval. It is not yet the production system.
At this stage we agree the first release, assumptions, exclusions and acceptance criteria. The proposal also identifies dependencies such as access to another system, usable historical data and the availability of your team for reviews. The prototype stage and its commercial terms are defined in the proposal.
A managed implementation
Build against the agreed workflow.
Develop and review
Our team uses the Fieldera foundation and field-service patterns to implement the project. Reviews check the actual workflow, including its exceptions, against the agreed requirements.
Test with your users
Your representatives work through acceptance scenarios. A completed job, a rejected approval and a failed data handoff may all need different tests.
Prepare the transition
Agree what data to move, how to check it, who needs training and how the team will operate during the change. A rollout can be phased where the project allows.
After launch
Keep the system in experienced hands.
We continue with monthly maintenance after implementation. Before the build, we document the operating responsibilities, support channel, coverage hours and defect handling in your proposal. We also agree who handles hosting, backups, monitoring and security maintenance, so your team knows where to turn.
We scope new workflows and substantial integrations separately, explaining the cost and impact on existing operations before scheduling the change. We agree data access, code rights and handover arrangements with you in writing before the build begins.
FAQ
Questions worth asking
How much time does our team need to contribute?
Plan for the working sessions, prototype feedback and user acceptance. We identify the right participants and review points with you. Timing depends on the scope and how well the current processes are documented.
What if we discover a new requirement during the build?
We assess its effect on the agreed scope, schedule and budget. You can prioritise it against existing work or plan it for a later release. It should not become an unpriced assumption.
Can you work from documents instead of meetings?
Yes. Written workflows, sample records and existing documentation are useful inputs. Sessions focus on unanswered questions, conflicting practices and decisions that need more than one department.
Do we need an in-house development team?
No. You need people who can explain the operation, review the workflow and accept the result. The Fieldera delivery team handles implementation and the agreed maintenance work.