Structured capability
Connect facilities, technologies, equipment and specialist experience.
← All industriesComplex infrastructure.
BIG FISH · Energy
Complex infrastructure.
Clear digital services.
Websites for energy and engineering businesses, contractor portals and service workspaces. Present capability, equipment and projects while organising requests and documentation.
BIG FISH / INDUSTRIES
01Facility and asset
02Service request
03Readiness check
04Task approval
Design × industry workflow
FROM WEBSITE TO SERVICE
Clear for customers.
Useful for your team.
Partner portal
Requests, approvals and required documentation in one workflow.
Service continuity
Link each request to its facility, equipment and responsible specialist.
INTERACTIVE EXAMPLE
Your workflow.
Try it in action.
Try the journey “Facility and asset → Service request → Readiness check → Task approval”. Change the inputs to see when the next step becomes available.
An educational model with fictional companies, values and rules. All actions stay in the browser; no data is submitted. This illustrates a possible solution, not a connected system or a client case study.
INPUT
WORKFLOW RESULT
Enable JavaScript to use the example.
WORKFLOW
Every step connects
to an outcome.
01
Facility and asset
02
Service request
03
Readiness check
04
Task approval
| Layer | Responsibility |
|---|---|
| Website and interface | Presents the product, explains conditions and guides the action. |
| Application server | Checks permissions, valid transitions and repeated requests. |
| Business systems | Confirm authoritative data within the agreed exchange scope. |
| Responsible people | Make decisions requiring professional assessment and approval. |
BIG FISH · ENERGY
Key readings. Visible exceptions.
An energy portal separates the asset overview from detailed equipment readings. Units, reporting periods and data freshness remain beside each chart. Colour signals status, with text and icons reinforcing important alerts.
Maintenance workflows connect requests, inspection history and asset documentation. Users can see what happened, who accepted the task and what comes next. Viewing and editing permissions are defined separately for each role.
SOLUTION GUIDE
Behind an interface
that works.
Design decisions, data, permissions and acceptance checks. Exact business rules and integrations are defined for your organisation.
Energy / 01
Design and the user journey
Energy websites explain complex services to buyers, contractors and specialists. Combine strong facility imagery with clear service diagrams and equipment tables. Separate public capability presentation from the operational workspace. Public pages should not expose internal access arrangements for critical systems.
During design, document representative screens and expected user actions. For each decision, identify what editors maintain, what comes from another system and who owns its freshness.
Acceptance check: A first-time mobile visitor can find the relevant service and next step.
Energy / 02
Workflow and states
The workflow connects these stages: Facility and asset → Service request → Readiness check → Task approval. Each transition has an owner, inputs and a visible result. Before implementation, map the normal journey, correction, cancellation and repeated actions. Interface status must represent a confirmed state rather than a button click.
Acceptance check: Returns and retries preserve input without duplicating the result.
Energy / 03
Data model and documents
Facilities, assets, contracts and service requests have separate identifiers. Requests include descriptions, attachments, priority and an agreed work window. Preserve the relationship between document revisions and requests. A complete document pack is not permission to perform work.
Acceptance check: Reference data changes do not overwrite an agreed document.
Energy / 04
Roles and access boundaries
Contractors see assigned tasks and permitted facility documents. Coordinators check completeness and responsible specialists approve next steps. Work authorisation follows the organisation’s existing procedures. The portal supports communication and approval records; it does not make industrial safety decisions.
Acceptance check: A different organisation cannot retrieve a restricted file by direct URL.
Energy / 05
Integrations and data ownership
Exchange only permitted data with asset or maintenance systems. The public website does not directly control equipment. Use a defined integration boundary, logs and retry rules. On failure, show the last confirmed information and a review task rather than an unverified readiness status.
Acceptance check: An unavailable source never appears as a confirmed success.
Energy / 06
Errors, retries and recovery
For long operations, acknowledge receipt and retain the result identifier. Retrying after a connection loss must not create a second record. Separate user-correctable errors from cases requiring a specialist, preserving input under the agreed handling rules. Design empty, loading, forbidden and unavailable states before implementation rather than after launch.
Acceptance check: A repeated event does not apply an operation twice.
Energy / 07
Content, search and discovery
Organise content by services, facility types, technologies and relevant experience. Publish only approved project details and results. Separate open documents from partner-only material. Structured enquiries identify the facility and service area early, reducing transfers between departments.
Acceptance check: Search and filters lead to useful pages without endless duplicates.
Energy / 08
First release and evolution
The first release covers the complete journey from “Facility and asset” to “Task approval”, supporting pages and editable fields. Test mobile views, roles, forms, documents and integration failures in staging. Save the previous state and define rollback before switching. Handover includes editor instructions, the exchange design and a checklist for future releases.
Acceptance check: Recovery has been tested on a copy, and editors can maintain fields independently.
FAQ
Before we start
Can we launch the website before the portal?
Yes. Start with structure, design, content and a complete enquiry journey. Design catalogue entities and identifiers with the future portal in mind to avoid another data migration.
Can you connect our existing systems?
We first inspect the supported interface, permissions and test environment. Then agree data scope and system responsibilities. If no suitable API exists, assess an alternative and its limitations separately.
What determines cost and timing?
Page types, content volume, roles, integrations and first-release scope. Discovery produces a structure, prototype and staged estimate. This page’s demonstration is neither a finished system nor a fixed-price promise.
Let’s discuss your industry project.
Start with business objectives, website structure and the workflow that needs a better experience.