Illustrative scenario: not a client case study
A founder once brought a polished homepage to a review. Everyone liked the tone, but nobody could answer a basic question: what happens after the enquiry? The useful work was not rewriting every sentence. It was building a message system around the decisions customers needed to make.
Inventory the questions
Gather questions from sales calls, proposal comments, support conversations, search queries and contact forms. Sort them into problem, suitability, process, proof, timing, price and risk. Keep Dubai and Abu Dhabi language separate until you can see whether the underlying concern is shared.
A question deserves a visible answer when it recurs, blocks a decision, or exposes a genuine limitation. Do not publish private customer details simply to make a page feel specific.
Start the message map with the question that blocks a decision, not the phrase the team prefers. For a service, that may be fit, required input, sequence, ownership or what happens when the brief changes.
Write the message hierarchy
Set one core message, three supporting messages and proof for each. The core message should state who the service helps and the meaningful outcome; the supporting messages should explain approach, fit and next step. This hierarchy prevents every section from trying to be the headline.
Write a plain language version first. Then check that the page title, opening paragraph, headings, image descriptions and call to action support the same decision.
Assign one proof type to every supporting message: a visible process, an approved document, a capability description or a permissioned quotation. This makes weak claims easy to remove before publication.
Use proof with context
A logo, testimonial or credential is not self explanatory. Say what the proof demonstrates and what it does not. Use named permissions, dates and scope where available; otherwise describe the evidence accurately without implying more than it shows.
For professional services, useful proof may include a process sample, team expertise, a transparent deliverable, or an explanation of how risk is handled. Do not invent case outcomes or attach a client name without permission.
Use a content matrix showing message, audience, page, language, owner and review trigger. It prevents a new sales deck from contradicting a carefully maintained service page.
Handle bilingual meaning
Translate the decision, not the sentence order. An Arabic page should sound like a natural explanation to its intended reader and retain the same scope and limitations as English. Ask an Arabic speaking subject expert to review terms that carry legal, cultural or sector meaning.
Keep names, product terms and measurements consistent where they must match. Add language links and ensure users can reach the equivalent content without being sent to a generic home page.
Bilingual work needs a meaning review after translation. Terms about responsibility, timing and eligibility deserve particular attention because a fluent sentence can still widen the original promise.
Test and maintain the system
Ask people unfamiliar with the business to explain the offer after reading the page. Compare their answer with the intended decision. Review search queries, qualified form submissions and sales objections, but avoid changing copy for every fluctuation.
Keep the message map with an owner and review date. Update claims when the service, team, availability or supporting evidence changes.
Test the hierarchy with a reader who has no internal context. Ask what the service does, who it suits and what happens next; confusion identifies a missing message better than a preference poll.
Worked example: compare two language paths
Open the English and Arabic services pages on gang&lani and create a small message map with audience, decision, proof, limitation, and next step. Compare meaning rather than sentence order and record any unresolved translation question for review. This is a reproducible content audit, not evidence of conversion performance.
Track qualified enquiries, repeated clarification questions and proposal objections over an agreed period. Keep a change log so a seasonal change is not mistaken for a copy improvement.
What to take away
- Build messages from recurring customer questions.
- Give every supporting claim a clear piece of proof.
- Arabic localisation must preserve meaning and limitations.
- Test whether readers can explain the offer and next step.
Frequently asked questions
How many messages should a service page have?
Usually one central decision with a small number of supporting ideas is easier to understand than a list of equal claims. The right number depends on the service and customer questions.
Should English and Arabic pages be identical?
They should be equivalent in meaning, scope and evidence, but not necessarily literal translations. Natural language and culturally clear examples are more useful.
What should we do when proof is confidential?
Describe the method, scope and permission safe learning without revealing confidential details. Never turn a private result into an anonymous claim that sounds independently verified.