The job sheet and diary system that runs your engineers

A diary on one screen, a printer beside it, and a pile of job sheets waiting to be keyed in.

A typical business running one of these has 8 to 25 engineers in vans, one office with three or four people in it, and somewhere between 40 and 150 jobs a day across a few thousand customer sites, some on contract and most on call-out. Plenty of firms this size run a bought job management package, some beside a homegrown system or the other way round. This page is about the homegrown diary, or a package customised past the point of upgrade. Whichever generation built it, the office leans on it for the same day's work.

In the office's words, it takes the call, finds the site and its equipment, raises the job with a priority and a promised date, and drops it into an engineer's slot. It prints the job sheet: site, access notes, the fault, the parts to take. The engineer fills it in by hand, gets it signed, and it comes back in the van on Friday. Someone keys in the times and the parts, the job is costed, and the invoice is raised. On Monday the service manager runs the outstanding-sheets report and goes looking for the missing ones.

It has lasted because of what it knows:

• The callout rate depends on the customer, the time band (before 8, after 5, weekends and bank holidays) and whether the site is inside the M25.
• Travel is charged from the previous job for most customers, and from the depot for two account customers whose contracts predate the rule.
• Parts are marked up on a sliding scale by cost band, except parts fitted under a maintenance contract, which go at cost plus a fixed fitting charge.
• A job cannot be invoiced until the sheet is back and marked signed, unless the customer is on the list for whom a PO number is enough.
• Some engineers cannot go to some sites: a customer's vetting, a Gas Safe category, or a site manager who asked for someone else in 2019.

None of that is in a manual. It is in the code, and in the scheduler's head.

Written between 2004 and 2014, usually by a contractor or a small local firm. It often began as a Microsoft Access database an office manager put together, and grew into a .NET Framework Windows program over SQL Server when Access could not cope with the number of people in it. The Sage export arrived when the accounts moved off a separate ledger, and the Access front end never quite left: the parts list and a couple of reports still open in it. It runs on a Windows server in the office, and the grid opens on the scheduler's PC and nowhere else.

The contractor who wrote it now answers one email in three, and the firm that keeps the office PCs patched will not open the code. So every new rate since has been squeezed into the old time bands rather than added, and the job sheet still comes back in the van on Friday.

The same diary built between 2016 and 2022, by a small agency or a freelancer, as a web system in React, Angular or Node or .NET Core with an engineers' app in React Native, or put together in Power Apps or Bubble by an office manager with a knack for it. The diary opens in a browser, the engineers see their jobs on a phone, and a facilities manager or two has a login to check on their sites.

What pins it down is the rate card. The agency wrote the time bands and the travel rules into the code, so each new account customer meant a quote from them, and the last one went live charging travel twice on every weekend job. The office reversed it by hand and the rates have been frozen since, while the agency was bought and stopped taking small work. From 2023 some owners had a second go in an AI app builder, and those diaries tend to stall at the Sage link, the one piece that has to agree with the accounts to the penny. A decade younger than the Access diary, and stuck in the same place.

One person runs the diary for twenty vans, and every job that gets done gets billed.

The grid is what lets a small office keep that many engineers busy. Every engineer's day and every open job are on one screen, and moving a job from Tuesday to Wednesday, or from one van to another, is a drag. The sheet the engineer picks up at seven in the morning came off the same grid, so the day the scheduler planned is the day the vans run.

The other half is the invoice. Because the sheet closes the job and the job raises the invoice, nothing that was done goes unbilled, and it goes out at the right rate. The Monday report is why the engineers hand their paperwork in. The Sage batch is why month end takes half a day.

And when a customer rings about a site, the history is on screen before they have finished the sentence: what was fitted, when, by whom, and what was said last time.

Systems like this do not break. They fall behind the vans.

The job sheet is still paper. Between the engineer finishing and the office raising the invoice there is a gap of two days to a week while the sheet finds its way back and someone types it in. Sheets get lost, parts get missed off, and the handwriting on a Friday afternoon is a guess. On the older systems the paper never went away; on the newer ones it came back, for every engineer whose phone the app will not install on.

The diary lives on one screen. The grid was built for the scheduler's PC and opens nowhere else. The service manager rings in from a site to ask where an engineer is, the on-call person takes the weekend from a printout, and when the scheduler is off the diary is run by whoever can be spared.

