Commissioning guide
A concise working guide to process, responsibilities, change control, handover and the boundaries that belong in the final agreement.
Guide · 01
This page is a planning aid, not a fixed package sheet or contract. Starting prices, typical ranges and indicative cadences support early qualification. The signed proposal controls the actual deliverables, schedule, responsibilities, revision structure, ownership and payment terms.
Discuss a project01 · Engagement reference
The four ways to commission Rivenhall, their current starting investments and indicative cadences live on the Engagements page. This guide explains how the selected engagement is governed.
02 · Process
The proposal names stage outputs, dependencies and approval points. The complete six-stage studio process is maintained on the Studio page rather than repeated here.
03 · Responsibilities
Responsibilities are assigned project by project. These are the categories a serious proposal should resolve rather than universal promises about every commission.
Useful before the first scope call
The commercial objective, current constraint and decision the project must make easier.
A named decision-maker and a practical way to consolidate stakeholder feedback.
Existing brand, audience, analytics and product or service information that can be shared lawfully.
Available copy, catalogue data, photography and other source material, or a clear statement of what must be created.
Required platform accounts, credentials and technical access at the agreed stage.
Approval of claims, policies, pricing, product information and other client-controlled content.
04 · Revisions and changes
Rivenhall’s public pricing does not promise a universal number of revisions. The proposal should define review points, included development of the approved direction, who may approve and how additional scope is authorised.
Develops an agreed direction inside the approved objective and stated deliverable.
Handled at the review points and within the revision structure named in the proposal.
Brings delivered work into line with an agreed requirement or acceptance criterion.
Reviewed against the signed scope and resolved through the agreed quality process.
Adds a route, audience, integration, feature, platform condition or production requirement.
Impact on investment and schedule is stated and approved before the additional work proceeds.
05 · Ownership and handover
Ownership and transfer are controlled by the signed agreement. Before approval, the proposal should identify each of the following in language appropriate to the project.
Which approved assets, interfaces, templates, prototypes or production surfaces are delivered.
Which design files, code, repositories or production files are transferred or made accessible.
Who owns hosting, platform, analytics, domain and third-party accounts, and how access is handed over.
Which fonts, imagery, software, applications or components carry third-party terms or continuing fees.
What publishing, system, deployment or operational guidance is included for the agreed recipient.
When transfer occurs and which payment, approval or contractual conditions apply.
The duration and boundary of any correction window, maintenance or ongoing support.
For Prototype Sprint, what is demonstrably functional and what still requires production infrastructure.
06 · Common exclusions
The following should not be presumed included. A proposal may include any of them; the safeguard is that it says so explicitly.
Hosting, platform subscriptions, applications, fonts, stock assets, domains, payment fees and other licences are not assumed unless the proposal names them.
Copywriting, photography, CGI, motion, translation, product-data preparation and large-scale content entry are separate unless explicitly scoped.
Complex data migration, bespoke APIs, enterprise systems and integrations not identified during scoping are not silently included.
Prototype Sprint does not imply a production backend, live model, production data, payments, authentication, persistence or operational support unless stated.
Maintenance, campaign management, content publishing, experimentation and post-launch feature development require an agreed support scope.
Rivenhall can implement agreed requirements but does not replace the client’s appropriate legal, privacy, accessibility or regulatory advice.
Next step
Share what needs to change, who the work serves, what already exists and what a useful outcome must make possible. Rivenhall will review the brief directly before recommending an engagement or asking the questions needed to define one.
Send a project briefView current engagements
