From a multi-service website to a connected business operating system.

A single enquiry can contain several different types of work. A customer may need equipment, an operator, collection from another supplier, delivery to a venue, assistance during an event and a return journey afterwards. The visible service might last an hour, while the commitment spans several days. Treating that booking as one product and one calendar entry makes the surrounding work difficult to see.

The administration is equally varied. A sales conversation may begin on the website, continue by email and finish with a WhatsApp parking update. A freelancer needs a role, a fee and clear timings. A venue may require accreditation information. An administrator needs to distinguish an accepted proposal from money actually received. Each activity has a different audience, but all belong to the same operational story.

WD82 Core addresses this by joining commercial and operational records rather than simply adding more contact forms. Its central model relates customers, named contacts, quotations, Job Cards, assignments, transport tasks, documents, messages, expenses and approvals. The website becomes an entrance to that model, while the internal workspace and account portals provide different ways of working with it.

The design brief also rejects unnecessary navigation. Where the information is already known, an everyday action should be close to the record being reviewed. Opening a conversation should not require reconstructing the customer identity. Allocating crew should not mean retyping the job date. Moving test records out of the live Jobs table should not require opening every record individually. The aim is fewer repeated decisions, not merely smaller buttons.

However, speed is not the only measure of a good workflow. A message still needs an explicit sending route. A quotation still needs a valid commercial state. A destructive operation still needs a reviewable scope. WD82 Core therefore combines shortcuts with permission checks, recorded transitions and recovery controls. The case is about reducing avoidable administration while keeping consequential decisions visible.

WD82 Core is a WordPress plugin, not a separate application that replaces the website. Its supplied package combines the Core operating features with an embedded customer Assistant. Products remain WooCommerce products, and WooCommerce remains the designated order and payment system. Core adds the relationships, commercial rules and operational workflows that a multi-service business needs around those records.

This separation gives the platform a useful division of responsibility. The product describes an offering. The quotation describes the proposed commercial arrangement. The Job Card describes the work to be delivered. An assignment connects a person to a defined piece of that work. A transport task records a movement. A payment record describes money, rather than standing in for operational completion. Linking these objects does not make them interchangeable.

The Assistant also retains its conversation and public quotation records. These support the customer journey and its history, but the implementation synchronises the relevant client, proposal and job information into Core. In the saved-quotation path, a Proposal-stage Job can be reserved before slower enrichment is completed. This makes the enquiry visible to operations without waiting for every supporting process to finish.

The package contains specialist modules for messaging, operations, logistics, crew workflow, catalogue management, private documents, copy quality and workspace improvements. These are supported by WordPress administration screens, front-end account views, scheduled tasks and authenticated interfaces. Administrators can work directly through the interface; appropriately authorised integrations can use the exposed tools.

The resulting architecture is best understood as a connected operating layer. It is not a claim that every external dependency has disappeared. Hosting, email transport, SMS and WhatsApp services, payment gateways, AI services and optional publishing integrations still have their own configuration and availability. Core’s role is to organise their contribution and record what actually happened, so an accepted request is not confused with a completed delivery or a settled invoice.

WD82 Core introduces five principal classification systems alongside ordinary WooCommerce categories: Business Areas, Offering Types, Customer Types, Industries and Service Locations. Products and editorial posts can share these classifications. A service can therefore be understood by what it is, who it serves, which operational division owns it and where it is relevant.

Business Areas provide a hierarchy rather than a flat collection of unrelated labels. Offering Types distinguish services, hire, physical products, packages, subscriptions, training and consultancy. These distinctions matter because the same website may contain an item that can be purchased, equipment that can be hired and a service that needs an operator. The catalogue should not imply that those transactions follow identical rules.

The visitor can enter through a business-area page, a product category, a service-location context, a guide or the Products and Services A–Z. Related-capability features connect the surrounding content without requiring each article to become a separate sales microsite. The same underlying product can appear where it is genuinely relevant, instead of being recreated for every audience or location.

Core includes tools for normalising business-area names, maintaining relationships and resolving legacy naming differences. It can connect business areas with product categories and editorial categories, while its links and breadcrumbs help explain the current position within the website. This provides an editorial structure as well as a database structure: the customer can move from a broad capability to a specific offering and then to practical guidance.

The operational advantage is consistency. When an administrator improves a product description, classification or commercial field, the connected views can use that record rather than a manually copied alternative. This does not make classification self-correcting; inappropriate assignments still need review. It does, however, give the business a defined place to maintain the meaning of its catalogue, rather than relying on a growing collection of disconnected landing pages.

A useful product record needs more than a title, price and photograph. WD82 Core adds information about the way an offering is supplied, its commercial model and the practical conditions attached to it. Product badges, supplementary details, quote messaging and related services help make those distinctions visible to the customer.

Hire functionality supports variable products and period-based pricing. The supplied code contains standardised hire-period handling and mechanisms for detecting legacy combinations that need review. It also distinguishes operated services from equipment that can be supplied without an operator. Product policies can require attendance rather than allowing a misleading dry-hire choice; the availability and quotation paths recognise the operator-required condition.

This matters when the catalogue contains both ordinary equipment and specialist work. A customer should not be offered an apparently simple equipment transaction where the actual service depends on trained personnel, access checks or a bespoke scope. Conversely, straightforward items should not be forced into a lengthy consultation merely because other parts of the business are more complex.

Commercial fields also support pricing presentation. Core has mechanisms for showing an appropriate starting price, explaining the selected variation and maintaining a protected hire base rate. It can identify products whose existing periods or prices warrant an audit. These are operational controls over the catalogue, not a guarantee that every price already reflects the correct market position or profitability target.

The product remains usable by the surrounding WooCommerce and Elementor environment. Core stores linked products for consumers such as product widgets, while avoiding a duplicate native upsell block where the designed product template already owns that presentation. This is a small but important example of the broader approach: the platform enriches the existing commerce record while trying to prevent two components from rendering contradictory or overcrowded versions of the same information.

The product wizard brings together assisted extraction, research, drafting and creation. Rather than starting every catalogue entry from an empty editor, the administrator can work through a structured workflow that produces proposed information and then applies it to an actual product. Existing classifications can be used to organise the result.

Pricing research is a distinct part of that workflow. The wizard contains research instructions, response cleaning and audit functions, together with actions for applying reviewed prices. It also has minimum-hire-rate safeguards, payback-related configuration and routines for maintaining standard hire periods. The purpose is to reduce arbitrary or inconsistent catalogue pricing, especially where a large collection of products has evolved through several versions of the site.

The important distinction is between a researched suggestion and an authorised selling price. Research can inform a decision; it cannot establish that a particular supplier price is current, that the item is available or that every cost has been included. The administrator still owns the published commercial position. Core’s benefit is that the investigation, proposed correction and applied product data can sit within a repeatable workflow.

