The Mill

The Mill does not primarily have a CRM problem. It has a collection of operational journeys: rooms, volunteers, activities, communications, partners, evidence, grants and finance, that have grown across separate tools, spreadsheets, folders, forms and individual working practices. The discovery identifies fragmented records, manual rekeying and hand-offs, disconnected room booking, fragmented communications, unclear decision rights and limited visibility of participation and outcomes as recurring problems.

The strongest conclusion of the earlier analysis is therefore that the issue is not the absence of a conventional CRM, but the absence of joined-up journeys, reliable ownership and a proportionate operational record.

The proposed response is deliberately incremental. The Mill should use inexpensive specialist services for activities they already perform well, simplify the public web experience, establish distributed ownership and authority, measure whether administration actually falls, and retire legacy processes only after replacements have proved themselves.

The current working technology hypothesis is:

• LemonBooking: rooms, events, booking, deposits/payments and potentially the public website.
• Plinth: volunteers, Network Organisations, community activity and impact.
• membermojo: organisation-owned membership where Network Organisations require it.
• Mailchimp: the authoritative Mill marketing audience and campaign service.
• Finance/banking: the authoritative financial record.
• Google Shared Drive: controlled documents and supporting evidence.
• Notion: internal knowledge and lightweight coordination where useful.
• Zapier: limited and documented integration glue.

This is a working architecture, not a commitment to implement every product or every capability.

The first proof should be rooms because room hire combines the website, customer experience, availability, policy, pricing, approval, payment, finance, access, communications and evidence in one bounded journey. The ambition is that a well-defined room should increasingly be capable of semi-booking itself: matching a customer's requirements against its profile, applying predetermined policies and pricing, taking a deposit, identifying exceptions and escalating only those decisions requiring human judgement.

Once that operating pattern has proved itself, the same principles can be extended to volunteers, Network Organisations, membership, participation and evidence. The objective is not digital transformation for its own sake. The Mill should be able to serve more people, organisations and activities, use its assets more effectively, increase earned income and produce better evidence without administration increasing at the same rate.

Why this matters: Millism describes what The Mill must protect while it modernises: the human, informal, community character that makes it The Mill.

Digitisation must preserve Millism. That means retaining:

• Human judgement
• Informality
• Accessibility
• Community initiative
• Volunteer contribution
• Assisted and non-digital routes where required
• Proportionate information collection
• The ability to deal sensibly with exceptions

The purpose of automation is not to turn The Mill into a corporate service centre. It is to remove hidden administration so people can spend more time doing the things that require people.

The discovery identifies low digital confidence and change fatigue as significant implementation risks, and recommends co-design, bounded pilots, assisted routes, minimal training and measuring whether administration genuinely decreases.

Training lite, task focused and role specific. Nobody should need to “learn the CRM”. They should learn the small number of tasks required for their role.

Why this matters: Not every existing process needs to change. This section sets out the test for deciding what is, and is not, in scope, and lists what the programme is deliberately not doing.

This programme does not assume that every existing process needs to change.

A process should only become part of the change programme where there is reasonable evidence that doing so will materially improve one or more of:

• The experience of residents, volunteers, staff, hirers or Network Organisations
• Administrative efficiency
• Operating cost
• Income or utilisation
• Resilience and continuity
• Privacy, control or accountability
• The quality and usefulness of evidence
• The ability of The Mill to grow without administration increasing proportionately

Processes that are specialist, already functioning adequately, affect only a small number of users, or would create more disruption than benefit, should normally remain unchanged. This is particularly relevant to funding applications, grant governance, accounting and other specialist processes; the programme may improve the interfaces around them, for example by making operational evidence easier to obtain, without redesigning the underlying process.

The default position is therefore:

Do not change a process merely because technology makes change possible.

A proposed change should be able to answer:

• What problem are we solving?
• Who materially benefits?
• What administrative effort or cost will fall?
• What measurable improvement should result?

If those questions cannot be answered convincingly, the process should remain outside scope.

The exception is where trustees, governance reviewers, regulators or accountable operational owners identify a material risk, control weakness or organisational requirement that justifies intervention, even where the benefit is not universal.

What This Programme Is Deliberately Not Doing

Applying this test, the programme does not currently propose:

• Procuring a large enterprise CRM
• Building a bespoke CommunityHub platform
• Integrating every application immediately
• Migrating every existing record
• Centralising all participant/member data at The Mill
• Automating human community judgement
• Collecting demographics because technology makes it possible
• Replacing the accounting system
• Buying dedicated technology for every activity
• Creating new central Forms/Data/Policy administrators
• Requiring every volunteer to become a sophisticated systems user
• Introducing AI before the underlying operational rules are understood

These are not omissions. They are deliberate design boundaries intended to control cost, disruption, privacy risk and administrative complexity.

The programme's governing principle is therefore:

Change where the benefit is material and sufficiently broad. Connect where an existing specialist process already works. Intervene where governance or risk requires it. Otherwise, leave it alone.

Why this matters: Rooms are where the new approach is proved first, because they combine income, community use and every operational step in one place.

Rooms provide the best first demonstrator because they are both a community asset and an income-producing asset; the current Mill strategy already describes the building as a community asset, income opportunity and safety responsibility, and the room journey follows a natural sequence of offer, request, authorisation, accounting and learning.

Each room should develop an authoritative profile, a single, trusted description of that room, covering:

• Dimensions and capacity
• Accessibility
• Facilities
• Furniture
• Equipment
• Permitted activities
• Support requirements
• Availability
• Set-up and clear-down
• Pricing
• Concessions
• Deposits
• Policies and terms

The customer's request describes: organisation; purpose; date/time; attendance; accessibility; equipment; services; pricing/entitlement status. The system can therefore increasingly determine:

The desired near-term outcome is not uncontrolled AI. It is bounded self-service: the system handles routine, predictable requests on its own, within limits The Mill sets, and refers anything unusual to a person. Routine bookings proceed automatically or semi-automatically where predetermined conditions are met. Human judgement remains for exceptions, concessions, policy issues or community priorities.

This is what is meant by the room increasingly “booking itself.”

Once the room journey proves this pattern, it can be reused across the organisation:

Why this matters: This single example shows, in practice, what the whole resilience approach means: reducing dependence on any one person, without criticising anyone.

Alison runs a small class of approximately 12 places. Despite the small capacity, she maintains a substantial spreadsheet for recruitment and participation, and receives repeated emails from parents asking routine questions. The purpose of this example is not to criticise Alison or the existing process. It is to show how a capable, committed person can gradually become:

Routine questions may include dates and times, eligibility, price, accessibility, what to bring and waiting-list status, and the answers can end up spread across Alison's spreadsheet, emails, web pages, forms and her own memory.

What happens if Alison is suddenly unavailable?

A suitably authorised deputy, or “Number 2”, should not need Alison's password, personal spreadsheet, historic emails or memory to keep the class operating.

The first step is to publish the answers to routine questions once, on the class's own web page, rather than answering the same question repeatedly by email. Routine, predictable communications can then be generated automatically, while anything unusual still reaches a person.

Publish the answer once rather than repeatedly answering the same question privately.

The Number 2 Test

If Alison becomes unavailable, a nominated deputy should be able to use their own authorised access and quickly understand current capacity, confirmed participants, the waiting list and outstanding exceptions, without contacting Alison directly.

Can a suitably authorised Number 2 take over without the Number 1 being available?

This becomes an acceptance principle for other important journeys too, from rooms to volunteers to communications. It does not mean duplicate administration merely to provide backup. The objective is:

Individual ownership without organisational dependency.

Appendix C sets out the full continuity checklist behind this example.

Why this matters: Before looking at individual changes, it helps to see the shape of the target model: fewer places for information to live, and clearer ownership of each one.

The Mill already possesses considerable digital capability. The problem is that capability has accumulated rather than been deliberately designed as one operating environment.

Current information and activity are distributed across combinations of:

• WordPress
• Google personal and shared drives
• Google Forms
• Spreadsheets
• Email
• Mailchimp
• WhatsApp
• Notion
• Zapier
• Finance and banking systems
• Local documents
• Specialist services
• Individual knowledge

This is found across volunteer, room, finance, mailing and project information alike, resulting in repeated searching, inconsistent records and weak handovers. Room hire illustrates the problem particularly clearly: availability, enquiry, approval, deposits and invoicing currently involve disconnected, manually coordinated processes. Communications show a similar pattern: overlapping mailing audiences, Gmail groups, WhatsApp and individual knowledge can make it difficult to know who should receive what and who owns a relationship.

