Three offers, one website
AI Minds combines a company story, six service families and an ERP product. The ERP adds its own layer: finance, people, supply chain, customer relationships, automation and reporting, followed by sector-specific explanations. Before a visitor can judge a demo, a trial or a consultation, the site has to make that hierarchy understandable, in English and in Arabic.
My part covered market research, content strategy, information architecture and the website copy in both languages. I worked alongside the design and development team, who owned the visual treatment and the build.
One company, three layers of offer
The company sets a broad direction: applying AI and digital transformation to business operations. A service family turns that direction into a possible engagement. ERP is a product, and a buyer evaluates it through functions, fit, implementation and price. Each layer needs a different degree of detail.
| Layer | The buyer’s question | What the content must do |
|---|---|---|
| AI Minds, the company | Who would we be working with? | Explain the business, its approach and the basis for credibility. |
| Service families | Which kind of help addresses our problem? | Describe the operating problem, scope and route into a conversation. |
| AI Minds ERP | Can this system support our work? | Explain modules, workflows, sector fit and the terms of evaluation. |
That distinction shaped the page structure. About gives identity and expertise room. Services separates the types of engagement. The ERP pages can explain a product without reintroducing the whole company each time. The homepage’s job is to send each reader to the right one.
The homepage sets the order of understanding
The homepage opens with a wide AI and ERP proposition, then translates it into business concerns (efficiency, integration, security, scalability, partnership and implementation) before the six services ask the reader to choose a route.
From there it moves through the service groups, an implementation process and eight industry entry points. The process gives a prospective client a picture of working together: discovery, design, implementation and optimisation. The industry cards help people who recognise their sector faster than a technology label.
The homepage also carries percentage claims about results. Figures like these persuade when the reader can see where they come from, so each one needs either a named case and a method behind it, or an explanation that can stand without a number.
ERP has to stay recognisable inside all of this. The navigation names the product, and the industry grid offers a sector route into it. A reader should always know whether they are looking at a packaged system, a custom AI engagement or the company itself.
Giving the company story its own space
The About page tells the company story through its mission, vision, reasons to choose AI Minds and areas of expertise. This is where a buyer gets to know the supplier behind the offer. If every product section had to answer those questions too, the module explanations would never get to the point.
The About page carries the company story, so the service pages do not have to.
The expertise groups name AI specialists, software architects, digital consultants, industry experts and infrastructure engineers. They describe the kinds of capability the company brings. The natural next step for this page is proof to match: named credentials, delivery examples and client stories.
Six service families need six reasons to choose
Every service family shares the same frame (introduction, FAQ, contact and a consultation route) while the selected family changes the detailed explanation. The families are genuinely different, so the copy has to make that difference visible before it asks anyone to get in touch.
Each service family is named for the problem it addresses and laid out for scanning.
| Family | Operating problem | What the page emphasises |
|---|---|---|
| Digital transformation | Deciding where to begin and how to modernize | AI consulting, legacy guidance and scalable technical foundations. |
| Mobility and logistics | Coordinating vehicles, journeys and demand | Fleet platforms, shared mobility and booking automation. |
| Business operations | Reducing manual coordination and missed signals | Project management, process automation and business intelligence. |
| Digital presence | Turning a digital audience into useful interactions | Web experiences, marketing and social-media work. |
| Technology infrastructure | Keeping systems available and secure | Cloud architecture, cybersecurity and technical support. |
| Talent and consulting | Obtaining the expertise to deliver | Specialist staffing, team extension and embedded execution. |
A single consultation route can serve all six, as long as the copy just before it tells the reader what the conversation will cover. An infrastructure buyer wants to hear about environments and support; a mobility buyer wants to recognise their own workflow. The FAQ deserves the same care: ERP implementation questions repeated on every service page crowd out the questions that service actually raises.
Arabic changes some of the offer itself. Mobility leans towards routing and supply chains, and talent adds training and strategic advice. That is a decision about scope as much as language: a bilingual service list needs one agreed definition of each offer, then room for each language to explain it naturally.
ERP needs the language of everyday work
The ERP opening names the product and offers trial and pricing routes. Below it, six modules turn a broad system promise into business functions. This is where the reader stops asking who AI Minds is and starts asking what the system would do for their team.
Finance and HR follow the same pattern: function, benefit, detail, then a choice. That makes modules easy to compare.
| Module | Everyday work | Evaluation question |
|---|---|---|
| Finance | Invoicing, reconciliation, expenses and cash-flow reporting | Which records and approvals connect, and what can the finance team inspect? |
| Human resources | People information, recruitment and workforce planning | Which HR processes are included, and how do permissions work? |
| Supply chain | Inventory, procurement and demand planning | How are purchasing, stock and fulfilment connected? |
| CRM | Customer records, pipeline and follow-up | How does a sales team move from an enquiry to a recorded relationship? |
| Automation | Workflow steps, task hand-offs and exceptions | What can be configured, and when must a person intervene? |
| Analytics and reporting | Dashboards, consolidated information and forecasts | Which data feeds the report, and can the buyer trace it? |
Finance and HR follow a repeated pattern: function name, benefit, detail, then a selection action. That makes the modules easy to compare. The next layer of precision is integrations, configuration, support and implementation, the details a buyer checks before booking a demo.
The original presentation also showed proposed module prices. A price on a product page sets expectations about billing and implementation as much as cost, so it belongs next to a clear account of what is included.
One ERP, eight buying contexts
The industry selector changes the explanation substantially. Manufacturing talks about production and predictive maintenance, retail about stock and recommendations, construction about projects and equipment. Healthcare and financial services introduce specialist AI promises, such as diagnosis and credit scoring, which sit better apart from the back-office ERP story.
Choosing an industry changes the explanation: manufacturing gets its own account of how the ERP fits, followed by a consultation route.
Each sector explanation earns its place when it answers the question a buyer in that sector is likely to bring:
| Industry | Likely buyer question | Content emphasis |
|---|---|---|
| Manufacturing | Can operations and finance see material use and production cost together? | Production orders, materials, purchasing, stock and costing. |
| Retail and e-commerce | Can we reconcile stock, sales and returns across branches and channels? | POS, inventory, orders, fulfilment and financial reporting. |
| Construction and real estate | Can we compare each project’s budget, commitments and actual costs? | Project costing, procurement, progress billing and equipment. |
| Financial services | Can finance trace entries, approvals and consolidated reports? | Ledgers, reconciliation, controls and reporting; validate specialist risk tools separately. |
| Hospitality and tourism | How do reservations and occupancy connect to accounts and operating costs? | Explain ERP integration with hotel/PMS systems and purchasing. |
| Transportation and logistics | How do vehicles, shipments and warehouse costs connect? | Fleet and shipment workflows, stock, maintenance and cost reporting. |
| Healthcare | Can administration coordinate purchasing, staffing and financial records? | Back-office ERP and the boundary with clinical/HIS systems. |
| Professional services | Can we connect project time, staffing and billing? | Resource planning, project profitability, client records and invoicing. |
Saudi buyers also use their own terms for these needs. Contracting firms talk about project cost centres and progress billing, retailers about cashiers and branches, and Arabic-speaking buyers about hotel operations and fleet management. A sector explanation should use those words.
English and Arabic are two editorial systems
The difference goes well beyond reading direction. The Arabic homepage explains أنظمة تخطيط موارد المؤسسات alongside the abbreviation ERP, using fuller sentences to bring an unfamiliar category closer. The English opening reaches the umbrella proposition faster.
The English homepage today opens with the company proposition, then offers two routes: explore the services or book a consultation.
The Arabic homepage today spends longer on the business benefit before offering the same two routes.
Some differences change what the reader expects. English presents discovery before design; Arabic puts design first. The process button moves from exploring services to booking a meeting. In the modules, English asks the reader to choose a module while Arabic calls the choice a system, and the Arabic ERP opening returns to a broad digital-solutions message where the English one names the product.
The service pages differ more. English mobility includes white-label platforms while Arabic emphasises routing; English talent is about supplying specialists while Arabic adds workshops and training. A shared editorial specification, agreeing offer boundaries, process order and product names, would settle these and still leave each language free to write naturally.
Arabic content planning starts from Arabic questions such as محاسبة المقاولات, نظام نقاط البيع and إدارة الأساطيل, rather than from a translated English keyword list. Those questions point to content needs that English modifiers miss.
Every button promises a different next step
Exploring, consulting, watching a demo, trying the system and checking prices are five different levels of readiness. Each action should tell the visitor what happens next, and the destination should keep that promise.
| Intent | Action | Where it leads today |
|---|---|---|
| Find an offer | Explore services | Opens the service explanation and its six families. |
| Discuss a business problem | Consultation | Uses the contact route; the selected service is explained beforehand. |
| Evaluate the product | Get your demo | Also uses contact, where the copy offers consultation or a live demonstration. |
| Try the system | Start free trial | The ERP opening leads to contact; a lower registration route opens signup. |
| Compare commercial terms | Plans and pricing | Reaches pricing, which reported plans temporarily unavailable. |
Signup asks for a name, email and phone number, then moves through verification, plan, company, address and review. A “Start free trial” label should make clear whether access is immediate or arranged through a conversation.
The Arabic industry consultation adds the word “free”, and the homepage process invites a meeting rather than more reading. Both are commercial promises, and they should match across the two languages. The real test is whether the whole route honours what the button said.
Search intent and page structure need to agree
Saudi buyers searching for “ERP software” expect suppliers and system pages, while “digital transformation” leads to policy, news and general business reading. In Arabic, نظام ERP is mostly a category question, and sector searches move closer to specific workflows. That points to three kinds of content: explaining the category, comparing a system and defining a consulting engagement.
Today each service and industry panel on the site is a state of one page, under one title. That works for browsing. If I were continuing the work, a sector with its own buying question would get a stable page with its own heading, copy and metadata, and the rest would stay as panels within the product page. The content decides which is which, not the number of URLs.
What the project shows
The project gave a broad offer a readable hierarchy in two languages: a company story, six service families and an ERP product with modules and sector variants, each with a clear job. My contribution connected the research, the content strategy, the page architecture and the writing in English and Arabic.
The SEO and Business Architecting cases look at the same project through search and through commercial strategy.