Bulk maintenance extends beyond individual prices. The catalogue tools can clean product titles and slugs, identify uncategorised items, assign meaningful categories and rebuild suitable product relationships. Migration work can be queued and processed in batches rather than attempting an unlimited rewrite during one browser request. This makes large-scale housekeeping a managed activity rather than a sequence of improvised edits.

The case-study lesson is not that a product wizard replaces commercial knowledge. It is that the business can encode recurring decisions and make exceptions easier to find. An unusual hire period, incomplete classification or implausible inherited rate becomes something the system can surface for review. That is more useful than allowing inconsistencies to remain invisible until a customer encounters them during a quotation.

The checkout module captures hire-specific information and carries it into the basket and order. It validates relevant inputs, preserves item details and provides administration visibility after purchase. This reduces the gap between what the customer selected and what the operations team subsequently needs to understand.

Delivery has its own commercial logic. The supplied mileage-based shipping method uses a base postcode and destination postcode, cached geocoding and a distance estimate. It combines vehicle mileage, estimated driver time and handling with configured minimums and other thresholds. The model recognises that moving equipment involves labour as well as fuel.

The implementation estimates road mileage from straight-line distance using a configured factor. It is not a live road-routing or traffic service. That distinction is important for interpreting the price: a reproducible estimate can support quoting, but unusual routes, access restrictions or venue-specific costs may still require review. The method also provides a fallback charge when postcode resolution is unavailable, rather than pretending that an exact route has been calculated.

Different baskets can involve different numbers of journeys. Dry hire can require delivery and later collection, while equipment travelling with an attending team may share an existing movement. Sale-only orders have no hire-return requirement. Product overrides can indicate courier handling or other arrangements. The shipping calculation considers the requirements present in the basket rather than automatically applying the simplest journey assumption.

Configuration includes delivery radius, minimum basket, an optional delivery-included threshold and charge labels. This allows the business to make its logistics policy explicit. The wider value is commercial clarity: delivery is treated as a planned service with costs and boundaries, not an afterthought added after a headline equipment price has already been accepted. The eventual transport itinerary remains a separate operational record, because a shipping estimate is not a driver instruction.

Core provides a collection of front-end shortcodes for presenting its catalogue and editorial relationships inside website layouts. These include business-area listings, product grids, a capability index, a guides hub, area heroes, related capabilities, related areas, product links within posts and business-area context links. The components allow the website design to use the same classified records without manually rebuilding each list.

The platform also supplies context badges and breadcrumb integration. A visitor can see whether they are viewing a product, business area or another content layer, with links back to the relevant index. Core includes support for WooCommerce breadcrumbs and filters used by Yoast and Rank Math. The objective is a compact explanation of context, not several competing navigation systems above the same content.

The Guides Hub connects practical articles with the products and business areas they explain. This is useful when an enquiry begins with a question rather than a product name. A visitor researching access, power or event preparation can move towards a relevant capability without being forced to restart their search elsewhere on the site.

Core also contains targeted Elementor maintenance actions, including stylesheet regeneration and related compatibility handling. Its product-template logic avoids injecting an additional squeezed upsell block underneath a layout that already presents related products. These features reflect a practical concern: a connected data model is only helpful when the front end remains legible and does not duplicate the same information.

This case study itself follows that principle. It is provided as static, scoped HTML for an Elementor HTML widget, rather than requiring a new plugin or a live connection to private records. Its content is readable without JavaScript, its navigation uses ordinary section links and its styling is contained within the article. The page explains the operating platform without exposing the operational platform to public visitors.

WD82 Core includes a site-planning module that can establish and connect a content structure from the existing business classifications. It supports business-area pages, a capability directory, editorial skeletons, existing-content wiring and menu synchronisation. It also contains repair routines for legacy or incomplete generated content, allowing site structure to be maintained after the first build.

The SEO module addresses titles, descriptions, canonical destinations and the coexistence of other SEO plugins. It can identify unresolved legacy paths, audit links, repair supported link patterns and normalise term names. Duplicate archive descriptions receive specific handling, reflecting the fact that a theme, builder and plugin can otherwise present overlapping introductions on the same page.

Editorial generation is connected to the catalogue rather than treated as a source of unlimited unrelated articles. The site planner can queue taxonomy descriptions and product examples, track progress and revisit incomplete output. Templates for supporting pages are available, but a generated legal page should be understood as editable website content, not professional certification of the business’s terms or practices.

Media handling includes product-image queues, generation status, retry controls, filename hygiene and metadata enrichment. Existing filename problems can be previewed and repaired through bounded work rather than an indiscriminate rewrite. The media module records ownership relationships so that filenames can remain meaningful without repeatedly adding the same prefix or assigning a shared image to the wrong product.

AI-assisted visualisation also has an explicit place. The catalogue contains a canonical WD82 logo asset and routines for applying the real logo to relevant generated renders. A disclosure component and caption handling distinguish visualisations from photographs of completed work. This supports a catalogue that can explain a genuine capability before a suitable project photograph exists, without presenting an artist’s impression as evidence that a particular installation has already happened.

The embedded Assistant provides several defined customer journeys. Visitors can browse the catalogue, ask about availability, build a quotation, seek help with an account or send a question to the team. A separate freelancer path collects applications, rather than treating someone looking for work as a customer who wants to buy a service.

The quotation journey includes product selection, quantities, basket review, required fields, options and amendments. It can present the quotation, lead towards an eligible checkout and support sending a copy through configured communication routes. Account-related paths cover jobs, orders, photographs, password assistance and transcripts, with access checks around information that belongs to an existing account.

These flows are not all dependent on free-form language generation. The engine contains defined nodes, choices and field prompts, as well as knowledge-base matching. Open-ended questions can use AI, but the structured route provides a reliable way to gather the facts that the next business operation actually needs. This matters particularly on mobile, where visible choices can be easier than asking a visitor to guess the right wording.

Known details and previous conversation context can be carried forward. The objective is to avoid repeatedly asking for information already available in the authorised session. At the same time, the Assistant should not make identity or booking changes solely because a message sounds plausible. Customer-facing tools are constrained separately from administrative tools.

The case illustrates a useful division between conversation and execution. A natural-language message can identify the likely intent, but saving a quotation, retrieving a private job or updating logistics is a defined operation with its own validation. The Assistant is therefore an entrance to the operating system, not an unrestricted substitute for it. A helpful reply must reflect what the underlying operation actually returned, including a genuine need for review when the required information or authority is missing.

The quotation subsystem does more than produce a formatted document. It builds line items, applies relevant hire rules, calculates totals and adds transport information. Quotations have references, stages and recorded events, allowing the business to follow the progression from an initial proposal towards acceptance, payment, expiry or decline.

Both catalogue items and custom lines can be represented. This is important for mixed-service work where not every element has a neat retail equivalent. A proposal can explain an operated service, additional labour or a bespoke requirement while retaining structured commercial information beneath the presentation. The generated HTML, text and email versions are different presentations of the quotation, rather than independent offers that happen to share a title.

