A booking spreadsheet can work well for a small team. The difficulty starts when several people change it, the status is recorded in an email thread, or somebody has to remember which jobs are confirmed.
Before commissioning a replacement, describe the moment that keeps going wrong. “We need booking software” is a category. “Staff reserve a crew before the customer accepts the quote” is a problem you can scope.
Separate a request from a confirmed booking
An enquiry, a tentative hold and a confirmed booking can look similar in a row. Decide what each state means in your business and who can move a job to the next one.
For a hire business, submitting a request may need an availability check before anybody promises equipment. For a service business, a site visit or written acceptance might come first. Tell the builder which decisions require a person. A request form should describe whether a person must confirm the request.
Write the confirmation rule in one sentence. Your rule could read: “A manager confirms the date after checking the crew and receiving the customer's written acceptance.” Use the rule you actually want the business to follow.
Follow the information your team copies
Take one recent job and list where its details appeared: enquiry form, inbox, spreadsheet, calendar and accounting tool. Mark the information that was entered twice and the version staff treated as current.
The first useful change may be a connection between existing tools. If your team likes its calendar and accounting system, ask whether they can stay. A custom booking screen does not automatically justify replacing both.
Decide what changes after confirmation
Customers reschedule. Staff are away. Equipment becomes unavailable. A quote changes.
For each case, decide who can change the booking, who needs to know and which dates or amounts must be checked again. Keep a record of the agreed change so a colleague can understand the current job without reading a private conversation.
Also define cancellation. Does it free the resource immediately, need an approval, or wait for another action? The right answer depends on your operation and the written terms you use with customers.
Check the whole flow in the first release
A useful first release could capture a request, show it to the right person, record confirmation and put the confirmed job on the team's schedule. Test a normal job, a change and a cancellation.
Include the practical questions in the scope: mobile use on site, staff access, reminders, supplier integrations, data export and who helps if the system is unavailable. Where an external calendar or payment service is involved, confirm its access and constraints before treating the integration as agreed work.
Choose one team member to test with redacted examples. A calendar that looks right still needs the actual sequence checked, including whether the same request can create two jobs.
Bring these answers to the discussion
- Which mistake or delay prompted the project?
- What counts as a request, hold and confirmed booking?
- Who can confirm, reschedule or cancel?
- Where is the current record kept?
- Which tools should stay?
- What does a successful first release let the team do?
- Who approves the scope and tests the result?
Keep the first build tied to a flow your team already recognises. That makes the written proposal more specific and gives you a clear way to decide whether the finished work is ready to use.
Use the worksheet in our custom software brief guide to prepare the first discussion.
Article tools
Want this done for you?
Bring the process you want to improve, the tools you need to keep or the site you want to move.