A Development Brief Checklist for Animal Service Businesses

Start with the problem, not a prescribed solution

A useful development brief explains what your animal service business does, what problem or opportunity has prompted the work, who is affected and what should improve. Describe the outcome you need, rather than deciding in advance exactly how a website, booking system, portal or other software must be built.

Use this checklist to give suppliers enough context to understand the work and discuss suitable options:

• Business and users: Say what services you provide and who will use the system, such as customers, reception staff, carers, practitioners, managers or volunteers.
• Current journey and process: Describe what happens now, from a customer’s first enquiry through to the service being delivered and any follow-up. Note where information is recorded, who handles each step and where work gets delayed, repeated or missed.
• Problem and desired outcome: Be specific about what is difficult or what opportunity you want to pursue. Explain who experiences the issue and what a better process would let them do.
• Workflows: List the main tasks the system may need to support, including customer-facing steps and the work your staff do behind the scenes. Separate essential needs from ideas that would be useful but are not necessary.
• Information and systems: Note what information the business uses, where it currently lives and which existing tools may need to work alongside a new solution. If you do not yet know how information should move between systems, say so.
• Scope and constraints: State whether you are considering a website, booking system, customer portal, online shop, internal software or a combination. Include relevant operational constraints, responsibilities and any expectations for launch and ongoing support.
• Priorities: Identify what matters most and what could wait. This helps suppliers explain the choices and trade-offs in their proposals.

You do not need to turn this into a full technical specification. Treat it as a starting point for discussion: suppliers can use it to ask informed questions and recommend an approach that fits the business. Mark uncertain points as open questions instead of filling gaps with assumptions; that makes it easier to agree what needs investigating before scope is settled.

Describe the business, people and customer journey

Give suppliers a clear picture of the business and the people who will use the system. This helps them understand whose needs it must serve and where a customer journey passes between a customer, the animal service team and any other participant.

• Describe the business. Name the type of service or business, what it offers, where it operates and its opening patterns. If you have branches, mobile service areas or different ways of working, explain which details vary. For example, note if one branch handles walk-ins while another works by appointment.
• List the user groups. Include customers or pet owners and the staff roles involved, such as reception, practitioners, groomers, carers, managers or volunteers. Add suppliers or other participants only if they take part in the process the system needs to support.
• For each group, say what they need to do. A customer might enquire, provide information about an animal, make or change a booking, pay, or arrange collection. A staff member might review the enquiry, confirm a suitable slot, prepare for the visit and record what happened. Be clear about who takes over at each hand-off.
• Describe the information each person needs. Keep this practical: for instance, a customer may need service options and confirmation details, while staff may need the booking context and relevant care instructions. Note where one person supplies information that another must check or act on.
• Walk through the customer journey in order. Cover how someone first gets in touch, what happens to an enquiry, how a booking or application is made and confirmed, how changes are handled, and what happens at payment, collection or follow-up where relevant. Include the less common route if it creates extra work, such as a request that needs staff approval.
• Explain how customers contact you now. Note the channels used for enquiries and bookings, and identify which journeys matter most to improve. If customers repeat information through several channels or staff have to move details between them, describe that hand-off rather than prescribing a technical fix.
• Attach a simple journey sketch or anonymised examples if useful. A short example can show what happens when an appointment is changed or an application needs follow-up. Do not include identifiable customer or animal information unless you have checked how it should be shared.

A supplier should come away understanding not only what the customer sees, but who handles each step and what needs to reach the next person for the service to continue.

Map the work behind the service

For each important workflow, describe what happens behind the customer-facing journey: who acts, what information they need, where they record it and what must happen before the work can move on. This helps a supplier see the operational system you need, rather than only the screens customers will use.