A saved quotation can be amended, but payment eligibility is checked against its current state. The implementation has guards for expired, cancelled, declined and otherwise closed quotations, and it checks availability before allowing the checkout route. It also maintains snapshots and hashes so an order can be compared with the commercial information from which it was created.

Decline is treated as a legitimate outcome, not an absence of response. Public response pages support decline reasons and stopping follow-up contact. The company also has a closure route. These states can stop associated follow-ups and affect linked checkout orders, avoiding the impression that a quotation remains payable after it has been deliberately closed.

Recovery and duplicate protection are significant features here. Requests carry identities, quote creation uses locks and existing outcomes can be recovered rather than blindly recreated. These controls are intended to reduce duplicate quotations, duplicate orders and repeated messages when a browser retries or an external request is interrupted. The commercial benefit is not merely tidier administration: the customer and the business have a clearer record of which offer is current and what accepting it would mean.

Core supports a Job Card-led proposal workflow as well as the Assistant’s quotation journey. Administrators can prepare or update proposal content from the job, preview the customer-facing version and send it through the appropriate controlled action. The job retains the relationship between the scope, commercial value and customer response.

The Terms Library provides reusable commercial modules. Relevant modules can be selected or suggested from the work and linked products, rather than placing every possible condition into every proposal. The implementation covers the idea of a master agreement supported by service-specific sections, with the selected content preserved in a versioned snapshot.

A snapshot includes the terms version, module selection, content and creation time, together with a hash. This makes the agreement record more useful than a link to a page that may subsequently change. The purpose is to retain the proposal’s commercial context, not to certify that the terms are legally suitable for every transaction. Responsibility for approving the wording remains with the business.

Proposal response handling supports acceptance and decline, with expiry and state checks. The customer can therefore respond to a defined offer rather than sending an ambiguous message that needs to be interpreted manually. The implementation can link the response back to the Job Card and the account relationship, while preserving the distinction between an accepted offer and an invoice or payment.

The same workflow supports a clearer handover from sales to operations. An administrator does not need to decide which email attachment contains the final scope before allocating the work. They can inspect the proposal attached to the canonical job and follow its recorded state. Where details change after the agreement, the surrounding review and invoice controls help prevent an old approval from silently authorising a new commercial arrangement.

The Job Card is the organising record for delivery. It can hold the reference, customer and company, named contact, service and equipment summaries, dates, times, venue, address, postcode, linked products and staffing requirements. It also connects the proposal, crew, logistics, documents, messages, financial information and activity surrounding the work.

The lifecycle is controlled rather than being an unrestricted colour selector. The source defines transitions between enquiry, proposal or quoted, confirmed, in progress, completed and cancelled states. A cancelled job can return to enquiry through a supported transition; a completed job is not casually moved into an unrelated state. History records make these decisions inspectable afterwards.

Readiness is presented alongside status. A job can exist without being ready to deliver, and the interface provides a place to identify missing information or record a readiness note. Booking helpers bring common actions closer to the record: accessing customer communications, resending appropriate booking details, checking account linkage and starting an invoice workflow do not require rebuilding the job context elsewhere.

The record workspace adds related-record access and an activity timeline. A user can inspect connected information while retaining a clear view of the job they are working on. Some previews are deliberately non-destructive: looking at a related assignment does not mean silently editing it or abandoning unsaved changes on the current form.

This is the platform’s most important architectural choice. A message, quotation or calendar entry may reveal part of the booking, but none should casually overwrite the authoritative operational account. Core provides synchronisation and controlled updates around the Job Card so that the business can answer practical questions from a shared record: what was agreed, what has changed, who is responsible and what still needs attention?

The workspace improvements focus on actions that recur throughout the day. A sticky save control keeps saving accessible on long records. Related-record previews reduce navigation. Search, filters and saved views help users return to a useful worklist. The navigation drawer groups the broader feature set and includes search, favourites and keyboard-handling improvements.

Saved views are a convenience within the browser, scoped to the current user key. They are not presented as a cloud-synchronised team reporting system. This is typical of the implementation’s practical approach: provide a useful shortcut, but be clear about the behaviour it actually supplies.

Job templates can reuse service information, equipment summaries, required roles and crew numbers. Built-in starting points include operated inflatables, Events and AV hire, event crew, and collection and delivery. Template application fills empty fields rather than replacing an existing brief. Client identities, agreed prices, private notes and committed dates are deliberately excluded from reusable templates.

Date handling uses shared UK parsing and presentation. The interface offers explicit day/month/year entry, together with appropriate Today and Use job date shortcuts. Assignment defaults inherit relevant job information, and new or untouched fields can receive a sensible suggestion. Values that a user has deliberately changed should remain intact. Evidence dates, such as an actual certificate date, are not fabricated merely to make a form appear complete.

Changing an established job date has its own impact review. The interface identifies linked assignments and logistics records that may need attention before the reviewed date change is saved. This is not an automatic promise to move every downstream commitment. It is a prompt to consider the relationships that a date change affects.

The overall principle is to remove repetitive entry without removing judgement. One or two clicks is a useful target when the facts are already present. It is not a reason to bypass a confirmation, invent a missing expiry date or copy another customer’s details into a new job.

Availability is not represented as a single yes-or-no flag for the whole business. Core checks the requested booking period against relevant Job Cards, order commitments and connected calendar information. When valid start and finish times are available, the decision can be time-specific; where they are not, the checks take a more conservative date-based view.

Products have fulfilment policies. A sourceable service can be treated differently from an in-house-only service or a unique WD82 asset. An offering can also require manual confirmation. This matters for a contractor-style business: an existing diary commitment may prevent the owner from personally attending without proving that an approved subcontractor cannot fulfil the enquiry.

The shared engine returns distinct outcomes such as available, sourcing required, hard blocked and manual confirmation. A quotation may still be appropriate where payment or confirmation is not yet permitted. The interface can explain that capacity needs to be confirmed instead of describing uncertain availability as a firm booking.

Availability Manager exposes those policies to administrators and provides a date-and-service simulator using the same decision logic. This helps the business test exceptional products and understand why a result occurred. Lead-time rules and recorded overrides can influence the decision, but they do not replace the need for accurate commitments and properly maintained product policies.

Calendar features serve both administrators and account users. Jobs, assignments and transport information can appear in relevant views, with downloadable calendar entries and token-based subscription feeds. Crew can receive a calendar context drawn from their assignments rather than a generic event containing no useful title or location. The Assistant also has calendar-feed and manual-date support.

The distinction remains important: a calendar feed is a view of recorded commitments, not proof that another person’s diary has been updated instantly. Core brings these sources into one availability workflow, while the installed site’s feed freshness and scheduling configuration still determine how current the underlying information is.

Core distinguishes an organisation from the people who communicate on its behalf. A client record can contain multiple named contacts, while an individual job identifies the relevant booking contact. This supports commercial customers whose marketing, accounts and on-site teams have different responsibilities without turning each person into a disconnected version of the same company.

