A website that receives the request, a portal that follows it through
Clients submit a request on your website and follow visits and documents in their account. Your team sees what needs scheduling, approval or completion. Try both sides of the journey.
Interactive Demonstration — Sample Data Mutqan and every company and person in this demonstration are fictional, not our clients. Figures and documents are sample data, not results we achieved.
The problem we address
A service request arrives in a message, the appointment is agreed on a call, and the report lives in a separate file. Clients ask for updates while staff search several places to find what was agreed.
When a client has several branches, knowing who can request, approve and see an invoice becomes an essential part of the work.
Signs you may recognise
- Clients ask when the technician is coming because they have no update.
- A quotation waits for approval without a clear owner.
- Only one employee has the visit report.
- A user can see requests from a branch they do not manage.
What needs careful design
The interface is only part of the work. Transitions and permissions need clear rules.
Account and site boundaries
Each user sees their own company and permitted sites, with separate requester, approval and finance permissions.
A workable schedule
Prevent overlapping visits for a technician and flag a missed response target before confirming a time.
Evidence of completion
A checklist, work summary and visit report, followed by client confirmation or a reason to reopen.
Content in two languages
Edit and preview a draft, check both languages before publishing, and keep versions that can be restored.
The solution
A website that presents your services and receives requests, a portal where clients follow their work, and an operations interface for your team.
- Website requests with a reference and limited guest tracking.
- Client accounts for requests, visits, approvals and documents.
- Separate account administrator, requester and finance roles.
- A technician schedule that prevents overlapping bookings.
- An event log that separates client messages from internal team notes.
- Arabic and English content with drafts, previews and version history.
Modules in this demonstration
Start with the website alone, then define the portal as a separate scope when needed.
Service website
Services, visit requests and reference tracking, with its own language selection.
Client accounts
Simulated sign-in and verification, with roles and sites controlling what each user sees.
Requests
Clear status, messages, appointments, visit reports and completion confirmation.
Approvals and documents
Itemised quotations with sample tax, finance invoices and account documents.
Team scheduling
Technician visits, priorities and response targets, with booking conflict prevention.
Content management
Arabic and English fields, preview, publication and restoring an earlier version as a draft.
How the production project is structured
The demonstration runs locally. A production project enforces permissions and stores data on the server.
Interfaces
- Arabic and English public website
- Client portal
- Team operations workspace
Services
- Authentication, verification and permissions
- Request, scheduling and approval rules
- Notifications through company-owned accounts
Data
- Database with tenant isolation
- Documents with controlled downloads
- Backups and audit history
The simulation below is not connected to those services, sends no messages and does not retain your data after reloading the page.
Explore four perspectives
Mutqan is a fictional facilities company in the UAE. Its sample data uses AED and an illustrative 5% VAT. Everything you do stays in the browser for this visit.
What to try
- Submit a sample request on the website, then open it as the team and schedule a visit.
- Sign in as Khalid, Mariam or Lina and compare their permitted sites and actions.
- Review and approve a quotation as an administrator, then complete a visit as the team.
- Edit the website headline in both languages, preview the draft, then publish a version.
- Use the demo controls to try read-only access, a slow connection or an offline state.
All names, accounts and documents are fictional. Sign-in, notifications and file checking are local simulations. See “Full version” for the production requirements.
Expected changes in daily work
Practical changes the design aims to support, not guaranteed business results.
- A clear status
- Clients see where the request stands and what they need to do.
- A visible schedule
- The coordinator sees visits and conflicts before confirming a booking.
- A recorded approval
- The quotation and the administrator’s decision stay attached to the request.
- A reviewable handover
- Clients review the visit report and confirm completion or request further work.
The effect depends on how the team operates, data quality and agreed service rules. The actual commitment is to the written scope, acceptance criteria and dates in the proposal.
Scope of a project like this
The public website is a standalone starting point. A connected portal, operational rules and integrations are scoped and quoted separately.
In the basic website scope
- Agreed service pages in Arabic and English
- A design for phones and desktops
- An agreed contact or service request method
- Basic search optimisation and content handover
Added when needed
- Client accounts, roles and site permissions
- Requests, scheduling, approvals and documents
- Content management and version history
- Connections to messaging, accounting or your existing systems
What we need from you
- Approved services, content and brand assets
- Roles, service rules and approval policies
- Hosting and sending accounts in your company’s name
- An owner to review acceptance criteria at handover
Hosting, provider fees and external subscriptions are paid to their providers and opened in your name. The website price shown here does not include the full portal in the demonstration.
How it starts
The price and duration apply to a bilingual site or simple portal within the scope described in the offer. A connected portal with the full demo workflow needs a paid diagnostic and a custom implementation quote.
- Duration
- 14–21 days
- Simple website or portal price
- Starting from 3,000 SAR
How does your team receive service requests today?
Tell us what happens from request to closure, and what clients need to follow themselves.