• Trace the usual process from start to finish. For example, note who receives a request, checks availability or information, confirms the arrangement, carries out the service and records its completion. Include the people involved, such as reception staff, practitioners, carers, managers, volunteers or fulfilment staff.
• Show what information moves at each step. Say what staff look up, add or pass on, and where it is currently kept: a booking record, paper form, shared document or another system. Identify information that has to be available to the next person, and where staff currently copy it by hand.
• Include routine exceptions, not just the ideal path. Explain how the work changes when someone cancels, does not arrive, needs to rearrange, collects an animal late, or supplies incomplete details. Include unavailable capacity and repeat visits where they affect the process. Note who decides what happens and who needs to be told.
• Describe hand-offs and approvals. Make clear when work passes from customer-facing staff to a practitioner or carer, or from a manager to a team member. Say what information accompanies the hand-off, whether someone must approve the next step and what staff do if that person is unavailable.
• Explain care-related variations. Describe what staff need to do when an animal has particular care instructions, needs an adjustment or cannot follow the usual process. Specify who records the instruction, who must see it and how staff know it has been acknowledged. Use anonymised examples rather than identifiable customer or animal details.
• Flag workarounds and delays. Point out where staff re-enter the same information, keep parallel records, wait for a decision or rely on a manual reminder. Say what problem each workaround creates, such as missed updates or uncertainty about which record is current.
• Separate the need from a preferred interface. “Staff must see current care instructions before the appointment” describes an operational need; “put the instructions in a red box at the top of the screen” is one possible design. Tell suppliers the need first, then mention a preferred approach if there is a practical reason for it.

If a process is hard to explain, attach a short process map, an anonymised sample form or a simple scenario showing what happens and who acts next. Keep it focused on one real workflow, including an exception, so suppliers can see where information or responsibility changes hands.

Add the module for your type of animal business

Choose the module or modules that fit your services, then tailor the prompts to how your business works. For a mixed business, mark which requirements belong to each service.

• Veterinary practices: Describe booking, consultations, animal records and follow-up, including who updates each record.
• Groomers: Set out service needs, appointment lengths, staff or mobile capacity, and repeat bookings.
• Boarding and daycare: Map enquiries, suitability checks, stays, capacity, care instructions and customer updates.
• Rescue and rehoming: Explain animal profiles, applications, assessment, matching, handover and follow-up.
• Pet retailers: Set out product information, stock and replenishment, sales channels, orders, fulfilment, returns and repeat purchases.

Note any exceptions or hand-offs that change between services.

Veterinary practices

For a veterinary practice, describe how appointments, consultations and animal records fit together in day-to-day work. Use these prompts to explain what the system needs to support, rather than specifying a particular practice system.

• List the appointment types you offer and explain how a request is received, reviewed and confirmed. Note how staff handle changes, cancellations and follow-up.
• Describe the animal and owner details staff need to find or update during a visit. Identify which roles need to view or change each kind of information.
• Map the hand-off from reception to clinical staff and back. Explain how the relevant appointment details and care or visit information are made available to each person involved.
• Include exceptions such as an urgent enquiry, a repeat visit or an incomplete record. For each, say who takes action, what information they need and what happens next.
• Flag operational requirements that need discussion with a supplier, such as how the proposed service would fit existing appointment and record-keeping processes. Separate essential needs from preferences, and use non-identifiable examples if they help explain a workflow.

Groomers and mobile groomers

For a grooming service, describe how an enquiry becomes a confirmed appointment and what affects the time and capacity available. Include the details suppliers need to understand the work, rather than assuming a particular booking feature.

• List the services offered and how appointment length varies by service or animal. Explain which staff, rooms or equipment must be available, and any limit on animals being handled at once.
• Set out what customers need to provide before a visit, such as grooming preferences or instructions. Say who reviews this information and how it reaches the person doing the work.
• For mobile grooming, describe the areas served, how travel between appointments is planned and what happens when a journey or appointment takes longer than expected.
• Explain how customers request changes, who confirms the agreed work, and how staff record that agreement. Describe what happens if an appointment overruns or the grooming cannot proceed, including how the customer is told and the next step is arranged.

Boarding and daycare providers

Use this module to show how a booking becomes a planned stay or attendance day, and what staff need to deliver the agreed care.

