Before we offered Amrak to anyone, we ran HBS Group on it. Our website, our bilingual blog, the images and SEO fields behind each article, our editorial and marketing calendars, our client portal and even our design files now take plain-language requests through our own connector, the same kind of connector we build for clients. The biggest change is the shape of the work: the team writes a clear request, reviews what Amrak prepared and checks the result, instead of clicking through form after form. This case study shows what we run on Amrak, the checks we built around it and the lessons any company can use. We chose not to publish internal figures, so the only count about our own work in this article is the public one from our Amrak page.
Why did we run Amrak on HBS before offering it to clients?
HBS Group is a B2B company that publishes in English and Arabic, runs its own CMS, keeps a marketing calendar and serves clients through a portal. That is the same mix of systems many of our clients run. If Amrak could carry our daily work, with all the odd cases of our own setup, we would know what it takes to shape it for someone else's.
Publishing was the obvious place to start. On our Amrak page we count 14 manual steps to publish one article by hand: log in, open articles, start a new article, add the title, write the content, upload the image, describe the image, choose the category, fill in the search title, the search description and the page link, set the publish date, preview and publish. With Amrak it is one sentence, followed by a review. In a bilingual CMS, many of those fields exist in both languages.
Research supports starting with the workflow rather than the tool. Of all the attributes McKinsey tested in its State of AI survey published in March 2025, redesigning workflows had the biggest effect on whether organisations saw EBIT impact from generative AI. Yet only 21% of respondents said their organisations had fundamentally redesigned at least some workflows. We wanted to redesign ours first, then offer the result.
How do we publish bilingual articles with one request?
Our team writes and publishes blog posts in English and Arabic through plain-language requests. A typical request names the article, both languages, its FAQs, the SEO fields and the date. Amrak works through our CMS's own sections: it creates the post, fills in each language, adds the FAQs, sets the meta title, meta description and keywords for each language, files it under the right category and schedules it.
The people stay responsible for what is said. Every post starts from a draft the team approves, and that approved draft is what Amrak publishes and what it is checked against afterwards. Amrak takes over the part nobody misses: copying text between fields, switching languages and filling the same form again.
If you want to see how one sentence turns into a change inside a system, step by step, read how Amrak works, from one sentence to action.
How do we handle images, headlines and the media library?
Images used to be a separate job for every post. Now they are part of the request.
- Hero images: Amrak generates the article's hero image and adds the headline to it.
- Media library: it uploads the finished images to our media library, so they can be found and reused.
- One image per language: it attaches the featured image and the social-sharing image for each language, so an Arabic reader who shares a post sees an Arabic image and an English reader sees an English one.
- Alt text: each image gets a description, which our pre-publish check confirms.
AI image generation is part of the Amrak monthly subscription when a client needs it, so the same workflow is available to the companies we build for.
How do we run the editorial calendar, SEO keywords and marketing posts?
Plans change. A launch moves, a topic becomes urgent, a series needs to slide by a few days. Instead of opening each post and changing its date, we ask Amrak to schedule or reschedule posts across the editorial calendar in one request, then check the calendar.
We also manage our SEO work this way. Our keyword tracking and editorial calendar run through Amrak, so the plan for what we write next lives in the same system as the posts themselves. The marketing posts calendar for social media runs through Amrak too: drafting posts, placing them on the calendar and moving them when plans change.
What do we check before and after anything goes live?
Speed is only useful if the result is right. So every post passes a quality check before it goes live, and a second check after.
| Check | What we look for | Why it matters |
|---|---|---|
| Both languages | The English and Arabic versions both exist and are complete | A post that is live in one language only looks broken to readers of the other |
| Meta title and description | Both are within the lengths we set for search results | Search results shorten titles and descriptions that run too long |
| Image alt text | Every image has a description | Screen readers and search engines rely on it |
| Internal links | At least one link to another page on our site | Readers and search engines find related content |
| Read-back after publishing | The stored post matches the approved draft | It catches anything that was dropped, changed or formatted differently on the way in |
The read-back is the habit we would recommend to anyone. After publishing, Amrak reads the post back from the CMS and compares it with what we approved. It is a simple step, and it is less common than it should be: in the same McKinsey survey, 27% of respondents whose organisations use generative AI said employees review all content created by gen AI before it is used.
How do we use Amrak for design work and the client portal?
Amrak is not limited to the website. Through a connector to our design tool, the team works on design files with plain-language requests, such as laying out a page of a sales booklet. A designer still makes the creative calls and reviews every page.
Our client portal takes requests too, for routine tasks such as looking up a client's open requests or updating a request's status. Anything that sends a message to a client still waits for a yes, the same rule every Amrak client gets.
What changed for our team?
Because we are not publishing internal figures, we will describe how the work changed rather than by how much.
| Task | By hand | With Amrak |
|---|---|---|
| Publishing an article | Form after form in the CMS, for each language | One request, then a review of what was prepared |
| Images | Generate, add headline, upload, attach and describe, one at a time | Part of the same request, checked by the team |
| Rescheduling | Open each post and change its date | One request for the whole set, then a look at the calendar |
| Pre-publish check | A checklist someone has to remember | Runs before anything goes live |
| Confirming the result | Open the live page and compare by eye | The stored post is read back against the approved draft |
| Knowing who did what | Ask around | The log shows who asked, when and what changed |
The work that remains for people is the part that needs judgment: what to say, whether it is right and whether it should go out. The forms are the part that left.
What did we learn that any company can use?
- Write precise commands. Vague requests produce vague results. The commands that work say what, where, when and for whom. We collected 30 examples by department in ready-to-use Amrak commands for every department.
- Keep approvals on anything public-facing. Amrak always stops before messages to clients, deleting anything and changing prices. We also keep a human yes on everything that becomes public, because a published mistake costs more than a short wait.
- Always verify the result after a change. Reading the result back is cheap. Finding an error after a client does is not.
- Use the log. Every action is recorded with who asked, when and what changed, which makes it easy to see who asked for what and to answer questions later.
- Expect edge cases, and treat them as information. Running Amrak on our own CMS surfaced its odd cases quickly. We fixed some and documented the rest, which is exactly why testing with your team is a stage of every Amrak project.
How would Amrak work in your company?
The same way it works for us, built around your systems instead of ours. HBS Tech builds a custom connector for your company, covering your own sections and rules, on MCP, the open standard for connecting AI assistants to company systems that we explain in what MCP is.
- Your systems stay: no data migration and no system replacement. Amrak connects to your website and content, dashboards, CRM, ERP, calendar, client portal and design tools.
- Permissions per person: each person reaches only what their permissions allow.
- Approvals for sensitive actions: messages to clients, deleting anything and changing prices always wait for your yes.
- A full log: who asked, when and what changed.
- Your data and your choice: data stays in your system, Amrak reads only what each request needs, you choose your AI provider, and you can switch Amrak off at any time.
Every project follows the same stages: a free discovery session, a command map, the build, testing with your team, handover and training, and ongoing support as you add commands. You can read why we launched the service in HBS Group launches Amrak, and see the full details on the Amrak page.
If you want your team to work the way ours does, with plain-language requests, approvals where they matter and a log of every change, book a free discovery session through the Amrak page. We will look at your systems and show you what the same approach would look like in your company.
