--- title: "Scheduling and booking software" description: "Systems that organise bookings, staff availability and customer updates in one place, so scheduling stops living in a shared inbox. AGMM, Manchester." canonical: https://agmm.co.uk/services/scheduling-and-booking-software/ updated: 2026-10-13 updated_basis: the date the page itself states publisher: AGMM (https://agmm.co.uk/about/agmm.json) lang: en-GB --- [All services](https://agmm.co.uk/services/) Operations software # Scheduling that is not held together by a shared inbox. Scheduling and booking software puts bookings, staff availability and customer updates in one place, so delivery stops depending on someone remembering. AGMM scopes it in a fixed £2,000, 14-day audit and builds it by proposal, connected to the tools you already run. [Book the free 30-minute fit call](https://agmm.co.uk/ai-constraint-audit/#book) [See every department](https://agmm.co.uk/services/#departments) Or call [0161 543 7189](tel:+441615437189) By [Sam Wall](https://agmm.co.uk/about/sam-wall/) and [Adam Gillett](https://agmm.co.uk/about/adam-gillett/) Checked on 13 October 2026 Two of the papers this work handles. Demonstration with sample documents. In the Audit we draw your real lines. Week 43, every engineer **Mon** **Tue** **Wed** **Thu** **Fri** Eng 1*Install* *Install* *Service* *Repair* *Service* Eng 2*Service* *Repair* *Install* *Service* *Install* Eng 3*Install* *Repair* *Service* *Service* *Install* The problem ## Scheduling depends on somebody remembering, so the busier you get the more it costs you. Booking, availability and keeping customers informed are three jobs that usually end up in one inbox and one person's head. That works until it does not, and it fails at exactly the moment you are busiest. Scheduling by memory works, right up until the week it matters. The failures cluster exactly where they cost the most: the busiest fortnight, the day somebody is off, the job that was confirmed verbally and never written down. And the damage is rarely the missed booking itself. It is the phone call afterwards, the apology, the customer who now checks up on you, and the hour somebody spends reconstructing what was agreed. Underneath that sits a quieter cost. If nobody can see current availability without asking, then every booking takes two people instead of one, and the person answering is usually the person you would rather have doing the work. Now picture yours ## The same work, three ways. Pick a line of work, press a stage, then step through the papers it handles. Each step shows the real document, and where a person stays in charge. Operations Confirmed without the back and forth Email Tue 13 Oct, 20:15 **From**: Mrs Okafor, website form **Subject**: **Boiler service, any day next week?** Hello, our boiler is due its annual service. Mornings are best for us. We are in Chorlton. 1. From a call, an email or the website. 2. What is booked, who is available and what is still open. 3. Lead times, working hours, skills and travel, applied automatically. 4. A new customer, an unusual job, a slot that breaks a travel rule: a person accepts it. 5. Confirmed, and in the calendar. 1. **As it runs now** Booking, availability and customer updates in one inbox and one person’s head. It works until the busiest week, which is exactly when it fails. 2. **Organised** Bookings and availability in one place, visible without asking anybody, with rules that reflect how you actually work. 3. **Agentified** Routine bookings confirm themselves and updates send on the rules you set. A new customer or an unusual job lands as a request for a person to accept. *A person decides Runs on its own Back with notes Demonstration. Sample documents, no client data. Timings compressed.* Signs you have it You will recognise some of these. - Booking is a back-and-forth of emails or calls before anything is confirmed. - Double bookings happen, or nearly happen often enough to worry about. - Nobody can see current availability without asking. - Customers chase you for updates you meant to send. - The busiest weeks are when bookings get missed, which is when it costs most. What we build ## What does the work include? 1. ### Bookings and availability in one place What is booked, who is available and what is still open, visible without asking anybody. 2. ### Customer updates that send themselves Confirmations, reminders and changes go out on the rules you set, rather than when somebody remembers. 3. ### Rules that reflect how you work Lead times, working hours, skills, travel and the exceptions you make, applied automatically. What it costs ## What does it cost? The audit is £2,000; the build is proposed after it **1The AI Constraint Audit**: **£2,000** 14 days, fixed **2The build**: **By proposal** Priced against what the audit found **3Ongoing support**: **By proposal** Only if you want it The published price on this page is the diagnostic: £2,000 for the AI Constraint Audit, fourteen days, three sixty-minute working sessions. A scheduling build is proposed after it and priced separately, because the cost of this kind of system follows the rules rather than the screens. Fixed slots against one calendar is a small build. Skills, travel time, several teams and the exceptions you make is a larger one, since every rule interacts with the others. The audit fee is not credited against the build. ## What does the £2,000 cover before anything is built? Four documents that are yours whatever you decide: a business-wide constraint map, an AI opportunity map, an economic case for each option worth considering, and a ranked order for spending. On scheduling the first question is whether an off-the-shelf booking tool would do it, and the audit is where that gets answered with your own availability rules on the table rather than in the abstract. If the answer is buy rather than build, you keep the documents and we have sold you nothing. The whole ladder, including what a build costs and what we do not bill for, is on [what it costs](https://agmm.co.uk/what-it-costs/) . How long ## How long does it take? Fourteen days from the first session to the written recommendation. The build runs in stages afterwards, and bookings and availability usually land before the automatic customer updates do, so something is in real use while the rest is still being shaped. 1. **Day 1** First working session 2. **Day 14** Written recommendation, yours to keep 3. **Then** First stage of the build, in real use 4. **Then** Next stage, only once the first is working Not in the price ## What this does not include - ### Calendar, messaging and payment licences Connecting to the calendar, SMS gateway or payment provider you already use is part of the work. Those accounts stay yours, you pay those providers directly, and we take no margin on any of them. - ### Support and hosting, inside the build price Reminders that must go out at seven in the morning need somebody watching them. Hosting, monitoring and changes after go-live are quoted as a running cost rather than folded into the build. - ### Data migration beyond what the audit scoped Existing bookings, customer records and recurring appointments have to be read before they can be moved. What is in scope is settled during the audit and priced in the proposal. - ### A guarantee of fewer missed bookings We will not publish a percentage we cannot source. Before anything is built you agree what you are counting, usually double bookings, no-shows and the time spent confirming by hand, and you keep counting it yourself. What you can check ## What can you check before you believe any of this? The nearest thing you can inspect today is how we run our own business. One of our knowledge bases holds 4,535 notes and 5.9 million words, and the systems that run on it, from the model fleet to the outreach engines, keep a receipt for every run and are drawn on Inside AGMM. It shows the standard we hold a delivered system to. It says nothing about your bookings and we will not pretend otherwise. What we cannot show you yet is a named scheduling client with a published before and after. [See the systems that run our own business](https://agmm.co.uk/evidence/) People and machines ## Where does a person stay in the loop? Some bookings should not be confirmed automatically, and deciding which is a business decision rather than a technical one. A new customer, an unusual job, a slot that breaks a travel rule: those can land as a request for a person to accept, while the routine ones confirm themselves. Reminders and updates run on rules you set and can stop. Nothing is cancelled, moved or charged by the system without an explicit rule somebody agreed, because the moment a customer is moved by software with no traceable reason, the phone call you were trying to avoid arrives anyway, and it is a worse one. - **Unusual ones to a person** *Bookings* A new customer, an unusual job, a slot that breaks a travel rule: a person accepts it. Proof it worked ## How do we know it worked? Count three things now and count them the same way later: how many messages it takes to confirm one booking, how many double bookings or near misses happen in a month, and how much time goes on chasing and confirming by hand. All three come from your own inbox and calendar rather than from an industry figure we would have to source. We do not measure bookings taken, because a busier month inflates it regardless of the software. If the confirmation count has not fallen, the rules were the problem rather than the tooling, and the fix is cheaper than another build. *A worksheet we fill in with you, from your own records* 1. Messages it takes to confirm one booking 2. Double bookings or near misses in a month 3. Time spent chasing and confirming by hand Same definition both times. If the number has not moved, that is a finding, not a failure. Known risks ## What tends to go wrong on this kind of build? Three. The first is availability rules that turn out to be preferences, where two people describe the same week differently and the build has to stop until somebody decides. The second is the integration surface: calendars, messaging and payment providers all change their own rules, so a live booking system needs maintenance rather than only a launch. The third is over-automating the front door. Every extra step between an enquiry and a confirmed booking costs you bookings, so the default stays a link that works in a browser with no app and no account. Fit, stated plainly ## What do we need from you? - Your real availability rules, including the exceptions you make for good customers. - Access to the calendar and the inbox where booking currently lives. - The people who take bookings today, including whoever covers when they are away. - A decision on what happens when two requests collide, before the software has to make it. ## Who this is not for - A business a standard booking tool would fit, where the objection is the monthly fee. - Availability rules nobody has agreed, where a system would freeze an argument rather than settle it. - A booking problem that is really a staffing problem. - A specification already written that needs implementation hands only. Questions ## What do people ask before they start? **Will it work with our existing calendar and job system?**: Usually yes. Connecting to the calendar and the job system your team already lives in is nearly always better than asking everyone to check a second place. What each of them exposes is checked in the audit, before anything is promised. **What about jobs that do not fit a standard slot?**: Those are the ones worth designing for. A scheduler that only handles the easy bookings just moves the hard ones back into the inbox. **What does scheduling software cost to build?**: It follows the rules, not the screens. Fixed slots against one calendar is a small build. Skills, travel time, multiple teams and exceptions you make is a larger one, because every rule interacts with the others. Our guide on what custom software costs explains what to ask anyone quoting you. **How long does it take to set up?**: We build in stages, so booking and availability usually land before the automatic customer updates do. Something is in real use early rather than everything arriving at once. **Do our customers need an app or an account?**: Not unless there is a reason. Anything that adds a step between an enquiry and a confirmed booking tends to cost you bookings, so the default is a link that works in a browser. **Should we just buy an off-the-shelf booking tool?**: If one fits, yes, and we will tell you so. Standard tools handle standard bookings well and cost far less than a build. It stops being the right answer when your availability rules are the awkward part, because that is exactly what those tools assume away. **What does a booking system cost to run each year?**: Hosting, the messages you send, and the changes a live system needs are running costs, and we quote them as running costs rather than folding them into a build price. Ask anyone quoting you what year two looks like. A figure covering only the build is incomplete rather than cheap. **What happens when two customers want the same slot?**: That rule is a business decision and it is made before anything is built: first confirmed wins, a provisional hold with an expiry, or a named person who arbitrates. A scheduler that leaves the collision unresolved has simply moved the argument back into the inbox. Free to read first ## Would you rather work it out yourself? Everything below is free, with no account and no paywall. If it solves the problem without us, that is a good outcome. - [AI for logistics and distribution: where the day goes](https://agmm.co.uk/industries/logistics/) - [Five automations to set up first](https://agmm.co.uk/learn/5-automations-to-set-up-first/) - [What custom software costs, and what moves the number](https://agmm.co.uk/learn/what-custom-software-costs/) - [How to calculate the ROI of automating a task](https://agmm.co.uk/learn/roi-of-automating-a-task/) - [Free course: automate your operations](https://agmm.co.uk/learn/courses/automate-your-operations/) ## What else is usually needed alongside this? - [**Custom CRM development** Sales and Leadership: enquiries, the pipeline and reports the team can trust.](https://agmm.co.uk/services/custom-crm-development/) - [**Custom process systems** Custom systems: the awkward process no off-the-shelf product fits.](https://agmm.co.uk/services/custom-process-systems/) [Everything we do](https://agmm.co.uk/services/) ## Tell us where the business is getting stuck. A short call to map the constraint and give you a clear next step. That might be software, automation, training or no build at all. [Book the free fit call](https://agmm.co.uk/ai-constraint-audit/#book) 1. Before day 1**Fit call** Free, 30 minutes 2. Day 01**Map the business** Constraints and weak points 3. Day 07**Price the opportunities** What could save or earn 4. Day 14**Rank the investment** Four outputs you keep **Then the proposal.** The fuller audit is always part of it. *Three 60-minute working sessions with the founders who would scope any build. Between them, we map, measure and price.* --- Source: https://agmm.co.uk/services/scheduling-and-booking-software/ · AGMM, a UK AI consultancy · company facts: https://agmm.co.uk/about/agmm.json · every page: https://agmm.co.uk/llms.txt