Public feature sections
Explain patient-facing services, portal capabilities, and lab strengths through homepage sections and builder content.
What feature content means in the lab website
In the lab public website, feature content is the patient-facing explanation of what the lab offers. It may appear as Website CMS home sections, visual builder blocks, blog links, portal calls to action, or service cards. The current lab website routes are Home, Tests, Blog, and Patient Portal; feature messaging is managed as content inside those pages rather than as a separate feature-page route for each service.
This distinction is important. A feature section should explain services in a way patients understand, while the Lab Panel continues to manage the operational truth: tests, prices, report release, home visit requests, branch contact details, and portal access.
Good feature content answers simple patient questions: what service exists, who it is for, how the patient starts, what the lab team will do next, and where the patient should go inside the website.
Website CMS home sections
Website CMS includes a Home Sections repeater. Each section has a section key, enabled switch, sort order, English title and body, and Arabic title and body. Enabled sections are displayed on the fallback homepage in sort order. Disabled sections stay saved in the panel but do not appear publicly.
Use the section key as an internal label such as home-visits, insurance, fast-results, corporate-services, or sample-instructions. The public patient sees the title and body, not the key. Keep keys stable so administrators can recognize the purpose of each section later.
Sections work best when each one explains a single promise. For example, one section can describe home collection requests, another can describe patient portal results, and another can describe insurance or corporate contracts. Avoid putting every service into one long paragraph.
Builder feature blocks
When the visual builder is used, feature content can be designed directly in the home page draft. The builder supports publishing sanitized HTML and CSS, so the team can create richer service layouts while still keeping content controlled. Route placeholders and widgets can be used so links to Tests, Blog, and Patient Portal remain correct.
The starter builder page includes a hero, action links, a grid of CMS sections, featured tests, latest posts, and portal call to action. A marketing user can expand that into service blocks, branch highlights, home visit messaging, or trust-building content. After publishing, the public homepage uses the published builder output instead of the fallback sections.
Builder blocks should be reviewed like any public medical communication. Confirm every service claim with the lab owner or responsible manager before publishing.
Patient portal feature messaging
The patient portal is one of the strongest public features. Public content can tell patients that they can sign in, review released reports, check loyalty information when enabled, and request home visits when the lab supports that workflow. The content should also explain that only released or published results appear in the portal.
Do not imply that every patient can see every historical result. Portal visibility depends on patient identity, released sample/result status, lab company ownership, and authentication. The patient portal uses OTP login, so the public content should encourage patients to use the phone number registered with the lab.
Home visit and service area messaging
Home visit messaging must match the lab's real dispatch capacity. The portal can receive home visit requests with contact information, address, preferred date/time, notes, and selected tests. But the public feature text should not promise immediate acceptance unless the lab has a team ready to confirm and dispatch requests.
Write home visit content as a request flow: the patient submits details, the lab reviews availability, and the team confirms. If the lab serves only specific areas or times, say that clearly. This prevents reception staff from having to correct expectations after the patient has already requested service.
Catalogue and educational feature content
Feature sections can point patients to the Tests page when they need to search for a test by name or code. The Tests page is safer than a manually written price list because it reads active tests and active price ranges from the catalogue.
Blog posts are useful for education, preparation instructions, service announcements, and seasonal campaigns. Published posts appear in the latest posts area of the homepage and on the public blog. Keep blog content medically careful, and avoid replacing doctor advice with general marketing copy.
Writing rules for feature sections
Write for patients and family members, not internal lab staff. Use short headings, clear service descriptions, and direct calls to action. Mention patient benefits, but connect them to the real workflow: portal result viewing, test search, home visit request, WhatsApp contact, branch visit, or blog reading.
Avoid internal system terms such as workflow state, tenant, catalogue price source, QC gate, or SLA. Replace them with patient language such as "your report is available after review", "search for a test", "request a home visit", or "contact the lab team".
Review checklist
Before publishing feature content, confirm that each section has English and Arabic text, the enabled switch matches the intended public visibility, and the order makes sense on mobile. Check that no section repeats the same promise, contradicts prices, or mentions a service that the branch cannot perform.
After publishing, open the public homepage, test the Patient Portal button, open the Tests page, and read the feature sections as if you are a new patient. If the next step is unclear, revise the section before sending the website link to patients.