A website testimonials brief helps your team decide which customer comments can be published, what they demonstrate and how the final wording will be approved. It is useful when a business has positive feedback in email, WhatsApp or project notes but no organised way to turn it into credible website content.
For a business investing in web development in Kenya, testimonials should answer practical questions about working together. A visitor may want to understand communication, the type of work delivered or how a particular requirement was handled. A wall of anonymous praise rarely explains those details.
This guide covers collecting, editing and approving customer statements for a business website. It does not provide a legal consent template or promise that displaying testimonials will produce a particular search position or enquiry rate.
Choose the question each testimonial should answer
Begin with the page where the comment will appear. A visitor reading about website maintenance may have different concerns from someone comparing ecommerce development proposals. Identify the concern before choosing the quote. Otherwise, the most enthusiastic statement can end up beside a service it does not describe.
Write a short purpose for each proposed placement. For example, an illustrative purpose could be “explain how the team communicated during a redesign.” Another could be “show why the client chose a particular catalogue structure.” These are editorial goals, not statements to put into a customer's mouth.
Separate feedback about the working relationship from evidence of business results. “The handover was clear” describes an experience. “Enquiries doubled” is a measurable claim requiring supporting information and context. Do not convert the first into the second because the result sounds more persuasive.
A useful testimonial can be modest and specific. If the customer comments on a well-explained process, preserve that point. There is no need to make every statement sound like a dramatic transformation. The reader benefits from understanding what the customer actually experienced.
Build a source and approval register
Create one register for the proposed quotes. Suggested fields are a reference, original message, date received, relevant project, intended page, proposed edited version, attribution and approval status. Store the original material through an appropriate internal process rather than exposing private correspondence in the public content folder.
Keep the person who supplied the comment distinct from the person who can approve its publication. A helpful employee may provide feedback without being authorised to approve a company logo or public statement. Ask the client which contact should review the proposed presentation.
Record exactly what is being approved. The quote, name, job title, organisation, portrait and logo are separate elements. Approval to publish a short statement should not be treated as an automatic instruction to display every identifying asset you possess.
Use clear statuses such as proposed, awaiting review, approved and withdrawn. An empty approval column should never be interpreted as permission. Give each record an owner so that the developer knows whom to contact when the content is ready but the release decision is unresolved.
Ask for useful feedback without writing the answer
Invite the customer to describe a specific part of the engagement in their own words. Ask what they commissioned, what question mattered before the project and which part of the process they can comment on. Avoid asking for a particular rating or supplying exaggerated praise for them to endorse.
An illustrative request might ask: “Would you be comfortable sharing a short comment about the catalogue handover? We would send the proposed quote and attribution for your review before adding it to the website.” Adapt the request to the actual relationship and the work that was delivered.
Do not pressure a customer to disclose commercial figures, private operational details or information about their own clients. If they prefer a limited attribution, discuss whether the proposed quote still provides useful context and can be presented honestly. Do not invent an identity to fill the gap.
Keep feedback collection separate from resolving an outstanding complaint. If someone raises a problem, route it to the person responsible. The content process should not turn a support conversation into a request for praise while the original concern remains unanswered.
Edit for readability while preserving meaning
A message written on a phone may contain repetition, spelling errors or details that do not belong on a public page. Prepare a concise proposed version, but retain the original alongside it. This lets the reviewer compare the meaning instead of relying on memory.
Remove irrelevant detail carefully. A customer may have praised one stage while qualifying another. Deleting the qualification could change the overall statement. When a shorter version cannot preserve the meaning, use another passage or ask the customer to write a fresh public comment.
Do not add service names, locations or search phrases that the customer never used merely to make the quote keyword-rich. The surrounding page can explain the project factually. A testimonial should remain a recognisable customer statement rather than becoming agency sales copy inside quotation marks.
Send the actual proposed version for approval. Include its attribution and enough page context to show how it will be used. Record the approved version rather than treating a general positive reply as approval for future rewrites of the same material.
Keep claims and project context checkable
Read each quote as a potential customer would. Could it imply that a proposed feature was delivered, that a mockup was manufactured or that the agency achieved a result it has not verified? Add factual surrounding context or choose a clearer statement when the implication is uncertain.
Google's guidance on helpful, reliable content asks publishers to consider clear sourcing, evidence and whether material is useful to its intended audience. Apply that editorial principle here by keeping customer statements attributable and the supporting project description accurate. A testimonial is not a substitute for documenting the actual work.
For any numerical claim, ask what was measured, over which period and by whom. If those answers are unavailable, leave the number out until it can be reviewed. Do not attach a growth claim to a redesign simply because the events happened in the same month.
A short case summary can provide context without inventing outcomes. State the agreed task and relevant deliverable using approved project facts. Link to an appropriate project page if one exists and has been cleared for publication. Avoid presenting a confidential internal screenshot as supporting proof.
Brief the layout for phones as well as desktop
Ask the designer to show a real approved quote in the proposed layout. Placeholder text often hides problems such as long organisation names, lengthy job titles or a statement that becomes difficult to read inside a narrow card. Review those details before approving the component.
Prioritise the statement and its attribution. Decorative quotation marks, oversized portraits and repeated logos should not crowd out the words. If the design truncates a quote, ensure the visible part still makes sense and that any expansion control works as expected.
Keep the text available as readable page content rather than embedding the whole statement in an image. Where portraits or logos are used, include them in the website image content brief so that source, crop and approval decisions remain connected.
Review the mobile page with several quote lengths. Check contrast, spacing and whether a visitor can reach the next useful action without navigating a complicated carousel. The goal is a readable account of relevant experience, not the largest possible collection of moving cards.
Plan replacements and withdrawals before launch
Name the person who can update testimonial content after the website goes live. Include the editing process in the website handover checklist, particularly if staff will add new statements through an admin screen.
Keep the approval register connected to the published version. If a job title changes or a client requests a revision, the editor should know which pages contain the statement. Repeated copies across service pages can otherwise make a simple correction difficult to complete consistently.
Agree how withdrawn or outdated material will be handled. Remove the relevant public content through the normal review process and record the change internally. Do not quietly substitute another person's name under an existing quote to preserve the visual layout.
Frequently asked questions
Do we need testimonials before starting a website?
No. Build the content plan around evidence you actually have. Approved project descriptions and clear service information can be prepared while genuine customer feedback is collected. Do not publish invented statements as temporary placeholders.
Can we shorten a long WhatsApp message?
Prepare a shorter proposed version and ask the appropriate customer contact to review its wording and attribution. Preserve the original message internally and check that the edit does not remove an important qualification or change the meaning.
Should every service page use the same quote?
Choose statements relevant to the visitor's question. Reusing a quote may be reasonable, but it should not imply experience with a service the customer did not commission. Record repeated placements so later edits can be made consistently.
What should we send with a website enquiry?
Send the intended pages, available feedback, proposed attribution and approval status without unnecessary private correspondence. Get a free quote for the website work and ask for testimonial layout, approval and content maintenance to be included in the scope.