• Trace the booking: Set out the steps from enquiry or booking through confirmation, arrival, the stay or attendance period, collection and any follow-up. Note who handles each step and what information they need.
• Explain capacity: Describe how staff check availability and allocate places, including differences between accommodation or care types. Flag any limits or checks that affect whether a booking can be accepted.
• List care information: Identify the instructions staff need to see, where they need them and who may add or change them. Explain how updates reach the right people across shifts.
• Cover arrival and collection: Specify the details recorded at check-in and what staff confirm or pass on at collection.
• Include exceptions: Describe how date changes, cancellations, late arrivals or other disruptions affect capacity, schedules and daily tasks, and who updates the plan and informs the customer.

Rescue and rehoming organisations

For a rescue or rehoming service, use this checklist to describe how an animal moves from profile preparation through adoption enquiry and follow-up.

• Animal profiles: Record what information is collected, who checks it, who can update it and how changes are kept current. Explain how staff decide which details are shared with prospective adopters, and how photographs or care notes are added and reviewed.
• Applications: Map each step from an initial enquiry to assessment, a decision and any follow-up. Note what information applicants provide, who reviews it, where decisions are recorded and how work passes between staff or volunteers.
• Roles: Explain what prospective adopters need to view or submit, and what staff and volunteers need to see or update. Identify who handles enquiries, assessments, animal-profile changes and adopter follow-up.
• Exceptions: Describe what happens when an animal becomes unavailable, an application needs more information or a decision is deferred. Say who updates the profile or contacts the applicant, how the next action is tracked, and how other people involved are kept informed.

Set out information, systems and constraints

Give suppliers enough detail to understand what information the system must handle and the conditions it must work within. A concise inventory is more useful than a long dump of records: describe what staff need to enter, see, change or report, and who should be able to do each of those things.

• Information to handle: List the information the system needs to collect, display, update or report. For example, distinguish customer contact details from an animal’s profile, care instructions, appointment or booking details, and the status of a request. Note which information is needed at each stage of the workflow and what staff need to find quickly.
• Access and responsibility: Identify the roles that use each type of information, such as reception staff, practitioners, animal carers, managers or customers. Explain who creates or updates a record, who needs to review it, and whether some users should see only part of it. Describe the practical hand-off, rather than assuming every user needs the same view.
• Current tools: List the systems, spreadsheets, paper records or other tools in use. Name products only where you know them. For each one, say what information it holds, who relies on it and whether it should connect to the new system or remain in use. Be specific about the information that needs to move between tools, such as a booking status or customer details.
• Existing records: State whether information may need to be transferred, which records are involved and who can explain their format, completeness and quality. Flag known duplicates, gaps or inconsistent fields. If you do not yet know whether records can be transferred, mark that as a question for the supplier rather than assuming it is straightforward.
• Day-to-day constraints: Note where and how people will use the system: for example, at a reception desk, in a treatment room, on visits, or while moving around a site. Describe relevant devices, connectivity, locations, accessibility needs, languages, staff training and reporting requirements. Include only the constraints that affect how work is done.
• Obligations and open questions: Record requirements your business has already identified, and separate them from points that still need checking with a supplier or an appropriate adviser. Avoid presenting an assumption as a confirmed requirement. This helps suppliers identify what they can scope and what needs clarification.
• Budget and timing: Share the budget parameters and decision or planning dates your business is working to, if you are ready to do so. Label them as your constraints, not as an estimate of a supplier’s price or delivery schedule.
• Safe examples: Do not put unnecessary personal or sensitive information in the brief. Use anonymised examples to show how a record or hand-off works, and remove details that could identify a customer or animal’s owner.

Rank requirements and show suppliers what matters

Give each requirement a priority so suppliers can distinguish what the first release must do from what can wait. Use the same labels throughout the brief and explain the reason behind each essential item.

• Essential for launch: Include a need here if the business cannot safely or effectively provide the service without it. State the workflow or problem it addresses, and what a user should be able to do. For example, a staff member needs to find the relevant animal’s care instructions before a handover.
• Important but flexible: Describe outcomes that matter, while leaving room for a supplier to suggest a different process or way to meet them. Explain any conditions that would make an alternative acceptable.
• Suitable for a later phase: List useful additions that are not needed to begin using the system. This helps suppliers separate launch scope from possible follow-on work.

Prioritise the result, not an untested solution. If you have written “add a dashboard” or named a particular screen, explain what decision or task it should support. A supplier may recommend a simpler route, or identify that a proposed feature would not resolve the underlying problem.