Identity resolution uses information such as email addresses, normalised telephone numbers and existing record relationships. The CRM can bring together associated orders, jobs, quotations and messages so that an administrator can inspect the wider customer context. A useful conversation should not depend on remembering which inbox originally received the enquiry.

The Source of Truth screen helps maintain those relationships. It identifies potential duplicate client pairs from exact-identity signals and provides a controlled merge workflow. The administrator reviews the suggested pair; Core does not treat a vaguely similar name as automatic permission to merge. Linked jobs and context can be relinked, missing information retained and the retired duplicate moved to Trash.

Historic quotation duplicates receive their own audit. The criteria consider the linked job, customer email, document type and total, rather than assuming that two similar document titles must be the same offer. This is particularly relevant after a system has evolved through several quotation and messaging implementations.

The benefit is a more coherent customer record, but identity matching is not the same as authorisation. Recognising that a message probably concerns a particular booking helps routing. It does not mean an anonymous visitor who knows the venue name should gain access to private correspondence or financial information. Core’s customer and administrative access checks remain separate from the process of finding a likely record.

The client account area gives the customer a view of their bookings and relevant supporting information. Navigation can include an overview, My Bookings, documents, messages and a calendar. Role-aware navigation also recognises that someone can be both a crew member and a customer, rather than forcing every account into a single permanent category.

Booking views connect the customer to their proposal and operational details. The portal supports controlled updates to logistics information, including fields such as parking, access and site notes. This gives the customer a practical way to contribute information without treating every edit as permission to rewrite the commercial agreement, booked venue or agreed working hours.

Customers can upload supporting documents through an authorised route. Documents can also be linked to jobs or relevant products, allowing the portal to present information associated with the actual booking. The document audience matters: a reusable operating document, a customer upload and a private freelancer invoice are different records with different reasons for access.

The platform also includes controlled photograph workflows. Photographs can be attached to relevant jobs or profiles through permission-checked handlers, rather than being treated as a public media free-for-all. This is useful for operational evidence and identity-related workflows, but publication remains a separate decision.

A major lesson from the development history is that a portal should not mirror the administrator’s entire job timeline. The office may need internal notifications, provider errors, monitoring copies and crew payment context. The customer generally needs their own correspondence and the operational information they are authorised to see. Core’s portal message layer makes that separation explicit, so a shared job reference is not by itself sufficient reason to disclose every associated message.

Freelancer recruitment begins with a dedicated application route. Core provides a front-end registration form and a button-led Assistant journey that collects structured information directly into the application system. This avoids relying on an AI conversation to interpret every applicant’s details or decide whether they should immediately become an active worker.

The application and worker record serve different purposes. An application gathers interest for review; the workforce record supports people who may be allocated work. Administrators can manage readiness, worker type, contact details, availability, travel limits and operational capabilities. Account provisioning connects the worker to the relevant portal functions.

The capability matrix covers roles and skills alongside practical constraints such as transport and licences. This is more useful than a single label saying someone is available. A person may be capable of a role but not ready for allocation, outside their preferred travel range or already committed elsewhere. Core provides places to record those distinctions so that matching can use more than a name in a contact list.

Onboarding supports protected document uploads and a profile photograph. Document categories include driving licence, insurance, trade-specific insurance, DBS, right-to-work evidence, first aid, training or competency certificates, trade qualifications and other accreditation. These are record types available to the business; their presence does not certify that a document is authentic, current or legally sufficient for a particular assignment.

The portal explains which information is required and what has been supplied. Payment information is connected to assignment invoicing rather than indiscriminately requested during onboarding. Accreditation has separate consent and visibility controls. The result is a workforce record designed for allocation and evidence management, while keeping employment, competence and document verification decisions with the people responsible for them.

Core can compare a job’s requirements with workforce information and produce candidate matches. Readiness, roles, structured capabilities, availability, travel limits and clashes contribute to the decision. The system helps identify suitable people; it does not imply that a calculated match is a substitute for checking competence, agreeing the scope or confirming that the person will attend.

Assignments give the relationship a concrete form. They can carry the worker, job, role, dates, call and finish times, fee, vehicle arrangement, mileage and notes. Relevant values can inherit from the job, reducing repeated entry. An assignment can then move through an offer and response workflow, rather than treating a draft allocation as an accepted commitment.

The crew workflow supplies direct accept, decline and authorised administration controls. It uses transition safeguards and response history so repeated clicks or conflicting states do not casually produce additional offers. Status and delivery information are presented separately: an offer may have been submitted to a messaging provider without proving that the worker has accepted it.

The Job Board adds a recruitment route for open opportunities. It supports fixed-fee and private-bid work, eligibility checks, closing and reopening, expiry and validation of bids. Applicants do not need to see competing bids or other people’s private applications. Selecting a candidate creates the normal assignment workflow rather than a parallel form of booking.

Multi-person vacancies are handled as capacity, not merely as an open-or-closed advertisement. Active assignments are counted against the number of crew required, remaining places can stay available and a decline or cancellation can reopen capacity. This suits jobs where several people are needed across different duties or dates. The business can recruit towards the actual requirement while preserving a private, traceable record of each person’s involvement.

The Crew Portal gives workers a view of the work relevant to them. Assignment cards present the role, job context, timing and response controls, with a distinction between event work and transport-only duties. A person collecting equipment should not receive an event-day brief that implies they must also remain at the venue for the activation.

The portal also connects operational progress with invoicing. Freelancers and subcontractors can upload an invoice against an assignment, and the payment state explains what happens next. The system distinguishes an offer awaiting response, work not yet completed, an invoice required, an invoice received, a payment scheduled, a payment on hold and a payment recorded as paid.

Early invoice submission is supported. Receiving an invoice before the work is complete does not automatically start the payment clock. The interface can explain that the invoice is already on file while the operational completion condition remains outstanding. This reduces repeated chasing without pretending that uploading a document is the same as approving or paying it.

The implementation includes five-working-day calculations and an England-and-Wales bank-holiday model, with a way to add exceptional dates. These are business workflow rules within Core, not a universal statement of the payment terms applying to every worker or jurisdiction. Administrators still need to maintain the relevant records and verify the resulting due date against the actual agreement.

Invoices are served through protected access routes and retained as assignment-related evidence. Crew Payments provides an administration view of due and overdue liabilities, while finance reconciliation supports recording the eventual payment. The value is visibility for both sides: the worker can see the stage of the process, and the administrator can distinguish missing paperwork from an approved obligation that now needs settlement.

The logistics module models collection and delivery as first-class operational tasks. A transport record can describe the items, collection stop, delivery stop, dates, time windows, contacts and instructions, together with the driver assignment. Suppliers and handover locations can be maintained instead of hidden inside an unstructured job note.

A transport assignment is deliberately distinguishable from an event assignment. The driver can be offered a specific movement with its own fee and itinerary. That is particularly useful when a job involves one person collecting equipment, another team delivering the event and a later return to the supplier. Each participant needs the right scope, not a compressed version of the entire project.

