Digital processes for different business models.

In the HIJIR project, a customer record connects quotations, invoices and receipts. Travel dates, party size, room options and extras form the quotation. The invoice is derived from it; recorded instalments and the outstanding balance remain part of the same transaction.

The transferable pattern is the relationship between documents. Each processing stage carries the required information forward, while the customer record keeps its history accessible. Search, filters and an enquiry inbox support day-to-day work.

For another business, start with its document types and amendment rules: what may change after approval, who confirms a payment and how a correction becomes visible. The pattern offers a starting point for processes with several document stages.

• More documented company projects

The Sunnah connects prospects, customers and appointments. A booking moves through creation, confirmation, completion or cancellation. Staff and time slots belong to outlets; the application also accounts for absence and cover from another location.

Commission calculations use defined bases. Membership and referral terms are recorded with the transaction. This makes it possible to identify which terms underlie a calculation.

A similar process starts with the organisation's own capacity and remuneration rules. Questions include outlet transfers, cancellations, discounts and responsibility for corrections. A shared appointment list alone does not answer them.

A directory application includes a form builder with different field types and validation. New or amended information is first retained as a submission. The responsible role reviews it and applies the approved version to the directory.

The submission and the currently published record remain separate states. This helps when form fields change or an existing contributor updates only part of a record. A public submission form also directs suggestions into an internal inbox.

This pattern fits directories, application processes and master-data maintenance. Before implementation, define required information, approval rules and the treatment of rejected, corrected or deleted submissions. A new form version must not silently change earlier decisions.

• Workflows with business approvals

Demonstrations: Two designs for visitor attractions show date, time-slot and party-size selection followed by booking details. An administration view displays bookings and available capacity. The design allows daily quotas and prices to be configured.

A business can use this to discuss the path from an available slot to confirmation. The demonstration presents the interface with a prepared dataset. It provides no evidence of tickets actually sold or production handling of simultaneous bookings.

Implementation adds capacity rules, reservation duration, payment, cancellation and behaviour after a lost connection. Two requests for the last available place make a useful acceptance case.

Demonstration and defined proposal scope: An internal knowledge assistant searches maintained entries and displays a matching answer with a document and section reference. If no suitable match exists, it returns the question as unanswered. The editing interface requires a source reference for each entry.

The reviewed demonstration uses weighted keyword search. The subsequent proposal describes retrieval of stored answers and excludes newly generated language-model responses. This defines the scope more precisely than the word chatbot alone.

For a business, the first decision is whether to retrieve approved answers or generate new responses from several document passages. That choice determines the checks for source maintenance, access permissions and questions outside the knowledge collection.

• Choose the right knowledge-management approach
• AI chatbot for companies