The server has a date on it. The database usually sits on SQL Server 2016, on a Windows Server 2016 box in the office. SQL Server 2016 updates ended in July 2026 and Windows Server 2016 ends in January 2027. Moving it needs the contractor back, and nobody has managed to pin them down.

The customers ask for things it cannot send. A facilities manager wants a confirmation when the job is booked, a text when the engineer is on the way, and a report with photos the same afternoon. The office does what it can by hand from the shared inbox, which works for the customers who shout loudest and not for the rest.

The same diary, with the engineers, the customers and the accounts connected to it.

The job sheet on the engineer's phone. The engineer sees the job, records the times, picks parts from a list, takes photos, gets a signature, and the sheet is in the office before the van has left the car park. The invoice can go that afternoon. The phone writes into the same database the diary reads.

The diary in a browser. The same grid opened in a browser, on the same data, so the service manager sees it on a tablet, the on-call person sees the weekend on a phone, and a second scheduler can run a region without a second PC in the office.

The rate card on a screen the office owns. The time bands, the travel rules and the parts markup come out of the code into tables the office can see and change. A new account customer with its own rates becomes a Tuesday-afternoon job instead of a developer change.

Confirmations and on-the-way texts. A confirmation when the job is created, a text when the engineer taps travelling, and the signed sheet with photos emailed as a PDF when the job closes. Nobody in the office types any of it.

A daily Sage run that has been tested. With the sheet arriving electronically the weekly batch can become a daily one. The export is tested against the Sage version in use before anything else moves, because month end is the thing that must not break.

The old program is not switched off for any of this, whichever generation it is. It gets added to.

In the words around each job: requests in, reports out, and the questions nobody built a report for.

AI reads, drafts and searches well here, and is no help deciding who goes where. Three places:

Job requests read from the inbox. Work arrives as emails, portal notifications and purchase orders as PDFs, and someone retypes each one. AI reads the request, matches the site and its equipment, and drafts the job with the fault, the priority and the PO number filled in, for the scheduler to check and drop into a slot. At 40 to 150 jobs a day, most arriving in writing and each a few minutes of keying, that typically gives the office one to three hours back every day.

The engineer's notes turned into the customer's report. What comes back from site is typed shorthand or a voice note from the van: fan motor replaced, drain blocked, quote needed. AI turns it into a clean report with the times and parts from the job record, and the engineer approves it on the phone before it sends. For the dozen or so reports a day the fussier customers expect, the admin who tidied them typically gets most of a day a week back.

Questions put to the job history. Which contract sites have had the same unit out three times since spring? Which follow-up quotes were never booked? Today each is an export and a morning with a spreadsheet. AI answers in plain words and lists the jobs behind the answer, so the service manager checks a list instead of building one.

Not worth doing: letting AI allocate the day's jobs. The scheduler knows which engineer the site manager will let in, who is on a course on Thursday, and who should not get two jobs in Southend on the same day.

A diary where one rate change can break the invoice run cannot take anything new, so AI waits for the first stage to make changes safe. The assessment shows which of these would pay back soonest on the system as it stands.

Stabilise, then the phone, then everything else one stage at a time, with the old program as the fallback throughout.

1. Stabilise. Source code found and building, or recovered from the agency's hosting account, the database on a version that is still supported with a backup that has been restored, and a test copy so changes can be tried away from the live diary. It goes first because everything after it depends on it, and it takes the January 2027 date off the table.
2. The job sheet on the phone. Writing into the existing database. The office sees no change except sheets arriving during the day instead of on Friday.
3. Confirmations, texts and the PDF report. From the same job record, triggered by what the engineer taps.
4. The diary in a browser. Run alongside the old grid until the scheduler stops opening it.
5. The rate card as data, and the daily Sage run. Each a stage, each priced on its own.
6. Retire the old program when nothing depends on it. The last thing to go is usually the parts list in Access.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a job system that means a few days with the scheduler and the code, finding the rules and the risks, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work, what drives the price and the payment terms each have a page, and so does each technology the system is built on: Microsoft Access, .NET Framework, SQL Server and Sage integrations, and for the newer generation React, Angular and Node, .NET Core and the engineers' app in React Native.