The module validates details and lifecycle changes, records an audit and supplies portal views. Driver progress can record leaving for collection, arrival, collection, travel towards delivery, arrival at delivery and completion. The resulting history can answer a customer’s collection question from actual transport events rather than from an AI model’s guess about what probably happened.

Notifications are also tied to logistics state. Collection and delivery contacts can receive information appropriate to their stop, while the customer can receive a progress link. Queued notices are checked against the current context so a superseded itinerary is not knowingly sent as though it were still current. The system records dispatch attempts separately from the progress event that prompted them.

The practical benefit is a better handover. A driver sees where to go, who to contact and what is moving. The office sees the assignment and transport status. The customer sees the relevant progress without receiving private driver payment information or every supplier’s message. Logistics is therefore not merely a calendar annotation: it is a connected workflow with responsibilities, state, communication and evidence.

Core’s live job controls give an authorised operator a simple sequence of operational stages: Leaving now, Arrived, Setting up, Ready, Finished and Departed. Selecting a stage records a timestamp and updates the displayed progress. This turns an ordinary operational update into information the wider workflow can use.

The controls are associated with the Job Card and the operator’s relationship to it. They are not a public status editor. The implementation checks access and the permitted progression so that unrelated visitors cannot update another team’s job or create an arbitrary sequence of stages.

Notifications are configurable for customer and administrator channels. Not every stage needs to generate every possible message. For example, the system can distinguish a useful customer milestone from an internal preparation step. This allows an operation to provide reassurance without creating a stream of low-value alerts each time someone touches a button.

Expected-time warnings and status presentation help identify where attention may be needed. They should be understood as comparisons with recorded expectations, not a guarantee that the person is physically at the reported location. The underlying action is an operator-reported stage update with an automatic timestamp.

The supplied implementation does not establish continuous GPS tracking or an embedded live traffic map. A manually reported milestone, a recorded ETA and a calendar commitment are different kinds of information from real-time location telemetry. Keeping those distinctions clear prevents a useful feature from being oversold.

For a small operator, the immediate value is straightforward. Instead of calling the office merely to say that setup is complete, the operator can update the job in place. The customer-facing view and any enabled notifications can then reflect the recorded milestone, while the office retains the history for later review.

Accreditation is a specialised output, not a reason to expose the full workforce database. Core can generate a job-specific crew and vehicle accreditation pack from the relevant assignments. It draws on recorded accreditation names, roles, photographs and references, and can include allocated vehicle details where they are present.

A crew member’s accreditation-export consent is a separate control. Where consent is not recorded, the pack withholds that person’s profile rather than assuming that being assigned to a job authorises every possible disclosure. The generation event is logged, providing an administration record of the pack being opened.

The newer document controls also allow individual uploaded documents to be marked for inclusion on accreditation. Driving licences, insurance, DBS and other evidence are not simply bundled together because they exist. Each document has its own visibility setting, and the worker’s broader accreditation consent remains relevant. This creates a more deliberate sharing process than exporting an entire profile folder.

The pack is designed for a restricted operational purpose such as venue access or security checks. Private contact details, pay and banking information do not belong in that presentation. Protected document links also remain protected links; printing or exporting the pack is not a universal grant of account access to its recipients.

The feature therefore solves two related problems. It reduces the time needed to assemble a coherent set of job-specific accreditation information, and it makes the boundaries of that set more explicit. An administrator still needs to check what the recipient genuinely requires, whether the evidence is appropriate and how the exported material will be handled. Core supplies the controlled assembly and record relationships; it does not certify compliance merely by generating a document.

The Messaging Centre brings email, SMS and WhatsApp into a shared administration workspace. Conversations can be associated with customer or crew identities, while channel labels preserve the origin and destination of each message. The purpose is to let an administrator understand the thread without opening three separate inboxes and manually comparing timestamps.

The overview supports filtering, search, unread state and conversation-level access. Messages can be linked to source records and jobs, and proposed Job Card updates can be reviewed from the conversation. The interface also includes human takeover, allowing AI handling to be paused for a particular thread while a person deals with the customer directly.

The composer makes the selected channel explicit. The visible pill, recipient and sending control should agree, including when the user leaves the initial default untouched. Send WhatsApp, Send SMS and Send Email communicate the action more clearly than a generic Send message button. The server handlers validate the selected route rather than treating an ambiguous form as permission to broadcast through multiple channels.

A failed attempt does not justify silently changing the channel. That would change the customer’s experience, potentially incur another charge and make the message history harder to understand. Core retains the chosen route and separates failure handling from a deliberate decision to send another message through another channel.

Conversation context is also more than a chronological list. The associated job, identity and operational data can inform an appropriate update or response. Recognised booking communications can be routed to the booking handler before the sales journey. The aim is to answer a question about an existing collection or append a parking instruction without responding with an unrelated catalogue menu. That improvement depends on authorised matching and an actual saved result, not just more fluent wording.

Core contains a two-way email workflow using configured mailbox access and outbound transport. It can collect incoming messages, retain them in its message records, show them in the inbox and support direct replies. Mailbox tools provide testing, processing and other administration controls, while scheduled intake avoids opening a mailbox connection during every ordinary page view.

Incoming attachments are handled as private operational material. The code includes attachment description, validation, size and type checks, protected storage and permission-checked retrieval. Financial attachments can enter invoice-extraction and expense-related workflows. Extracting proposed invoice information is not the same as authorising a payment or accepting every value as correct.

AI email handling is deliberately approval-only in the supplied implementation. The system can analyse, research and draft, but the drafting path does not automatically send the response. An administrator can inspect the proposed wording and use the appropriate sending action after checking the current facts. This is particularly important where a message could commit the business to completing a form, sharing personal details or changing an agreement.

Loop prevention considers internal addresses and incoming messages that appear to be part of WD82’s own mail cycle. Historic imports are treated differently from new correspondence, reducing the risk of replying automatically to an old conversation merely because it has been collected for the first time. Sender bypass and sending-policy controls provide further administration boundaries.

The thread context and writing policy are intended to improve relevance. A good reply should answer the latest question, avoid asking for known information again and use a practical alternative when the matter genuinely needs a different route. Internal provider commentary does not belong in ordinary customer copy. Core retains the technical delivery record for the administrator while keeping the proposed customer response focused on the customer’s actual need.

Messaging reliability depends on distinguishing several events. Core may have queued a message, submitted it to a provider, received provider acceptance or received a later delivery or read callback. Those states are not interchangeable. The delivery monitor and message records retain the distinction so that a submission is not described as successful handset delivery without supporting information.

SMS quiet hours are enforced around the UK sending window. The supplied workflow submits eligible SMS during 08:00–17:00 Europe/London and holds it outside that window for the next opening. A queued item can therefore exist before it has been submitted. The record should explain that state rather than implying that the customer already received it.

