How it works
The whole path, from a blank request to a delivered event
Procurement records are transactional and governed, not documents. Every request moves through an explicit set of states, and each transition is recorded.
- 01
Request
Build an event-native brief: dates, venue, delivery windows, lots, specifications and required documents.
- 02
Source
Invite suppliers from an approved panel, the wider network, or by controlled external invitation.
- 03
Compare
Read normalised offers side by side at total, lot and line-item level, with exclusions and options visible.
- 04
Approve
Route the decision by value, category and department. Comments and decisions are recorded as they happen.
- 05
Award
Award a whole request, selected lots or partial quantities. Award and decline notices go out from the record.
- 06
Hand off
Produce an operational record with final scope, timeline, contacts and documents for the delivery team.
Buyer side
What you do
- Create a request from a template or a blank form.
- Add event context, location, dates, delivery windows and procurement lots.
- Add the technical specification, commercial context, required documents and evaluation criteria.
- Select suppliers from your approved panel, the network, or by controlled external invitation.
- Route internally for issue approval where your policy requires it.
- Issue the request and handle supplier questions in one centralised clarification thread.
- Receive structured submissions by the deadline.
- Compare offers at total, lot and line-item level.
- Score non-price criteria and record the recommendation.
- Route for commercial and governance approval.
- Award the whole request, selected lots, or partial quantities.
- Send award and decline notices from the record.
- Generate the operational handoff: final scope, timeline, contacts, documents, responsibilities.
- Capture post-event supplier evaluation and close the record.
Supplier side
What they see
- Receive an invitation email and a secure portal link.
- Create an account or sign in.
- Complete the minimum profile and required compliance fields.
- Confirm interest, or decline with a reason.
- Read the brief, download files, and submit clarification questions.
- Build a quote using structured line items, options, exclusions, VAT and terms.
- Submit before the deadline.
- Receive status updates as the process moves.
- If awarded, accept and complete handoff information.
- After delivery, receive performance feedback where the buyer’s policy permits it.
Request lifecycle
Explicit states, not a status field somebody types into
A request is always in exactly one of these states, and the workflow controls which transitions are legal. No application bug can put a request into a state that does not exist.
Additional states cover the situations events actually produce: cancelled, paused, reopened, expired, supplier disqualified and award withdrawn.
Clarifications
Questions handled fairly, and provably so
In a competitive process, who knew what and when is a fairness question. Clarifications are categorised so that answering one supplier does not quietly advantage them.
| Type | Who sees it |
|---|---|
| Buyer to all | An answer every invited supplier sees, so nobody gains an information advantage. |
| Buyer to one | A response to a single supplier where the question is specific to them. |
| Supplier private | A question a supplier asks without other bidders seeing that it was asked. |
| Internal only | Buyer-side discussion that no supplier ever sees. |
Run your next event sourcing round in one place
We are onboarding a small number of design partner buyers and their existing supplier panels. If you buy event services regularly, a pilot starts with one real request.