The problem is therefore less: “Which CRM should we buy?” and more: “How do we make The Mill easier to operate without losing what makes it The Mill?”

The Mill needs to move from an environment organised around applications and files towards one organised around journeys, responsibilities and authoritative sources, the one agreed place each piece of information officially lives.

A simple target principle is: one thing should have one clear home, one accountable owner and understood authority for consequential change.

This does not mean putting everything into one database; that would create real risks of complexity, inappropriate visibility and administrative burden. The architecture instead stays distributed: bookings belong in the booking system, members of a Network Organisation stay in that organisation's own membership service, finance stays in finance, policies stay in controlled documents, volunteers and impact may sit in Plinth, and public information is published through the website. Information only moves to another system where another role genuinely needs it.

This reflects the emerging governance principle: named ownership of the individual thing, defined custody of the information, and explicit authority for consequential change.

Appendix A sets out the full Change Matrix, covering all thirteen operational areas with their current problems, proposed changes, benefits, risks and success measures. Appendix B sets out the fuller governance rationale.

Why this matters: The public website and the specialist systems behind it are one service, not separate projects; and Network Organisations keep responsibility for their own people.

The Mill should not regard the website and CRM as separate budget silos; they are components of the same service environment. The website should become the simple public front door for rooms, What's On, Network Organisations, activities, volunteering, joining links, policies, community opportunities, fundraising, art and events, and enquiries. The public should not need to know whether the service behind that page is LemonBooking, Plinth or membermojo.

Website publishes. Applications transact. Mailchimp markets. Custodial systems, the specialist applications that hold the current, trusted record for their area, retain the authoritative record.

Google Drive can then progressively return to being a document repository instead of an accidental operational database.

Network Organisations retain their own relationship with their members: The Mill manages The Mill's relationship with the Network Organisation, while the organisation manages its own relationship with its members. A participant may also remain simply a visitor without persistent membership. This avoids turning every community participant into a Mill CRM record.

Volunteer and Network Organisation Journeys

Once the room pattern of profile, request, conditions, authority, action and evidence has proved itself, it extends naturally to people and partners:

Appendix B sets out the fuller governance rationale that sits behind this strategy.

Volunteer Scheduling: A Related but Distinct Problem

Volunteer onboarding alone does not solve the operational problem. The Mill also needs an easier way to understand regular volunteer availability, know which roles or services a volunteer is willing and able to support, plan recurring services, identify gaps, find appropriate replacement cover, and reduce repeated WhatsApp, telephone and email discovery.

The target is not to turn volunteers into assets that can be automatically allocated. The distinction is:

Availability means “you may ask me”. Acceptance means “I have committed”.

The desired journey, at a high level:

And for cancellation:

The administrator manages matches and exceptions rather than repeatedly discovering availability manually.

The programme principle is:

Rooms first for implementation. Volunteer scheduling early for exploration.

Volunteer scheduling / community management: candidate to be confirmed through bounded discovery and supplier demonstration. Plinth remains one possible candidate for broader volunteer, Network Organisation and impact capability; LemonBooking or another commodity service may prove sufficient for scheduling and availability.

Appendix B sets out the volunteer profile and service profile model, a small discovery sandbox using synthetic data, and the criteria a candidate application should be tested against.

Why this matters: The roadmap shown in Visual 03 above is achievable at a modest, steady pace; this section explains the discipline that keeps it that way.

The programme should be achievable with approximately 2½ volunteer days per month, provided vendors, suppliers and operational owners perform routine implementation and operation.

A new system should not automatically trigger migration of everything associated with that subject. Instead: establish a measurable problem, record the current baseline, configure one bounded journey, test it with real users, compare the result with the baseline, improve if necessary, adopt, retire the displaced process, and move to the next journey.

Configure before integrating. Integrate before custom-building. Custom-build only where repeated evidence demonstrates an unresolved problem.

The important adoption gate is: do not scale a new process until normal users can operate it without specialist or volunteer rescue.

Every material change should also begin with a baseline and be checked afterwards against the same measures. For room booking, for example: number of enquiries, response time, time to confirmation, hours of administration, booking conversion, occupancy and income, measured both before and after each change.