The self-number guard addresses a concrete configuration failure: a message whose recipient is the same as the configured sending number is blocked before provider submission. Administrator monitoring copies have separate handling, so an invalid monitoring destination does not become an endless source of attempted self-sends. Internal copies are not intended to appear in the customer or crew correspondence view.

Retry policy distinguishes terminal failures from temporary problems. The source includes a finite retry decision and holds uncertain operations for review rather than treating every failure as permission to send again. Deduplication and operation guards further reduce repeated submissions. Restoring a trashed job or recovering an interrupted interface should not automatically replay messages that were deliberately stopped.

WhatsApp has its own sending-window and template workflow. Core can inspect the free-text reply window, manage its required content templates, submit them for approval and check their actual approval state. Configuration in Core does not remove the provider’s requirements. The application also applies per-contact automated-reply limits and honours conversation takeover. Together, these controls aim to keep automation useful without allowing a minor configuration error or a repeated incoming message to generate an uncontrolled conversation loop.

The message-visibility layer enforces a narrower rule than job membership: account users should see correspondence they sent or received, not every message attached to the same operation. A client and a driver may share a Job Card relationship while having no legitimate reason to read each other’s private messages.

Core’s portal filtering excludes internal notifications, administrator monitoring copies and unsent drafts from the ordinary account correspondence view. This applies when rendering historical messages as well as new ones. A provider error linked to a job is still an internal diagnostic, and a worker’s payment discussion is still not a customer update.

Document access follows a related but separate model. Records can be classified for customer, crew, public or specifically private audiences, with checks against the account and linked party. The private-storage implementation expects a verified writable location outside the detected public website root. Where that requirement cannot be met, the system reports a configuration problem rather than quietly falling back to ordinary public uploads.

Legacy private-file migration is handled in bounded steps. The source describes copying, checksum verification, metadata verification and only then removal of the old public source. This is a data-handling mechanism, not evidence that every installation has already completed its migration. The health view exists to make the remaining configuration and migration position visible.

These controls are part of the platform’s privacy design, but they are not an independent security certification. Account permissions, hosting, shared caches and the configuration of other plugins also matter. The case-study point is the deliberate boundary: operational convenience must not mean that a client portal becomes an unfiltered window into the office, and a shared booking must not erase each participant’s separate identity.

The Operations Centre turns records and communications into a prioritised action view. Rather than asking the administrator to infer every outstanding task from a collection of inboxes, it can surface messages needing a reply, delivery issues, job readiness and other operational conditions. The underlying source records remain available for inspection.

Action state can be managed with ownership, deadlines, snoozing and internal notes. A user can assign work to themselves, mark a matter reviewed, record that they are waiting for the client or defer it until an appropriate time. Those administration notes are not automatically sent to the contact. This is important because a reminder about a conversation is not itself another customer message.

The workspace keeps automatic facts separate from saved action decisions. For example, a message can remain part of the history while its action state changes from needs attention to waiting. This helps prevent the inbox from becoming the only task-management system, where reading a message is incorrectly treated as finishing the work it requested.

Core also contains scheduled communication workflows, including crew reminders, proposal follow-ups and customer follow-ups. The quotation and job state can stop those sequences when continuing them would be inappropriate. The Automation and Activity views provide a record of the events rather than asking the administrator to trust that every scheduled task happened invisibly.

Daily Operations adds Start of Play and Close of Play reporting, with configurable timing and optional report delivery. Reports can include upcoming work, communications diagnostics and outstanding roadmap items. Email diagnostics are designed to check readiness without creating another self-addressed test conversation; an SMS diagnostic is a separate optional action. This supports a repeatable operational handover while retaining a clear distinction between a health check, a reminder and a message actually sent to a customer.

Core connects job costing with customer and supplier money, but it does not replace WooCommerce’s order system or a full accounting platform. Its finance views distinguish commercial value, recorded payments, refunds, outstanding customer amounts and outgoing obligations. This is more useful than treating every confirmed job as money already in the bank.

The Job Card can present a payment summary using linked order information and the recorded payment ledger. Administrators can record actual payments through a controlled form, with an appropriate current-date suggestion for a new entry. Invoice preparation is a separate process: an accepted proposal on a confirmed job can be used to prepare a pending WooCommerce invoice from its frozen commercial snapshot.

Preparation and sending are approval-gated actions. The implementation checks line values, tax, delivery, fees, customer details and totals against the snapshot, and uses locks and recovery checks to avoid creating another invoice simply because a request is repeated. Sending the invoice is then a distinct tracked action. An approval should not be reusable against a materially changed commercial record.

Outgoing finance includes expenses, purchases, crew fees, mileage and sourcing costs. Crew Payments focuses on invoice and payment progress, while Finance Reconciliation supports review and recording settlement. Period exports and Xero-compatible bank-statement CSV output provide a manual hand-off; the source does not establish a live bank feed or automatic posting into an accounting account.

Profitability and Management Information bring together pipeline and operational measures such as revenue, calculated gross profit, margin, quote conversion, upcoming jobs and workforce readiness. These figures depend on the records and cost categories actually included. They are not automatically audited accounts or a complete measure of business net profit. Their value is managerial: they help reveal whether recorded work, costs and outstanding obligations are moving in a commercially sensible direction.

A contractor-style business needs a way to fulfil work that is not covered by its own equipment or personnel. Core’s supplier network and sourcing records provide that connection. A sourcing requirement can be linked to a job and describe the service, date and location, with candidate research and commercial information retained alongside it.

The research workflow can use configured external services, including Google Places and AI-assisted web research. It presents candidate businesses and supporting reasons for review. Adding a researched company as a candidate supplier does not mean its suitability, availability, insurance or final price has been verified. The distinction between discovery and approval remains important.

Sourcing settings support different markup categories, including simple pass-through work, managed subcontracting and higher-risk or bespoke work, together with a minimum management fee. Core can show supplier cost, proposed selling price and calculated margin. This makes the commercial treatment of external fulfilment explicit rather than allowing supplier cost to pass through without considering management responsibility.

The sourcing workflow also relates to availability. A diary clash for a sourceable offering can lead towards a sourcing requirement instead of an immediate claim that the whole business is unavailable. That route should still retain the need for capacity confirmation before a customer is allowed to treat the booking as guaranteed.

The case illustrates how breadth can be managed without pretending that WD82 owns every capability in the catalogue. The system provides records for the requirement, research, candidate and commercial position. People still approve the supplier and the commitment. This is a more credible operational model than allowing a website to promise delivery merely because it can generate a plausible description of the requested service.

The platform exposes defined tools and interfaces for authorised integrations. Its MCP implementation separates public, customer and administrative capabilities. Public catalogue access is not the same as access to private jobs, and a customer-safe credential is not intended to unlock the administrator’s client list, expenses or message history.