For each important requirement, add a short, practical example of success. Describe the user, the point in the workflow and the information or action involved. Keep examples consistent with the processes and exceptions already set out in the brief; avoid turning them into specifications for every screen or edge case.

Ask each supplier to respond against your priorities, rather than sending a general description of its proposed system. Request that the proposal:

• Summarises what it has understood about the priority workflows and intended outcomes.
• Separates confirmed requirements from assumptions, exclusions and questions that need discovery.
• Explains how its proposed approach would handle the essential workflows, connect with existing systems, and deal with any information migration and ongoing support needs you have described.
• Identifies alternatives, including an existing product, configuration or process change, where these might meet the need. Ask what each option would and would not cover.

Tell suppliers who is expected to make decisions, provide information, review proposals and approve changes, but only where those responsibilities have been agreed. If ownership is undecided, say so. Clarifying this early helps suppliers show where they need input and avoids treating an unconfirmed assumption as part of the plan.

Use the same priority labels and response questions for every supplier you approach. You can then compare proposals on how well they address the work that matters, what remains uncertain and which trade-offs need a decision—not simply on the number of listed features.

Decide whether to buy, adapt or commission a build

Use the priorities in your brief to compare three routes: an existing product, a configured product or process, and a custom build. A distinctive service does not automatically need bespoke software; the important question is which route can support the work that matters without creating unacceptable gaps or operating burdens.

• Investigate an existing product if its standard workflows appear to cover your essential needs. Ask suppliers to show how staff would complete the relevant tasks, such as handling a booking change or passing care information to the next person. Record any limitations and decide whether they are acceptable.
• Consider configuration or a small process change where the core workflow already works and the gap is narrow. For example, check whether changing a form, permission or notification could resolve the issue, or whether staff can reasonably adjust a hand-off without losing important information.
• Explore a custom build when an important workflow, hand-off or connection between systems cannot be handled suitably by the options you have considered. Describe the specific gap and its effect on staff or customers; do not rely on “our service is different” as the only reason.
• Compare like with like. Give each supplier the same prioritised checklist and ask them to mark what their approach meets, partly meets or does not meet. Include the work of adapting existing processes, moving information and supporting day-to-day operation.
• Ask what happens after launch. Clarify who will manage access, updates, support, data changes and issues, and what your staff will need to do. Compare these responsibilities across all routes, not just the initial solution.
• Request the trade-offs. Ask suppliers to state assumptions, exclusions, workarounds and unmet needs, and to explain why they recommend their route. Keep unresolved questions visible so you can investigate them before choosing.

This comparison can show that a product is sufficient, that a limited adjustment is needed, or that a bespoke solution merits further scoping. Leave room for suppliers to propose alternatives rather than specifying a build before the need is clear.

Prepare a concise supplier pack and invite proposals

Bring the brief together as a short pack that gives each supplier the same picture of the work. Include:

• Business summary: what services you provide, where and how you operate, and whether the project covers one service or several.
• Problem and outcomes: the issue to address and what should work better for customers, staff or animals.
• Users and journeys: who will use the system and a simple map of the customer journey or operational process, including key hand-offs and exceptions.
• Relevant business-type module: include the workflow prompts that match your service. For a mixed business, combine the relevant modules and label which needs apply to which service.
• Priorities and constraints: separate essential requirements from useful extras, and include the systems, operational limits, budget parameters and open questions already identified.
• Supporting examples: attach only material that makes the work clearer, such as anonymised forms, sample schedules, process sketches or screenshots of an existing system. Remove identifying details where they are not needed.
• What is known and unknown: mark confirmed requirements separately from assumptions and questions for suppliers to explore. This helps avoid treating an early idea as a settled requirement.

Send the same core brief to each supplier. Ask them to explain how their proposed approach addresses your priorities, what they have assumed, what is excluded and where an alternative might fit better. You can then compare proposals against the same needs rather than their different interpretations of an informal conversation.

When making an enquiry, name the animal service and project type clearly, particularly if your organisation offers more than one service. Include the brief and any relevant examples, and invite suppliers to raise gaps or questions before they propose an approach.