The test is not: “Does the new application work?” It is: “Did the operating problem improve?”

Every introduction creates disruption, so the programme must identify not only what starts, but what stops.

Retirement should follow successful adoption, not precede it.

Legacy applications should not survive indefinitely merely because removing them feels uncomfortable; equally, familiar systems should not be removed merely because a new platform contains a similar feature. The criterion is operational value.

Appendix A lists the specific retirement candidates identified against each operational area. Appendix G sets out how progress against the roadmap should be measured.

Why this matters: The programme must not create a new dependency on one volunteer or one system; every capability should work even if that person is unavailable.

The transition must not depend on the transition volunteer.

Volunteer support can materially reduce the cost and risk of the programme, helping The Mill understand its current journeys, configure and test new processes, establish baseline measures, support initial training and ensure old processes are retired once replacements work. However, the volunteer must not become part of the permanent operating architecture.

If the transition volunteer became unavailable tomorrow, could The Mill continue operating safely and know where to obtain help?

Every capability should therefore be designed for organisational self-sufficiency from the outset. No important Mill process should depend on one volunteer, one member of staff, one personal Google account, one supplier contact, one undocumented Zap, one spreadsheet understood by one person, or one person's memory.

Appendix C sets out what each important service should have instead, and the detailed continuity checklist.

The same test applies to volunteer scheduling: a nominated deputy should be able to see services requiring volunteers, confirmed cover, gaps, potentially suitable replacements, accepted commitments and immediate exceptions, without needing somebody else's personal WhatsApp history, inbox or memory.

The organisation knows the state of the rota; the coordinator does not have to remember it.

Training should not consist of a large system manual; for each role, a small set of practical tasks and a one-page operating card is usually enough. A useful adoption measure is therefore not “How many people attended training?” but:

“Can two ordinary users independently complete the essential tasks?”

The discovery also recommends practical task-based training, volunteer support, paper fallback where necessary and measuring completion and confidence.

Over time, appropriate administrators and lead users should progressively become:

• Confident super-users
• Owners of their operational journeys
• First-line problem solvers
• Workflow improvers
• Informed users of supplier support
• Practical users of AI-assisted tools

AI assistance should support exploration, analysis and drafting; it should never independently change live permissions, policies or organisational authority. Their emerging capability, not a software-developer skillset, should be expressed through questions such as:

• What problem are we trying to solve?
• Where is the friction occurring?
• Can the existing application already solve it?
• What is the smallest change we could test?
• How will we know whether it improved the experience?

Appendix D sets out detailed role-by-role training tasks and the specific ways AI assistance can be used.

Commodity software materially helps here because The Mill is not expected to maintain the underlying technology itself; licence cost is unlikely to be the principal financial risk.

Appendix E sets out current supplier support and pricing detail for LemonBooking, Plinth, membermojo and Mailchimp.

Why this matters: The Mill is not being asked to commit to a fixed technology contract; it is being asked to approve a controlled envelope, released only as benefit is proved.

Rather than approve a five-year technology contract, The Mill could establish a five-year digital operating-model envelope and release expenditure progressively against demonstrated benefit. An indicative planning position is approximately £15,000 over five years. Make clear that this is:

• An indicative planning allowance
• Not a supplier quotation
• Not a commitment to spend
• Released incrementally against demonstrated benefit

Appendix F sets out the detailed budget breakdown and assumptions.

That envelope should be released in phases aligned with the roadmap, authorised only once the previous phase has demonstrated benefit, not committed as a fixed annual schedule. Part of it should be explicitly ring-fenced as a resilience reserve, assuming an external specialist rate of approximately £600 per day purely as a prudent planning allowance, enough to cover roughly five specialist days across five years for events such as a key volunteer's departure, a broken integration or an emergency handover.

“We can buy competent help when we need it.”

The earlier planning figure of approximately £24,000 is not discarded; it is reframed. Expenditure could drift towards £20,000–£24,000 or beyond over five years if the controls in this report are not established, principally through continued dependence on the transition volunteer, weak training, unnecessary integrations and retained duplicate processes.

£24k is not the budget ambition. It represents approximately the type of cost exposure that good governance, training, internal capability and disciplined scope control are intended to avoid.