Customer tools have guards around the quotation and account context. Administrative tools can read and act on supported records through the Core interface, with permission checks and configurable action controls. OAuth support provides scoped access for approved external clients, while the internal Assistant has its own execution route. The presence of these interfaces does not automatically connect an external AI application; authorisation and configuration are still required.

Supported administration actions include creating or updating selected record types, working with assignments and requesting invoice-related actions. Sensitive fields receive special treatment. Status, revenue, contact changes, crew fees, assignment ownership and verification flags can carry consequences beyond a simple text edit, so the implementation can route those changes through approval rather than accepting a model’s request as final authority.

The Approval Centre is therefore part of the tool architecture, not merely an inbox for suggested wording. It holds a defined action and payload for an authorised decision. Payload hashes, stale-state checks and execution records help connect the approval to the specific proposed operation. A general conversation about preparing an invoice should not become permission to send a different one later.

The underlying principle is that AI may identify an action, but the software controls whether that action is permitted and how it is executed. The tool receives structured fields, runs the relevant checks and returns a result. The final wording should follow that result. This is how a system can move beyond polite suggestions while avoiding the equally unhelpful extreme of giving a conversational model unrestricted access to business records.

Some customer requests need more than one step: retrieve a product, check a period, prepare a quotation and return the result. Core’s embedded Assistant supports a resumable execution model for this interactive work. The browser starts a request with an identity, and authenticated continuation phases advance the operation instead of repeatedly submitting the original request.

The interface displays progress and provides a Stop this request control. If a response is lost, the browser can check the existing request’s state rather than creating a new booking action. Hidden tabs pause advancement, and persistent connection problems expose a deliberate recovery control. This is a more useful response than leaving the visitor with an indefinite spinner or encouraging them to click repeatedly.

The supplied implementation sets explicit limits: a website turn has an overall budget of 180 seconds, with phase and tool-count limits and shorter individual provider-request budgets. SMS, WhatsApp and email research use a bounded synchronous route. These are application limits, not promises about how quickly an external AI provider will answer.

Mutating tool operations have receipts. The system records the intended action before execution and stores the returned result afterwards. Repeated equivalent writes can reuse recorded outcomes, while interrupted or uncertain writes are held for review rather than blindly repeated. This helps distinguish a slow screen from an operation that genuinely did not happen.

Cancellation also has an honest boundary. Stopping the remaining phases does not reverse a change that was already completed. The implementation preserves that distinction in its recovery and response handling. Core is not claiming a universal exactly-once guarantee across every external system; it provides bounded work, request identity and explicit uncertainty handling so that interrupted AI activity is less likely to become duplicate business activity.

Core’s shared writing policy asks for natural UK English, the correct trading identity, relevant authorised facts and a direct answer to the latest question. It rejects invented commitments and unsupported statements that a booking has been updated, a message sent or a task completed. Sending and business operations remain separate from text generation.

The deterministic checks look for specific problems such as unresolved placeholders, unsupported amounts, dates absent from the supplied context, unrecognised links, unsuitable provider commentary and action claims without an execution receipt. Channel-specific checks flag inappropriate Markdown and excessive message length. The checks are useful review signals, not proof that a fluent answer is factually correct in every respect.

The Copy quality workbench adds two distinct activities. An administrator can compare an original message with an edited version, retain notes and mark an approved example without overwriting the source message or sending anything. This private review stays separate from the live communication workflow, making it possible to improve wording without changing the historical record.

The second activity runs the configured model against twenty synthetic scenarios. The workbench records the response, model, timing, usage information and automated warnings, with human review tracked separately. The generation path has no customer-sending tools. It provides a repeatable way to inspect how the configured model handles representative situations without using a real customer as the test recipient.

That distinction prevents misleading quality claims. The presence of an evaluation screen does not mean every scenario has passed on the installed website. Reviewing supplied historical replies is also not the same as generating fresh output after an upgrade. The case-study contribution is the working quality process: clearer instructions, targeted checks, retained edits and a deliberate place to evaluate real model behaviour before relying on it operationally.

The Knowledge Centre gives the business a place to maintain information that should inform replies and operational decisions. Knowledge items can hold categories, keywords, product relationships and practical fields such as packed weight, dimensions, transport, setup and power. This is more useful than asking an assistant to infer technical requirements from marketing copy alone.

Knowledge also has provenance. The supplied records support a source, source URL, verification state, owner, reviewed date and review-due date. Overdue review can be surfaced, and CSV import and export help move structured information in and out. A knowledge entry can therefore be maintained as a business asset rather than treated as a timeless statement once somebody has typed it.

Email, SMS and MCP paths can draw on relevant knowledge. The purpose is to ground a reply in approved operational facts, while recognising that unverified or incomplete records should not be promoted into certainty. A stored dimension may help answer a transport question, but it still needs to belong to the right item and reflect the current configuration.

The AI Director provides a separate administration-facing analysis tool. Its interface supports a general director-style question and a legal or compliance issue-spotting mode, using a selected snapshot of operational data. It can help an administrator consider a decision in the context of recorded jobs, workforce, quotes and marketing activity.

This is advisory analysis, not an autonomous director, lawyer or accountant. Its context is a selected set of records rather than an exhaustive real-time account of every part of the company. The value is in bringing relevant business information into a structured discussion while leaving the decision and any resulting action with an authorised person. Core keeps analysis distinct from the approval and execution pathways that make actual changes.

The marketing features connect the operating platform with the website’s editorial activity. Core has a Marketing Seeds library, planning tools, a queue and scheduling controls. An administrator can generate a plan, create draft posts from planned items, review or refresh them and manage publication slots. Duplicate-slot cleanup reduces the risk of repeatedly creating competing posts for the same planned position.

Generated articles are connected to existing classifications and relevant catalogue content. The implementation can add allow-listed internal links and, where supported, a verified first-party external source. It includes content-cleaning and link-validation routines rather than relying on the writer to invent a credible-looking URL. This helps keep articles useful to the site’s actual service structure.

Post-event content is a separate workflow tied to completed jobs. It can move through pending generation, draft creation, review and publication, with status visible to the administrator. Crucially, the current public-content payload is built from approved public facts rather than the job’s private operational notes. Naming the saved venue requires a separate publication decision, and leaving the approved facts blank prevents automatic drafting for that job.

This makes operational completion different from publication permission. A finished job may contain sensitive contact details, access instructions, private commercial information or photographs that are unsuitable for public use. Core does not need to send those fields to the writing model simply to explain the service. Linked published products and approved facts provide a more controlled basis for the article.

Visual generation and branding can support the planned content, while a Blog2Social integration provides authentication, account refresh and publishing functions where that service is configured. An available integration is not evidence that a particular social account is connected or that a post has already appeared there.

The practical outcome is a managed route from genuine capability and completed work to editorial output. It encourages reuse of verified information without treating every job as permission to publish a client case study, and without claiming that automated publication eliminates the need for an editor.

