IT consulting is for companies where the price of a technology mistake exceeds the cost of the review: before a large purchase or a development project, when systems have to be joined up after growth, when a regulator sets new requirements. Company size is not the deciding factor — what matters is how many systems are in use, what their downtime costs and who decides on IT.
Key takeaways
The trigger rarely looks like a technical fault; it looks like a management dead end: a decision has to be made and there is nothing solid to base it on. These are the signs people usually arrive with.
What a consultant actually does with such a task, how the project runs and which documents stay with the company is covered in our article on what IT consulting is and how the work runs.
There is a simple test: if the manager cannot confidently answer at least one question on the list, the company has no picture of its own IT and decisions are being made blind.
An answer of "I do not know" to the first two questions calls for a process review, and to the rest for an infrastructure survey. How losses are put into money is shown in our article on the business audit.
Whether a review is needed is decided not by headcount but by four things that are easy to measure. A fifteen-person company with three integrations and online payments depends on IT more heavily than a two-hundred-person factory running on paper.
These four figures are worked out before any conversation about specific systems. Until the cost of an hour of downtime is known, an argument about the IT budget stays an argument about taste: one person finds a support retainer expensive, another finds it cheap, and there is nothing to compare it against.
The wording differs, but the same question sits behind it: what to fix first. The table shows the typical tasks and what shapes the requirements beyond the wishes of the business.
| Industry | Typical task | What shapes the requirements |
|---|---|---|
| Manufacturing | Cost of goods and stock levels are calculated by hand and late | Batch and shift accounting, exchange with the warehouse and accounting |
| Logistics and delivery | Orders live in messengers and only the dispatcher knows their status | Routes, statuses, customer notifications, courier work from a phone |
| Healthcare | Appointments, patient records and equipment sit in separate systems | Biometric and genetic data are stored in Uzbekistan — article 27-1 of the personal data law |
| Banking and fintech | A new service has to launch without breaching data protection rules | Minimum information security requirements for banks — Central Bank regulation No. 3669 |
| Retail and services | Enquiries from several channels get lost and repeat sales rest on what managers remember | A single intake for enquiries, stock accounting, exchange with the till and accounting |
| Energy, transport, telecoms | The systems fall under critical information infrastructure | The law on cybersecurity, ZRU-764 and the requirements of the authorised body |
Industry specifics change the requirements and the priorities but not the order of work: facts and figures first, then options, then the budget.
A review is not a universal answer, and in four situations it only delays the work and spends money.
The line between review and operations is described in our article on technical support for IT infrastructure, along with the scope of work and what gets written into the contract.
An outside review neither replaces the in-house team nor tests its competence: the two do different jobs. Internal specialists keep the infrastructure running and know its history, while external ones bring comparison with other companies and carry the uncomfortable conclusions.
Mistake Commissioning the review behind the IT department's back. Staff find out at the first interview anyway, and from there they defend their work instead of describing real processes, so the quality of what is collected drops. It is fairer to announce it in advance: what is being reviewed is processes and systems, not people.
Where there is no in-house team at all, the role usually falls to the manager or to an employee who looks after the systems alongside another job. Then it matters more than usual that access and documentation are registered to the company rather than to a person: otherwise the project leaves when they do.
Half the quality of a review is decided by what the company assembles before the first meeting. The more facts are ready, the less time goes on rebuilding the picture.
If those six items cannot be assembled, that is a finding in itself: the company has neither an inventory of its systems nor a clear owner of the IT budget. In that case the review starts with the inventory, and the first findings appear before the interviews do.
We do not sell IT consulting as a separately priced service — there is no such line on our site. The same question is closed by work from the service pages, and it makes sense to start with the narrowest: it answers sooner and costs less.
We start with a narrow question and a single process rather than a survey of the whole company: the first result arrives sooner and shows whether it is worth going further. Where an in-house IT specialist already exists, we work alongside them — operations and access stay with them, while comparison with other projects and turning the decision into documents stay with us.
We name our own interest up front: Syntra Systems builds systems, which means every recommendation we make has a side on which we earn. So the findings that close with settings in software already paid for and with changes to the rules are marked separately in the review — they can be closed without us.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
It does where the business already depends on systems: online payments, several intake channels, integrations, stock. A fifteen-person company with that stack carries more risk than a large enterprise running on paper. Where the processes are simple and fit in one spreadsheet, a review adds nothing.
With the single process closest to the money: taking requests, shipping, invoicing. A narrow review gives an answer sooner and costs less — a $400 AI process audit ends with a list of processes and an implementation plan, which shows whether it's worth going further.
Say it in advance and plainly: what is being reviewed is processes and systems, not people. It helps to define the in-house team's role from the start — it supplies context and the history of decisions, grants access and takes part in writing the documents. A secret review always ends in self-defence instead of real description.
That is a workable starting point: the spreadsheets show which fields and statuses the company genuinely needs. The review starts by describing how the work runs today and usually ends not with the most sophisticated system but with the one closest to the current process, so the team actually adopts it.
A contractor in a sales conversation answers how their product will close your task; a review answers which solution is needed, including the option of buying nothing. These are different roles, and combining them works only in the open — when the supplier states their interest and shows the options where their own work is not required.
We have no single priced service for this — it's covered by narrower work: a $400 AI process audit, system support from $700 a month with a system inventory and a monthly report, or ongoing project development from $1,500 a month if you have a backlog of work and no in-house dev team.