The principal cost-control mechanism is not negotiating slightly cheaper licences. It is building sufficient capability inside The Mill to solve ordinary problems without repeatedly buying external intervention.

What trustees should therefore be approving is not:

“£15,000 for a CRM.”

but:

“Up to £15,000 over five years to create and sustain a simpler, resilient digital operating model, subject to phased proof of benefit.”

This discipline applies directly to volunteer scheduling: The Mill should not add another application for this purpose unless the demonstrated benefit exceeds the additional licence cost, training, support, data duplication, integration and continuity burden it would introduce.

Why this matters: This is the long-term destination worth keeping in view, even though the current programme is deliberately practical: a Mill that increasingly knows itself, and can present that knowledge to whoever needs it.

The immediate programme is deliberately practical: simplify the website, improve room booking, strengthen volunteer and organisation journeys, reduce duplicated administration and produce better operational evidence. There is, however, value in keeping sight of a longer-term destination.

As The Mill's network grows, it should not require The Mill to become the central administrator or data custodian for every participating organisation and individual. A more scalable model would allow:

• Community organisations to retain responsibility for their own members and participant relationships
• The Mill to retain authority over its rooms, facilities and operating policies
• Rooms and other assets to maintain structured profiles describing capacity, accessibility, facilities, availability, permitted uses and pricing conditions
• Network Organisations to establish reusable profiles and appropriate entitlements
• Only the information necessary for a particular booking, activity or report to be shared
• Routine requests increasingly to be matched against available facilities and policies automatically
• Human judgement to remain available for exceptions, concessions, safeguarding, community priorities and other consequential decisions
• Operational activity to create proportionate evidence for learning, funding and improvement

In that future state, a room could increasingly appear to “book itself”: a request is matched to an appropriate space, conditions are checked, an authorised price is offered, payment is taken and the booking proceeds unless a defined exception requires human attention. This is not a proposal for autonomous AI or the removal of community judgement. It is a vision of bounded automation operating within policies and authority established by The Mill.

The purpose of naming this now is not to build the future system during the current programme. It is to ensure that today's decisions do not prevent it. This favours:

• Modular rather than monolithic applications
• Clear ownership and authoritative sources
• Usable exports and interfaces
• Distributed responsibility
• Minimum necessary data sharing
• Explicit policies and permissions
• Technology that can be replaced incrementally

Appendix H sets out the full CommunityHubCierge provenance note.

The Mill's Dynamic Profile

As the programme progressively establishes authoritative information about rooms, activities, volunteering, policies, pricing, participation and evidence, The Mill begins, almost by stealth, to build a dynamic authorised profile of itself, a single, trusted, living picture, not a giant central database. The important concept is:

Single authorised versions of important facts, presented through different purpose-appropriate views.

Hirer view

relevant rooms, capacity, facilities, accessibility, availability, permitted uses, prices and Terms & Conditions.

Resident view

What's On, activities, accessibility, organisations, ways to participate or volunteer.

Network Organisation view

facilities, network opportunities, room access, relevant benefits, participation routes and promotional opportunities.

Volunteer view

roles, opportunities, support, practical guidance and activities.

Reception/administration view

today's authorised operational state and the exceptions requiring attention.

Trustee view

utilisation, earned income, participation, community reach, volunteer contribution, risk and improvement evidence.

Funder/reviewer view

authorised evidence relevant to the particular programme, outcome, obligation or KPI.

These are not competing descriptions of The Mill. They are different authorised views of the same organisational reality.

The Future Customer Experience

The longer-term ambition is that customers and partners increasingly describe what they need rather than having to understand The Mill's internal administration, for example:

“I need somewhere on Saturday afternoon for 18 children and parents, with wheelchair access, tables and somewhere to wash art materials.”

The customer describes the need. The Mill presents the best authorised match.

This is also the proper context for the existing “room books itself” language. It means bounded self-service within policies, information and authority already established by The Mill, not uncontrolled autonomous decision-making.

Evidence That Emerges From Activity

A more structured operational model should also make it substantially easier for The Mill to produce credible, timely evidence for trustees, funders and reviewers, because evidence increasingly emerges from normal activity rather than being reconstructed afterwards for a report.

Appendix G sets out the specific measures this can draw on.