Follow a field-service job from the operator's experience to its implementation. See what Keel supplies, what your process requires and what to agree before handover.
Keel is an operations platform you can shape around the work your team needs to do. The result should be useful working software: people can find their next job, see the information they need, carry out its steps and understand where the work goes next.
For a technical leader or product manager evaluating Keel, the practical question is how that experience gets built. Keel supplies the platform facilities for running it, including configurable operator tools and workflows. The implementation defines your process, expresses its rules and connects it to the rest of the business. Keel leads that implementation and agrees the handover with your team.
From a site visit to the next piece of work
Imagine a technician opening an assigned visit. They see the equipment details, the work requested and the observations they need to record. At the end of the visit, they request further work and attach their findings. The scheduling team receives the follow-up with the site and equipment references already included. This is an illustrative implementation, not a claim that a particular field-service module arrives preconfigured.
The technician needs one coherent experience. They should not have to finish the visit, retype its details into a separate request and send a message to make that request visible. The implementation can make recording the outcome create the agreed follow-up work, carrying the relevant findings with it.
A technical evaluator should be able to trace that behaviour. Where is the visit outcome recorded? Which rule creates the follow-up? Which view shows it to the scheduling team? That trace reveals both what the platform provides and what someone must design for this operation.
The platform and the application each do part of the work
Keel defines records and their actions in a schema. An action describes something the application can do, such as list assigned visits or retrieve equipment details. Keel implements supported built-in actions from their definitions. More specialised behaviour can use custom functions written in code.
For actions supported in Console, Keel generates operator tools such as lists and forms. The implementation can configure labels, visible fields and layouts, and link related views. The team chooses which information and actions belong in the technician’s view. A particular mobile layout or bespoke interaction may need further development.
Part of the experience | Keel supplies | The implementation decides or builds |
|---|---|---|
Find and open a visit | Data modelling, built-in actions and supported generated tools | The visit records, relationships, filters and information needed for the job |
Record an outcome | Action and custom-function facilities | The allowed outcomes and the rule that creates the appropriate follow-up work |
Guide a person through the visit record | Flows with UI and processing steps | The sequence, questions, instructions and recovery behaviour |
Give each role appropriate access | A permission system for models and actions | Who may record observations, amend an outcome or arrange the follow-up |
Connect the result to another system | Callable APIs and custom-function support for external services | Field mappings, authentication configuration, acceptance checks and duplicate handling |
Verify the application | Generated testing facilities | Meaningful test cases, expected results and the release process |
Access rules are explicit: Keel’s permissions model denies actions unless permission is defined. That foundation still needs the right policy for your team. An overly broad rule will not become appropriate merely because the platform enforces it consistently.
Changing a rule changes the work people receive
Suppose the business introduces a separate parts-preparation step for follow-up visits that require replacement components. The technician records which part is needed. The team wants the scheduling view to distinguish visits ready to arrange from those waiting for a part, so it can organise the work accordingly.
Adding a “parts required” outcome to a record gives the application somewhere to store that choice. The implementation must also define what choosing it does: create the parts request, retain the technician’s findings and record why the next visit is waiting. Once the required part is available, the follow-up can appear as work ready for the scheduling team. The site visit remains traceable through that sequence.
The implementation uses custom functions to express business behaviour and flows to connect human steps with processing. In this example, submitting the visit record can run the follow-up rule and tell the technician what happens next. The rule and the working experience change together, so a new operational option becomes work the team can actually carry out.
The technical design should also identify which callers use that action. A Console tool and a connected application can call the same implemented action through the supported API. If another route updates the visit directly, it needs its own assessment; reusing an action does not prove that every possible write path applies the same business rule.
Existing work matters too. The team must decide how follow-ups already being arranged enter the new parts-preparation process and preserve a record of what happened. Tests should cover a new parts request, revised findings and a repeated submission that must not create unintended duplicate jobs. Keel’s testing facilities provide ways to exercise actions and flows; someone still has to define and check those outcomes.
Where AI fits in the scope
AI can be involved in two different parts of a project: helping create or change the system, and performing a step inside the operational work. Keep those responsibilities distinct when agreeing scope.
For development assistance, generated code still needs review and tests against the business’s requirements. For an AI step within the visit, such as extracting an equipment identifier from a photo, the implementation must define the model call, how to validate its output and what the technician reviews before the process continues. That is an illustrative extension, not a supplied image-reading feature or a claim of model accuracy.
Keel also documents MCP access, through which configured AI clients can discover and call the actions exposed by an API. The API scope and access policy are part of the setup. Agree the particular AI capabilities and availability for your project; access to actions does not establish that an autonomous agent has been designed and tested to run the whole process.
What to agree before handover
For a team comparing Keel with building an application from scratch, these facilities define work the platform can supply. The custom route through a visit, the interfaces people need and the integration behaviour remain application responsibilities. Other development approaches can also use mature frameworks and managed services, so compare the actual delivery scope and maintenance responsibilities.
Before handover, agree who changes process definitions and code, who maintains integrations, and who reviews and releases those changes. Include how the team investigates failed work and how operators get help. A successful first implementation does not decide those responsibilities for future changes.
Take one process through the evaluation in that level of detail. Ask to see the working experience, then trace one rule into its implementation. Introduce a change and identify which definitions, screens and tests need updating, along with who will do the work. Review a workflow and its implementation scope with Keel to make that boundary concrete for your team.