The performance work focuses on repeated costs rather than cosmetic speed claims. The Messaging Centre’s overview was changed from per-conversation querying to batched retrieval. The recorded local comparison for a full thirty-thread overview reduced that method path from up to sixty-five SELECT queries to five, with equivalent results in the tested fixtures. That is a query-count result, not a measurement of total live page speed.

Frontend styles were also separated. Ordinary public pages use a smaller bundle, while account and crew components receive the relevant account styles. The recorded public bundle was 45.9 per cent smaller by raw file size than the previous global stylesheet. The implementation preserves source order and includes detection for supported shortcodes, account routes, Elementor content and late-rendered components. File size alone does not establish the percentage improvement in loading time.

Polling controls reduce unnecessary work in hidden tabs, and activity polling includes coordination and bounded request handling. List and finance-query improvements address unbounded retrieval and totals that previously depended on a displayed slice. These changes improve particular paths; they should not be described as proof that every historical query in the plugin is now optimised for unlimited scale.

Diagnostics cover operational readiness, communications, private storage, scheduled work and integration configuration. The Roadmap distinguishes code present from features still dependent on configuration or live verification. Start and Close reports can surface outstanding areas rather than hiding them behind a general green status.

Maintenance also includes operational exports and validation, plus places to record evidence of backups, off-site copies, staging and restore checks. These are not substitutes for a hosting backup service or an actual restore rehearsal. The system can preserve and inspect evidence; it cannot guarantee that an external backup exists because a setting says it should.

The v0.59.2 release notes report 209 passing local test invocations across syntax, source contracts, runtime fixtures and browser suites. Those tests use synthetic records and controlled providers. They support the supplied package’s regression record, while leaving live configuration, customer-provider delivery and performance under real traffic as separate deployment checks.

Testing creates records that should not remain mixed into live work indefinitely. Earlier test cleanup depended on an explicit test marker or title prefix, which did not help with older unflagged Job Cards. The v0.59.2 interface puts selection controls on the actual Jobs table, including individual checkboxes and current-page select-all.

Selected jobs can be reviewed and moved to Trash as a batch. The action is not a hidden permanent deletion. The preview identifies the records, and confirmation rechecks permissions, eligibility and important fields so that a changed record can be skipped for fresh review. Batches are limited rather than allowing an unlimited operation to run in one request.

The everyday bulk action moves Job Cards only. Customers, workforce profiles, messages, quotations, orders, payments, expenses, assignments and transport records are preserved. This matters because removing a test-looking job must not silently cancel a crew commitment, erase an invoice or destroy the evidence of a real conversation. Linked records may remain visible in their own workspaces.

An Undo this batch action restores jobs to their previous saved statuses while they remain recoverable in Trash. It does not resend messages or requeue stopped SMS. The operation refuses to substitute permanent deletion when WordPress Trash is disabled. Recorded receipts and processing locks support recovery from repeated or interrupted submissions.

The release also contains an exact-reference shortcut for a specifically reviewed historical set, with identified genuine jobs protected. That is a targeted cleanup aid, not a claim that Core can reliably classify every job as genuine or test from a person’s name. Quotation synchronisation recognises deliberately removed jobs, and queued SMS linked to a trashed job is stopped before provider submission. These controls close the loop around removal instead of letting background processes immediately recreate the clutter.

Consider an illustrative booking for an operated inflatable at an event. The customer needs equipment collected from a supplier, an event-day team and a later return. The following journey demonstrates how the features can work together; it is not a report of a completed client project, an actual quotation or a measured operational result.

The customer begins with the website catalogue or Assistant. They describe the service, location and required date, and the quotation journey gathers the remaining facts. Product policies identify that the item requires operation rather than an ordinary dry-hire transaction. Availability considers the requested period and the relevant fulfilment policy. Where external capacity is needed, the record can remain subject to sourcing rather than offering unrestricted checkout.

A saved quotation creates the commercial record and reserves a Proposal-stage Job. The administrator can review the scope, confirm which terms modules apply and send the appropriate proposal. The customer’s acceptance is linked to that offer. Invoice preparation can then follow the approved commercial snapshot rather than copying an amount from an old message and hoping it still matches.

The client organisation has a named booking contact. Crew requirements are recorded on the Job Card, and suitable workers can be considered through the capability matrix. Offers carry the role, date, fee and timings. Where another person is needed, the Job Board can retain the remaining vacancy instead of closing simply because the first worker accepted.

Collection is created as a transport task with its own stops, item list and driver assignment. The driver receives the transport itinerary rather than an event-duty brief. Progress records can show arrival, collection and delivery. If the customer later asks whether collection happened, the authorised booking-conversation route has an actual transport history to consult.

A parking update arrives through WhatsApp. The sender’s recognised relationship and the job context help route it, but the relevant authorisation checks still apply. Parking details are appended to the appropriate operational information. A parking-location address is not automatically substituted for the event venue, and the car park’s opening hours are not treated as newly agreed working times. The reply should confirm only the change that was actually saved.

Before the event, accreditation information can be assembled from consenting assigned crew and specifically shared documents. The customer portal shows appropriate booking information, documents and the customer’s own messages. It does not include another applicant’s decline notification, the driver’s private fee or an administrator’s monitoring copy.

On the day, the authorised operator updates the job stages. Enabled notifications and the progress view reflect those recorded milestones. After completion, invoices and payments follow their own states. Finally, the administrator may approve public facts for a post-event article, which enters the editorial review workflow. The same connected job supports each stage, but commercial approval, operational progress, private evidence and publication permission remain distinct decisions throughout.

WD82 Core demonstrates the value of designing a website around the work that follows an enquiry. Catalogue, commerce, customer contact, staffing, transport and finance are not unrelated plugins from the user’s point of view. They are successive parts of delivering a service. The platform’s central contribution is to connect those parts while giving each participant a suitable view.

Its automation is most credible where it removes repetition: carrying forward known details, inheriting dates, retrieving the correct thread, creating a structured offer, preparing an approved invoice or recording a milestone. Its safeguards are most valuable where a shortcut could have consequences: sending externally, changing a commercial state, disclosing a document, repeating an uncertain operation or moving records to Trash.

The AI features follow the same distinction. Language generation helps interpret and explain, while defined tools and permission checks govern actual business actions. Copy review, synthetic evaluations and action receipts make quality more inspectable. None of those controls should be confused with a guarantee that every model output is correct or that a website has passed every possible security and reliability test.

There is no independently measured time-saving, revenue-growth or conversion uplift claimed in this case study. The supplied evidence supports the implemented workflows and specific local test results, not a fictional return-on-investment figure. A live operational evaluation would need a baseline, a defined period and records of the tasks being compared.

The business also retains responsibility for source data, pricing, competent people, valid permissions and provider configuration. A useful system makes those responsibilities easier to fulfil; it does not make them disappear. That is the substantive result of the WD82 Core approach: a connected, inspectable operating environment in which the website is part of delivery, the Job Card holds the operational account, and everyday work can move forward without repeatedly reconstructing the same information.