From first-time fix rate to contract attach rate

One of the reasons I stay enthusiastic about Dynamics 365 Field Service is the range of operations the product actually covers. Service, sales, scheduling, maintenance, agreements. It is all in there, in one data model, with the handovers between them as fields on records that already exist rather than as integration projects in their own right.

I have worked with the product since 2019, from its early days. In that time the pattern I see most often is not a technical one. It is a sequencing one.

Most organizations implement D365 Field Service to lift the first-time fix rate, or to push technician utilization and billable hours as high as they will go. That is the business case that gets signed off, and it is the right place to start. Shorter response times, fewer wasted trips, technicians who arrive with the right parts and the right procedure.

A second set of numbers tends to come later in the sequence. Contract attach rate. Recurring service revenue. Visibility of the installed base.

That sequencing is what this article is about, because the reactive flow makes your service faster while the agreement flow makes it profitable. Both are worth having. The second one just rarely gets the first turn, and there is usually more margin sitting in it than the roadmap assumes.

The Agreement, and why it is one record

Consider what it is worth to generate an agreement automatically for every product sold and every asset installed, with the invoicing and the maintenance arranged from that moment on.

In Field Service that is one record. It is called an Agreement.

The Agreement sits between the customer, the service location and the installed asset, and it does two things on separate schedules. It creates the maintenance work orders, and it creates the invoices.

On the work order side you define the recurrence pattern, the incident type each generated work order should use, how far in advance the records are created, the service tasks and products that belong on the job, and if you want, a preferred resource and a preferred time window. Set it once, and the maintenance visits appear on their own for as long as the contract runs.

On the invoice side you define what is billed and on what recurrence, entirely independently of the work order schedule.

Those schedules are deliberately independent, because in practice they never line up. You service a location twice a year and you invoice monthly. You install under a contract that bills annually in advance and services on demand. Without the Agreement, that gap gets bridged by a spreadsheet and a person who remembers. The Agreement holds both, so nobody is reconciling a maintenance calendar against a billing calendar by hand.

Operationally: the maintenance job appears by itself, gets scheduled, the technician goes out, the work is completed, and nothing is invoiced on completion. The revenue is already contracted.

Financially: every asset you sell becomes a recurring revenue line and a planned block of capacity, instead of an unpredictable call to an overloaded scheduler.

Where the asset comes from in the first place

An Agreement needs an asset to attach to. That is why the second flow matters, and why it repays being planned earlier than it usually is.

A product is sold and added to a sales order. That product has to be installed, which means someone has to schedule an engineer, bring the right parts, and follow the right procedure.

Here is the configuration that makes this work, and I should be precise: this part is not out of the box. You add a relationship from the product record to an incident type. The product then carries the knowledge of how it gets installed. When that product appears on a sales order line, an automated flow reads the incident type from the product and creates a work order using it.

The incident type is the most useful template in the product and it repays more attention than it usually gets. It is a reusable definition of a kind of job. It holds the service tasks that need to be performed and the order they belong in. It holds the products and services the job consumes. It holds the required characteristics and skills, which is what lets the scheduling engine pick someone qualified rather than someone merely available. And it holds an estimated duration, which is what makes the schedule realistic instead of optimistic.

Attach the incident type to a work order and the work order is fully specified before a scheduler has looked at it. Attach the incident type to the product, and selling that product specifies the installation job automatically.

From there it is familiar. Resource requirement, booking, execution. On the commercial side you choose: bill from the sales order, or bill from the actuals recorded on the work order. Different organizations need different answers and the product supports both.

And then the part that is easy to miss. When the installation completes, the product is registered as a customer asset at that service location. Your installed base is not a separate project with its own data migration and its own budget line. It is a by-product of delivering work you were already delivering.

Without that, there is nothing for an Agreement to attach to. Where the installed base has not been registered, contracted service has nothing to hang on, which is why the two are worth planning together rather than as separate phases a year apart.

The reactive flow, which usually comes first

For completeness, the flow that most implementations start with.

A customer has a problem, reaches an agent, and the agent creates a case. That case becomes a work order, and the moment it does, the work order carries what the field needs. The service account, the billing account, the service location, the asset, and the price list that governs what this work costs. Nobody retypes any of it.

The work order then needs a technician. The schedule board lets a scheduler make the call by hand, seeing availability, skills and travel time in one view. Resource Scheduling Optimization does it automatically against the constraints you set, and rebuilds the day when reality interferes. Either route produces the same thing: a resource requirement becomes a booking, and the booking appears on a technician's mobile device. I wrote separately about how the Scheduling Operations Agent changes that picture.

The work is carried out. Time and material are recorded against the work order as actuals, and those actuals are what you invoice. Not an estimate, not a re-entry. With Dual Write configured, the resulting transaction flows into Finance and Supply Chain Management, where the invoice is issued and the receivable is tracked. That handover is a piece of integration design in its own right.

Phone call to paid invoice, inside one application, with a single handover at the point where a finance system should take over.

Why the three belong together

Look at what these flows share. One data model. One scheduling engine. One asset record. One route into finance.

The case that came in over the phone, the product that went out on a sales order, and the contract that governs the next years of maintenance all resolve to the same customer asset at the same service location. A scheduler, a service manager, a controller and a sales rep are looking at different views of records that are genuinely the same records.

That is unusual. In most landscapes each of those three flows is a separate system with a separate owner and an interface in between, and the interfaces are where the project time goes.

It is also why the order matters. Reactive service first, because it is the business case that gets funded. The installed base second, because contracted service has nothing to attach to without it. Agreements third, because that is where the recurring revenue is.

Where the sequence stops after the first flow, picking the rest up later is usually a question of scope and configuration rather than a rebuild.

Three questions worth putting to your team

• What share of our installed base is under contract, and what is the reason the rest is not?
• How much of the work we carried out last year was never invoiced, and do we know that or are we guessing?
• If a customer calls tomorrow with a breakdown, can the scheduler see within thirty seconds whether it is covered by a contract, or does someone have to go and find out?

If two of those answers are uncomfortable, that is worth an hour of conversation.

Working with me

I have specialized in D365 Field Service since 2019 and I am PL-600 certified. I take on the full track as principal contractor: the functional work myself, development and integration through a fixed subcontractor.

I currently deliver Field Service and Universal Resource Scheduling for a US-based healthcare technical services company, working across time zones, so North American programs are familiar ground rather than an experiment. I work remotely across the EU, hybrid in the Netherlands, with working hours flexible into US time zones. Rates on request.