A public entity in the Kingdom is unusual among the organisations we advise, in one respect that changes almost everything about how technology decisions get made here: it does not set its own agenda, it does not control its own calendar, and it is measured on its progress by somebody else. A ministry, an authority or a commission receives a mandate from a national programme, spends against a budget cycle it did not design, buys through a procurement regime built for fairness and auditability rather than for speed, and is then assessed on its digital maturity by a body outside it. Very little of the work we are called into is a straightforward platform choice. Almost all of it is the reconciliation of those four constraints into something that can actually be delivered.
That reconciliation is what a sector page for government has to be about, because it is where public technology programmes fail. They rarely fail on the technology. They fail because a three-year transformation was funded one year at a time; because a requirement document written around one product attracted a single serious bid; because the service depends on data held by another entity whose own programme is eighteen months behind; or because the people who learned the system were contractors whose engagement ended at go-live and took the knowledge with them. None of those is a software defect, and none is fixed by buying better software.
The prize is correspondingly large. Saudi Vision 2030 has made digital government one of the most visible parts of the national reform agenda, and the citizen-facing standard in the Kingdom is now set by the best national platforms rather than by an entity's peers. A resident who authenticates once and completes a transaction in ninety seconds elsewhere does not grade your service against the ministry next door. That is a high bar, and it is a fair one.
Our interest, stated before the argument rather than after it. Trustangle is an independent advisory firm based in the Kingdom. We do sell selection, architecture and implementation assurance work, so we have a genuine commercial interest in your decision, and you should know that before you read further rather than discover it on a partners page afterwards. What we do not do is earn a margin on your licences or bid for the implementation we scoped. That is what makes it possible for us to write a requirement document that more than one supplier can answer - which, in a regime where the quality of competition determines the quality of the outcome, is the single most valuable thing an adviser can do for a public entity.
The three pressures below are not a catalogue of everything that can go wrong in a public entity. They are the three we are actually called about, and they are connected: the regulatory one sets obligations that are assessed and scored, the operational one removes the capacity that would meet them, and the data one is why cross-entity services take years rather than quarters.
A public entity here answers to several authorities at once, and they do not ask for the same thing. The Digital Government Authority (DGA) regulates government digital work and assesses entities on their digital maturity. The National Cybersecurity Authority (NCA) sets the national control baseline, with a heavier tier for systems classed as critical. SDAIA, through the National Data Management Office, governs data management, classification and the handling of personal data alongside the Personal Data Protection Law. The Communications, Space and Technology Commission governs the cloud arrangements much of this now runs on. The Government Tenders and Procurement Law and the national procurement platform constrain how any of it may be bought, and local content obligations shape who may realistically be bought from.
We are not going to quote you an article, a control reference or a deadline on this page. Those change, a sector page carrying them is wrong within a year of being written and never says so, and your own legal and compliance function is the authority on the current text in any case. What is stable enough to be worth saying is the shape of the problem, and in government it has a distinctive edge that private-sector compliance does not have: you are not merely required to comply, you are scored on it, and the score is visible to people above you.
That single fact produces most of the dysfunction we are asked to unpick. Work gets sequenced to move an assessment result rather than to reduce a risk, which is rational for the individual and expensive for the entity. Evidence is assembled by hand in the weeks before each assessment, so the same twenty people lose a month several times a year to reconstructing what was already true. Controls are implemented per system rather than once across the estate, so the twelfth system costs as much as the first and nobody can answer "who has access to citizen data" without a fortnight's work. And because several authorities assess overlapping ground on different cycles, the entity answers the same underlying question four times in four formats.
The work that breaks that cycle is not a compliance tool. It is deciding once where each obligation is met, who owns it, and how it evidences itself continuously rather than on request. That is IT governance - decision rights, control ownership and the evidence model - with the control environment itself covered under IT security consulting.
The operational problem in a public entity is rarely that something is broken. It is that the organisation has adapted to a set of constraints so thoroughly that the adaptation now costs more than the constraints do.
The funding cycle and the programme length disagree. A platform replacement or a service redesign is a multi-year undertaking; the budget is approved annually. Entities respond by slicing the programme into pieces that can be committed within a cycle, which is sensible, and then by scoping each piece to spend the allocation rather than to deliver the next coherent increment, which is not. The visible symptom is a programme that has consumed three years of budget and cannot yet retire the system it was meant to replace, because the decommissioning was never anyone's year.
Procurement lead time is part of the delivery plan, and is usually left out of it. Between a decision and a mobilised supplier sits requirement drafting, internal approval, publication, a bidding window, evaluation, award and contracting. That elapsed time is real, it is largely not compressible, and a plan that begins at contract signature has already lost the part of the year that most often turns a delivery into a slip. Building it into the schedule is unglamorous and is the cheapest realism available to a public programme.
Capability leaves when the contract ends. Specialist technology skills are scarce and expensive everywhere, and a public entity competes for them against employers with more flexible pay. The common answer is to contract the capability in. That works during delivery and fails afterwards: the people who understand why the system was configured the way it was are gone at go-live, the entity cannot change its own platform without raising a variation, and the second phase costs more than the first. Knowledge transfer written into the contract as a deliverable with an acceptance test - not as a goodwill clause - is the single highest-return contractual change we recommend to public clients.
Dependence on one integrator. Many entities have a long relationship with a single systems integrator holding considerable institutional knowledge. That is an asset. It also means the party that estimates the work, designs it, builds it and assures it can be the same party, and that the entity has no independent basis on which to judge whether an estimate is reasonable. That is not an accusation about any supplier; it is a structural absence of a second opinion, and it is straightforward to restore.
The channel that will not close. Almost every entity that has digitised a service still runs the counter, the call centre and the paper form alongside it, often because a segment of users genuinely cannot use the digital one. Running both is the correct decision and an expensive one, and it is frequently taken by default rather than deliberately. The question worth asking annually is which channels remain open on purpose, for whom, and what it would take to serve those users digitally instead.
Cross-agency integration is the defining technical problem of public-sector technology in the Kingdom, and it is not primarily a technical problem. The national channels for identity and for exchanging data between entities exist and work; what is usually missing is the readiness of the entity on either end of them.
The recurring conditions are consistent enough to list. Nobody has declared which entity is the authoritative source for a given data domain, so two entities hold different versions of the same establishment record and both believe they are right. Data has not been classified, so nothing can be shared confidently, because no one can say whether this particular field may cross this particular boundary - and in the absence of an answer the safe response is refusal, which is why so many integration requests die quietly. Integration has accumulated as point-to-point interfaces built one project at a time, so the entity has no inventory of its own data flows, which is an architecture problem right up until an authority asks for that inventory and it becomes a compliance one. And the reporting that goes to central bodies is assembled through a chain of extracts and spreadsheets whose logic lives in two people's heads.
This is why the ambition that matters most - a proactive service, where a citizen is offered an entitlement rather than asked to apply for it - is so much harder than it looks. It requires an entity to consume another entity's data as authoritative, in real time, with a consent and classification position behind it, and to be accountable for a decision made on data it does not own. Every one of those is a governance decision before it is an interface. The boundary work itself is systems integration, and the reporting and analytics layer that becomes possible once the boundaries hold is business intelligence & analytics.
What follows is what actually comes up in the conversations we are in with deputy ministers, CIOs, heads of digital transformation and programme owners in the Kingdom. It describes where attention is going. It is not a market forecast, and we have attached no percentage to any of it for the reason section 8 sets out at length.
From digitised forms to designed services. The first wave of public digital work put existing procedures online, which was the right first move and is now largely done. The question has changed to whether the procedure itself should exist in that shape - whether three separate applications are one service, whether a document the entity itself issued should ever be requested from the applicant, whether an entitlement can be granted without being applied for. That is service design and policy work with a technology consequence, not the other way round, and it is where the remaining value is.
Maturity assessment as an executive objective. Digital maturity scoring has moved from a technology concern to an entity-level performance measure discussed at the top of the organisation. Used well, it is a useful forcing function. Used badly, it produces optimisation for the measurement, and the most common thing we are asked to arbitrate is the difference between work that moves the score and work that improves the service. They overlap substantially. They are not the same set.
Cloud adoption inside classification and residency constraints. The direction is settled; the interesting decisions are about which workloads, under what classification, with what residency position and what exit plan. The entities that are moving well decided their data classification first and their hosting second. The ones that are stuck did it the other way round and are now relitigating each workload individually.
Data governance before analytics, and certainly before AI. Interest in applying machine learning to case triage, inspection targeting, fraud and eligibility detection, and citizen contact is genuine and rising fast. The constraint is almost never the model. It is lineage, quality, ownership and the ability to explain an automated decision that affects a person's entitlement to that person and to a reviewing authority. Entities that build the governance first move faster afterwards, not slower.
Shared services rather than parallel builds. There is real and increasing reluctance to let every entity build its own version of the same capability. The pressure is to consume a national or shared platform where one exists and to justify building where it does not - which is a better default, and which makes "what should we own" a more important question than "what should we buy".
Resilience of services declared important. The board-level question has shifted from whether the entity is protected to what happens when a critical supplier or platform fails and whether the entity has proved it can continue operating through that. This pulls exit plans, recovery testing and the mapping of important services onto the agenda, and it is why outsourcing and hosting arrangements now attract more scrutiny than the technology inside them.
Spending quality and local capability. Local content is an evaluation factor in public procurement, and the ambition behind it is capability that stays in the Kingdom rather than a supplier address. Commercially-oriented public entities - the Saudi PIF companies among them - face the same question in a sharper form, because they are expected to operate to commercial standards while remaining accountable to a public mandate, and their technology decisions have to satisfy both.
We start from the decision you have to make, the mandate it has to satisfy and the date it has to be made by - not from a discovery phase with an open end. In a public entity an assessment that takes a quarter has usually cost more in missed procurement windows than it saved in better information.
First, establish what is actually true. The estate as documented and the estate as operating differ in every entity we have worked in, and the difference is the point. We read the service inventory against actual usage - the number of services that exist is always larger than the number anyone uses - the integration inventory, the incident record, the open assessment findings with their root causes rather than their closure status, the committed run cost with its contract renewal dates, and where the knowledge actually sits: which capabilities the entity could still operate if a particular supplier left next month. That record describes an entity's real constraints more honestly than any architecture diagram.
Second, separate the decisions from the noise. Most estates present as dozens of competing problems and resolve into a handful of genuine decisions - which entity owns which data domain, what is consumed from a shared platform versus built here, whether integration becomes a governed layer or stays point to point, what the entity must be able to change itself after handover. Those decisions constrain everything else, and making them explicit is usually the most valuable week of the engagement.
Third, put options in front of you with their costs and their risks - written so they can survive procurement. This is the part that is specific to public clients and it matters more than anything else we do. Requirements have to be specification-neutral and genuinely evaluable, so that more than one capable supplier can answer them and the evaluation can be defended afterwards by someone who was not in the room. A requirement lifted from a product datasheet is a single-source award with extra steps, and it is visible as such in the record for years. Each option carries what it costs to run over several years rather than to buy, what it forecloses, what has to be true for it to work, and how it fails. Our view is stated plainly with the reasoning shown, so you can disagree with the reasoning rather than the conclusion.
Fourth, sequence against the constraints that do not move. The budget cycle, procurement lead times, assessment cycles, and dependencies on other entities whose programmes you do not control. That last one deserves explicit planning rather than optimism: a milestone that depends on another entity delivering an interface should carry a stated fallback, because the alternative is a programme that reports green until the quarter it cannot.
Fifth, stay accountable through delivery, and leave capability behind. Where we are engaged past the decision we work as design authority and assurance - holding the architecture boundaries the decision depended on, reviewing what the implementer is actually building against them, and saying so when the two diverge. We also treat the transfer of knowledge to your own team as a deliverable with an acceptance test, because in the public sector an outcome that cannot be maintained after the contract ends is not an outcome. The decision-rights and operating-model side of this is set out in IT strategy consulting.
We work in capability categories rather than product names, because the right answer depends on the estate you already have and on what a shared platform already provides, and we would rather not imply a shortlist we have not built for you. The categories below are where public sector engagements in the Kingdom concentrate.
Citizen and business service delivery. The portal, the mobile channel, the application and case lifecycle behind them, appointments, notifications and payment. The decisive design question is not which portal product to buy; it is whether the service logic lives in the portal or in a service layer the channels consume, because that single answer determines whether the next channel costs a project or a configuration.
Government resource planning. Budget preparation and execution, finance, procurement, contracts, human capital, payroll and asset management, together with the integration into national financial and procurement platforms that turns them from internal record-keeping into compliant transactions. The usual failure here is treating the national platform integration as an interface at the end rather than a constraint at the start.
Licensing, permits, inspection and enforcement. The regulatory workload of a great many public entities: applications, eligibility, field inspection, case management, sanctions and appeals. These are workflow and data-quality problems, they are very poorly served by generic tooling, and they are where risk-based targeting produces the clearest measurable gain once the data underneath is trustworthy.
Integration, API management and identity. The governed interface layer, the management of the interfaces the entity publishes to others, and consuming national identity rather than maintaining another credential store. An entity that builds its own login when a national one is available has taken on a permanent liability for no benefit.
Data platform, classification and reporting. The warehouse or lakehouse, the data governance, classification and lineage that make its outputs defensible, and the reporting that goes to leadership and to central bodies. Success here is not a dashboard. It is that two directorates and the central report agree on the same number and someone can show why.
Cybersecurity, governance, risk and compliance. Control implementation across the estate rather than per system, identity and access management, resilience of services declared important, and the continuous evidence that turns an assessment from a project into a report you can run.
The practices below are the ones public sector engagements draw on most. Each page sets out how we work in that area rather than restating this one:
Independence is claimed by nearly everyone selling advice, so it is worth being specific about what it means here, why it matters more in public procurement than anywhere else, and where its limits are.
The requirement document is the decision. By the time bids are evaluated, most of the outcome has already been determined by how the requirements were written. Requirements drafted by a party that intends to bid, or lifted from one product's feature list, narrow the field before the field is invited - and the entity then runs a scrupulously fair evaluation of a competition that was already decided. An adviser who will not bid can write requirements that several capable suppliers can genuinely answer, which is what produces both a better price and a better result. This is the core of the argument, and everything else follows from it.
We do not earn a margin on your licences. An adviser whose revenue rises with the size of the implementation cannot credibly tell you the implementation should be smaller. We can, and it is frequently the advice - that the platform you already own covers the requirement, that the module being proposed solves a problem you have not got, that a shared national platform already provides this and building it again would be a decade-long liability.
A decision that survives the record. In a public entity the procurement file is read again - by internal audit, by an oversight body, and by whoever inherits the contract after you have moved on. A process whose criteria were written after the shortlist existed, or whose weightings were adjusted to produce a preferred answer, is visible in that file. Running the evaluation independently of anyone who benefits from its outcome is what makes it defensible, and that is a governance argument at least as much as a commercial one.
Someone who can disagree with the incumbent. An independent design authority does not replace a long-standing integrator or displace its institutional knowledge. It restores the second opinion that a single-supplier arrangement removed, which is the thing that lets you judge whether an estimate is reasonable before you commit public money to it.
And the limits, stated honestly. Independence is not omniscience - we will not understand your mandate, your regulations or the people you serve better than your own staff do, and an engagement that proceeds as though we might is one that has gone wrong. It is also not the same as having no interest: we sell advisory work, and where we hold a partnership or accreditation with a vendor it is published on our partners page rather than implied in copy. Ask us directly whether we hold one with any supplier you are evaluating, and ask every other adviser bidding the same question. It should have a straight answer.
There is no case study on this page, and the reason is not modesty. This heading was drafted for a page that would tell a story about a named or lightly disguised public entity. We are not going to write one, because the only two ways to fill this section are both bad.
Naming a public entity and describing its estate needs that entity's specific permission for that specific purpose, routed through its communications function and usually through the owner of the mandate the work sat under. The detail that would make the story useful - what was failing, what an assessment had found, what the migration actually cost - is precisely the detail that does not get cleared, and some of it touches classification questions that make publication inappropriate regardless of willingness. Where a client has agreed, the account is on our success stories page with the detail they approved.
The alternative is the anonymised composite - "a leading government entity" - and it is worse than an empty section. That construction permits any claim at all, because no organisation exists that could contradict it, and a reader has no way to distinguish a real anonymised engagement from an invented one. It is common in this sector for exactly that reason, and its prevalence is an argument against trusting it rather than for using it.
What we will do instead is more useful and costs you an hour. In a first conversation we will talk in specific detail about work of a shape close to yours - what the estate looked like, where the real constraint turned out to be, what we recommended, what went wrong that we did not foresee, and what we would do differently - within the confidentiality each client is owed. If an adviser cannot do that, or can only describe engagements that went well, you have learned something important about them.
In the entities we see in the Kingdom, five recur. Multi-year programmes funded one year at a time, so scope is shaped by the allocation rather than by the next coherent increment. Procurement lead time left out of the delivery plan, which quietly consumes the part of the year that later shows up as a slip. Cross-entity dependencies that the programme does not control and has not planned a fallback for. Capability contracted in and lost at go-live, so the entity cannot change its own platform afterwards. And a compliance burden whose cost sits in evidencing controls to several authorities on different cycles rather than in operating them. They compound: the data problem inflates the compliance cost, and the capability problem removes the people who would fix either.
Fewer than are usually proposed, and materially fewer than an entity needed a few years ago, because more of the stack is now available as a shared or national capability. Most entities need a way to deliver and track services to citizens and businesses; a resource planning core for budget, finance, procurement and human capital that integrates with the national platforms; a governed integration layer and consumed national identity; a data platform with classification and lineage sufficient to defend its own reporting; security and compliance tooling that evidences controls continuously; and, for regulatory entities, case management for licensing and inspection. What varies is how much of that is separate software rather than capability inside something you already own or can consume. Two cautions worth more than any product recommendation: do not build what a shared platform already provides, because you will maintain it forever for no advantage, and be alert to buying the same capability twice - workflow in the portal and in the case system, identity in three places - which happens whenever nobody decides which system owns the decision.
We are not going to publish a figure. Duration in a public entity is set by the procurement cycle, the budget calendar, the readiness of the other entities you must integrate with, data migration and cleansing, and the availability of a small number of people who understand the existing systems - and those vary so widely that any number here would be marketing rather than information. What we can offer is how to read an estimate you are given. Ask whether it begins at the decision or at contract signature, because the gap between them is real elapsed time. Ask what proportion is data migration and cleansing, and treat a small number there as evidence the estimate has not been done. Ask which milestones depend on another entity, and what the plan is if that entity is late. Ask whether knowledge transfer, parallel running and the decommissioning of what is replaced are inside the price, since all three are routinely excluded and routinely turn out to be where the time went. And ask which named individuals are committed to your dates rather than pencilled against them.
At the level of institutions rather than clauses: the Digital Government Authority regulates government digital work and assesses digital maturity; the National Cybersecurity Authority sets the national control baseline with additional requirements for systems classed as critical; SDAIA and the National Data Management Office govern data management and classification alongside the Personal Data Protection Law; the Communications, Space and Technology Commission governs cloud arrangements; the Government Tenders and Procurement Law and the national procurement platform govern how technology may be bought; and local content obligations apply to the award itself. Treat this as a map of who asks, not as a statement of what is currently required - specific obligations, thresholds and dates change, they are your own legal and compliance function's to confirm against the current published text, and any sector page that tells you otherwise is one you should trust less rather than more.
Yes - and this page deliberately does not quantify that, because a client count on a web page is unverifiable and therefore worthless to you as evidence. The honest answer is the one you can check: ask us, in a first conversation, for engagements of a shape comparable to yours, for the named individuals who would be on your programme and what they have personally delivered inside a public entity, and for a reference call with a client who will take it. We will approach a suitable client and put you in touch directly if they agree. Published work our clients have approved is on our success stories page.
There are no numbers in this section, and that is the point. The heading was drafted for a page that would publish a count of public sector clients, a number of services digitised and a set of improvement percentages. We will not write figures we cannot evidence to you on request, and you have no way to tell a real one from an invented one - which is exactly why the invented ones are so common in this sector, where a claim to have moved an entity up a maturity ranking is simultaneously unfalsifiable and extremely persuasive.
More useful than our numbers is knowing which numbers to demand, of us and of everyone else bidding. Ask for these in writing and treat a refusal as information:
Named engagements of your shape, with the client contactable. Not a count but a list you can check, at comparable mandate, scale and service complexity. One reference call with the programme lead who lived through the delivery is worth more than any aggregate on any page.
The baseline behind every improvement claim. A percentage means nothing without what it was measured against, over what period, and who measured it. Ask whether the baseline was recorded before the work started or reconstructed afterwards. In this sector it is very often the latter.
What the entity could operate afterwards without them. The public sector question private clients rarely have to ask. Which capabilities transferred, who holds them now, and what the entity has changed on its own since handover without raising a variation.
The engagements that went badly, and what changed afterwards. Every firm with real experience of public programmes has ones that hurt. An adviser who cannot name one has either not done enough of this work or is not telling you about it.
The named individuals on your programme and their availability. Firm-level experience is not what turns up on site. Ask who specifically, what they have personally delivered in a public entity, and whether they are committed to your dates.
How the adviser is paid, and whether they will bid. Whether they earn on the licence or the implementation as well as the advice, and whether they intend to compete for the work their own requirement document will define. We do not earn a margin on your licences; put the same question to everyone else.
Where our clients approve publication, their results appear on our success stories page with the detail they approved. That page, not this one, is where our record lives.
Organisations across several sectors in the Kingdom have engaged us on selection, architecture and assurance work. We name a client only where that client has agreed to be named for the specific purpose, and in the public sector that permission is rarer and slower than elsewhere for entirely rational reasons: approval usually runs through the entity's communications function and the owner of the mandate the work sat under, and the engagement often touches an open assessment finding, a classification question or a platform decision the entity has not yet announced. A logo published without a current permission is a breach of confidence dressed up as marketing, and an entity evaluating advisers should notice that a firm careless with somebody else's confidentiality will be careless with theirs.
The organisations who have agreed are on our customers page, which is maintained against those permissions rather than assembled for this page. If you would like a reference from an entity of comparable mandate, size or service complexity, ask during a first conversation - we will approach a suitable client and put you in touch directly if they agree, which is worth considerably more than a grid of logos.
Our published project record is on the success stories page. It carries the engagements our clients have approved for publication, with the detail they approved, and that is the honest extent of what we can show a stranger on a web page.
It is worth saying what that page is not. It is not a complete record of our work, because most clients in regulated and public sectors do not publish. It is not weighted towards government, for the same reason. And it deliberately contains no anonymised composites, so the absence of a story matching your situation is not evidence we have not done that work - it is evidence the client concerned did not agree to publish it. Ask us in a conversation; the constraint is publication, not disclosure to a prospective client under an appropriate agreement.
Client feedback we have permission to publish appears below this page's content and on our customers and success stories pages. There is no quotation written into this section, and the absence is deliberate: we do not publish a client quote until the client has reviewed and approved the exact wording attributed to them, for the specific place it will appear. In the public sector that approval is a formal step rather than a courtesy, and a testimonial drafted by a marketing team and attributed to a job title is not evidence of anything. A reader cannot tell one from the real thing, which is precisely why the real thing is worth protecting.
If what you actually want is to hear from somebody who has been through this decision, ask for a reference call - ideally with the programme or operations lead rather than the executive sponsor, because they are the one who lived through go-live and the first assessment after it. It is a far better test of an adviser than any quotation, and it is one we are happy to be put to.
Our current vendor relationships, accreditations and the certifications our consultants hold are published on the partners page. We keep them there rather than restating them in sector copy for a practical reason: partner tiers and individual certifications change, and a page asserting a status it can no longer stand behind is worse than one that does not assert it at all. Treat that page as the current answer, and ask us directly about any platform you are evaluating.
Because "is this firm qualified" is the question public buyers ask most often and verify least, here is what we would check - about us or about anyone else bidding. Ask for the certifications of the named individuals who will be on your programme rather than the firm's aggregate status, and ask whether those individuals are committed to your dates. Ask who on the team has personally delivered inside a public entity, which is a materially different experience from delivering the same technology commercially, because the procurement, assessment and accountability constraints are not incidental to the work. Ask for a reference from an engagement of comparable mandate, ideally one that went less than smoothly, and ask what was done about it. Ask how the commercial relationship works - whether the firm earns on the licence or the implementation as well as the advice, and whether it intends to bid for the work it is scoping. And ask what handover looks like, and what your own people would be able to change afterwards without calling anyone. A firm that answers those five without flinching tells you more than any badge.
Public sector technology decisions rarely sit on their own, so the pages below are the ones that most often get read alongside this one. Each covers ground this page only touches:
A first conversation is an hour with people who have done this work, not a sales presentation. Bring the mandate you are working to, the decision you are facing and the constraint you think you are under; we will tell you where we think the real constraint is, what we would want to see before advising properly, and whether this is work we are the right firm for. Sometimes it is not, and saying so early is cheaper for both of us than discovering it in a proposal.
If a procurement is already in motion, say so at the start. There are points in a public process at which it is not appropriate for us to be in a conversation at all, and it is our job to recognise those and withdraw rather than yours to manage around us.
It is also a fair opportunity to test us on everything this page has asked you to demand of an adviser - the named individuals, the reference call, the engagement that went badly, what capability you would be left with, and how we are paid. Those questions are on this page because we expect to be asked them.
Request a public sector consultation, or ask us for a reference from an entity of comparable mandate and scale before you commit to anything.
We are delighted to list trustangle as our technology partner of choice. With their hands-on support, we successfully executed our digital transformation journey, moving from pen and paper to advanced technology. NetSuite by Oracle is now fully integrated with our POS, inventory, and HR systems.
We are thrilled with our partnership with trustangle and Onfleet, which enabled us to build an advanced logistics system from day one. Their extensive technical expertise helped us avoid common issues in the logistics sector and ensured an exceptional customer experience, allowing us to achieve impressive numbers effortlessly.
Working with trustangle team has been transformative for Foods Gate company. Their expertise in implementing NetSuite ERP, Reachware Connect, Reachware Extend & Reachware Fatoora, as well as Revel POS, has truly transformed our operations. The seamless integration of these solutions has streamlined our processes, improved efficiency, and provided us with invaluable insights. trustangle team’s commitment to delivering tailored solutions and their exceptional support have significantly enhanced our business capabilities.
We are thrilled with our partnership with trustangle and Onfleet, which enabled us to build an advanced logistics system from day one. Their extensive technical expertise helped us avoid common issues in the logistics sector and ensured an exceptional customer experience, allowing us to achieve impressive numbers effortlessly.
لقد كان تحويل عملياتنا ف ي فندق وأجنحة تايم رب اترست آنجل استطعنا أن ننفذ مجموعة من األنظمة التقنية الجديدة الت ي عززت كفاءتنا وحسنت تجربة ضيوفنا بصورة ملحوظة. إن الت ام ترست آنجل بالجودة والحلول االبتكارية يعد عالمة فارقة ف ي هذه الصناعة، كما يضيف .قيمة عظيمة ألعمالنا
Our experience with trustangle in implementing Oracle NetSuite for our food business was extremely positive. Their team showed deep understanding of the food and restaurant industry, along with strong technical expertise in NetSuite. They designed a scalable solution that supports our daily operations while allowing us to grow confidently. Beyond the system setup, trustangle guided us through best practices and change management, making the transition smooth and effective. NetSuite, implemented by trustangle, has become a solid foundation for our ongoing digital transformation.
Partnering with the trustangle team has revolutionized our operations at OAK Village NEOM. Their flawless implementation of Shiji PMS, Shiji Infrasys Ltd POS, Reachware Fatoora, and Reachware Connect has enhanced our efficiency and elevated the guest experience. Their professionalism and unwavering commitment to our success have been nothing short of extraordinary.
Working with trustangle changed the way we manage our retail and e-commerce operations at Karaz Linen. The team understood exactly what we needed: a connected omnichannel experience with faster and more accurate order handling. With Omniful and Reachware Integration, our retail stores and online business now run through an automated order management process, giving us better visibility, faster fulfillment, and a smoother customer experience. trustangle delivered real business value, not just technology.
trustangle team has exceeded our expectations with their seamless implementation of Reachware Extensions (Basher HR & Extend), Microsoft Office 365, and NetSuite ERP. Their professional approach and deep understanding of our needs ensured a smooth transition and led to immediate improvements in our operations. trustangle’s commitment to delivering high-end quality solutions has been invaluable to our business.
We are thrilled with our partnership with trustangle and Onfleet, which enabled us to build an advanced logistics system from day one. Their extensive technical expertise helped us avoid common issues in the logistics sector and ensured an exceptional customer experience, allowing us to achieve impressive numbers effortlessly.
Shiji Infrasys has completely transformed our operations at JW Marriott Saudi. Their cloud-based POS system is incredibly efficient, allowing us to enhance our guest experience in ways we never thought possible. With seamless transactions and real-time insights, we’ve redefined how we serve our clients. The value added to our hotel is undeniable, Shiji has truly set a new standard in hospitality!
trustangle Solutions have been a great partner for our business. The comprehensive suite of solutions they offer has allowed us to improve our customer experience, increase operational efficiency, and gain better customer insights. Their data-driven approach enabled us to optimize our strategies and resources effectively.
Working with trustangle team has been an absolute pleasure. The systems they provided worked flawlessly for our business, eliminating disruptions and enabling efficient operations. Access to the latest technology saved us time and money, and their customer service was top-notch with extremely fast response times.
I would like to share my experience working with trustangle team on the implementation of Fiix software at Siniora. From start to finish, the team was exceptional in their knowledge, attention to detail, and customer service. The software was seamlessly integrated, resulting in significant improvements in efficiency and productivity.
It gives me great pleasure to announce the successful launch of NetSuite ERP at Al Jabr Soft Drinks – Rita Drinks. The trustangle team demonstrated exceptional knowledge and determination, helping us grow rapidly. trustangle has proven to be a trusted technology partner, and we highly recommend their solutions and services.
The market lacks professional IT software providers who offer full support like trustangle. I advise companies to consider trustangle as a strong technology solutions provider capable of addressing real business challenges.
Having the versatility of an all-encompassing ERP solution like NetSuite was far better than running separate systems—it can do pretty much anything.
We at Golf Saudi are pleased with the systems and technological solutions provided by trustangle, which supported our journey toward Saudi Vision 2030 while delivering a seamless customer experience. trustangle has proven to be a reliable technology partner, and we highly recommend their solutions across sectors.