We build an arrangement in which faults and requests arrive through a single record rather than through a messaging app, a corridor conversation or a phone call. Every request is prioritised, has a clear owner and a measured resolution time. We run the same structure not only in IT but also for human resources, administrative affairs and maintenance requests. That is what enterprise service management (ESM) means.
In a factory, the IT team's day usually goes like this: in the morning someone's printer stops working, towards noon a terminal on the production floor freezes, in the afternoon an email arrives from the accounts department, and at the end of the day a manager catches you in the corridor and asks for a favour. Requests come in through four separate channels and none of them is recorded. When the day is over, nobody has a record of what was done, which job was left half-finished and who is still waiting. The next morning the forgotten request comes back, this time as a complaint. The team works hard but cannot show that it works. When one more member of staff or a new server is asked for at the end of the year, not a single figure can be found to support the request, and that is usually why the budget is refused.
The second problem is that priority is set by whoever has the loudest voice. A fault that stops the production line and a request for a graphics card join the same queue; which of them gets done first is decided according to whoever happens to be in the room at that moment. The third is that the solution stays with the individual: even the sixth time the same error occurs, how it was resolved is not written down anywhere, and if the person who knows that job is on leave, the work waits. The fourth is that changes are made without notice. A server is updated, a software version is released, then an unexpected problem starts on the production floor and nobody remembers what changed. These four problems share the same root: the absence of a record. Because there is no record, priority cannot be set, knowledge cannot be shared, and nobody can look back and see what changed and when.
IT service management (ITSM) is the approach that treats the work IT does not as scattered jobs but as services. Every request and fault becomes a record; it is classified, prioritised, assigned to an owner, and its resolution time is measured. Recurring faults are linked to a problem record so that the root cause can be investigated; changes to be made to systems are planned and logged in advance; frequently asked questions are written into a knowledge base. The help desk, a term used just as often in Turkish as in English, is the first tier of this structure: the place where the request is received and simple fixes are given. ITSM covers the whole process around the help desk. Enterprise service management (ESM) is the same engine carried beyond IT: internal requests reaching human resources, administrative affairs, maintenance and quality units also run on the same logic of records, priorities and timings.
Let us draw the boundary from the start. Field service management (FSM) is often confused with this system, but they are different: FSM manages the route of the technician who travels to the customer, the mobile work order, the parts used and the warranty coverage; the system here is mainly an internal service desk. The two can be connected, but they are not the same thing. The second point of honesty is this: there are mature off-the-shelf ITSM products on the market, and if your need is a standard one, the right decision is most often to use one of them; we say so plainly. Custom development makes sense if your request flow is embedded in your production processes, if you have flows of your own on the ESM side, or if the data must not leave the organisation. We make that assessment together during discovery and share the outcome openly, whatever it turns out to be.
Teams of a few people looking after a large user base and production systems at the same time. The real gain here is that requests are not lost and that what gets done first is beyond dispute. The second gain is that the workload becomes measurable; investment and headcount requests can for the first time be based on figures, discussed by looking at records rather than at guesswork.
Companies with branches, warehouses or separate facilities that also need support on the night shift. Which location a request came from, who is on duty at that hour and how the handover is to be made are all defined in the system. Information that would otherwise be passed on verbally at shift handover is handed over together with the open records; nobody has to go looking in the morning for where a job that started at night was left.
Structures where internal requests such as leave, asset assignment, vehicles, catering, shuttle services and purchase requests run over email and messaging. With the enterprise service management (ESM) approach these requests also run on the same engine, with their own forms and approval tiers. The employee raises a request from a single place and does not need to know which unit it goes to.
Firms working in software, automation or technical service that provide support to third parties under a service contract. Here the service level commitment is contractual; response and resolution times have to be measurable and reportable. A customer portal largely removes the need to phone and ask about the status of a request, and makes sure that at contract renewal you have an indisputable performance record in hand.
A request can be raised through the web portal, by email, from a QR code on the machine, or by the team on behalf of a user who calls in. Whatever the channel, the outcome is the same: a numbered record. Users see the status of their own requests and do not have to ask again. Accepting no work outside the record is the single condition for the system to function, and we discuss that from the outset.
Every request is classified by type; priority is set by assessing the breadth of the impact together with the urgency. A fault that stops the production line and a request affecting a single user do not join the same queue. Thanks to defined rules, a request goes straight to the relevant team or person according to its subject and location; no one is needed to distribute records by hand all day long.
Response and resolution time targets (SLAs) are defined by request type and priority. The clock starts running, records approaching the target raise a warning, and records that breach it are escalated to the next tier. Measurement takes working hours, the shift pattern and public holidays into account; time spent waiting for information from the user is kept separate. If you serve external customers, the same measurement becomes the basis for contract reporting.
Knowledge base articles are produced from resolved records; when a similar request is raised, the relevant solution is suggested and users can resolve some problems themselves. Faults that keep recurring are gathered under a single problem record and their root cause is investigated, instead of each one being closed separately. That creates the chance to remove the cause rather than do the same job for the sixth time.
Work such as server updates, version upgrades and network changes is logged in advance, the affected systems and the rollback plan are written down, it is submitted for approval and placed in a maintenance window. The change calendar is open to everyone. When a problem occurs, you have a list of what changed in that period to hand; this is the step that saves the most time in fault-finding.
Separate service catalogues and forms are defined on the same engine for human resources, administrative affairs, maintenance and quality units. An asset assignment request, a vehicle request, a facility fault or a document request is also numbered, prioritised and timed. Each unit sees only its own records; the employee raises a request from a single place.
Requests are related to devices, users, locations and systems, so it becomes visible which device keeps causing trouble and which system generates the most requests. Management reports show the number of records opened and closed, the average resolution time, the category distribution and SLA compliance. These reports become the basis for headcount and investment decisions.
We work out together which requests come in, who they come from, which channel they arrive through and how they are resolved today. A service catalogue emerges from this work: for the first time, the services IT actually provides are written down. Discovery usually takes one to two weeks, and this step also sets the scope of the project.
The impact and urgency matrix, priority levels, target times, the working calendar and the escalation tiers are agreed together with management. This step is managerial rather than technical, and it is the hardest part to change later, because it directly sets the teams' expectations. We do not move on to development until the rules are approved in writing.
The request portal, email intake, notifications, authentication and asset links are set up; a working version is shown at short intervals. The first usable version usually appears within six to ten weeks, depending on scope. The aim in that version is not to build every process at once but to run the request flow properly from end to end; problem and change management are left until later.
We start with a single location or a single unit. During this period the solutions to the most frequent requests are written into the knowledge base, forms are simplified and the priority rules are tested against real records. The purpose of the pilot is to build the confidence of both the team and the users in the system; the scope is extended to other units only once that has been achieved.
All locations go live, reports are opened up and, if you wish, human resources, administrative affairs and maintenance requests are moved into the same system. Change management is added at this stage. After that, new service types, rules and integrations are built into the system under the maintenance scope. The source code, the database and the accumulated request history remain yours.
For most companies the off-the-shelf product is the right decision, and we tell you so plainly; developing software from scratch to meet a standard service desk need is unnecessary cost. Custom development makes sense in these situations: if your request flow is embedded in your production or quality processes, if data must not leave the organisation, if the licence cost tied to user numbers has become unsustainable, or if your flows on the ESM side do not fit the templates of off-the-shelf products. We make this assessment together during discovery.
No. Field service management is about the work of the technician who travels to the customer: appointment and route planning, the mobile work order, the spare parts used, warranty and contract coverage, the customer's signature. The system here is an internal service desk: the record, priority, timing and resolution of the requests and faults raised by employees. Connecting the two systems is possible, and in some firms necessary, but setting one up and counting it as the other does not work.
This is where service desk projects most often get stuck. Two things must be done together. First, raising a request must be easier than sending a message: a short form, a record opened from a QR code, an email turning directly into a request. Second, management has to be firm about not accepting work without a record. In our experience, simply installing the software and waiting for the habit to change by itself does not deliver results.
ITIL is not a product but a good practice framework; rather than claiming that a piece of software conforms to it, we prefer to say which processes have been set up. In practice we set up incident, request, problem, change and knowledge management to the extent you need. A mid-sized manufacturing company does not need to apply the whole framework; a process setup heavier than necessary is one of the most common reasons teams abandon the system.
That concern is fair, and the answer depends on how the setup is done. In the first period the time targets run for measurement purposes, with no obligation to act; once we have real data, the targets are set together. Targets are set by looking at current performance rather than imposed from above. Measurement also works both ways: excessive load, understaffing or a constantly recurring fault become visible in the same reports.
A written service catalogue; multi-channel request intake and a single numbered record system; priority based on impact and urgency together with automatic assignment rules; SLA measurement and escalation; a knowledge base and problem records; change management and a maintenance calendar; if you wish, human resources and administrative requests running in the same system; and management reports. The source code and the data belong to you.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
Who is using which computer, phone, server and network device, which licence expires when, which subscription quietly renews itself: we gather all of it into a single record system. Assignment, warranty, the renewal calendar and decommissioning run in the same system; the inventory moves out of personal memory and into the organisation's records.
Details →We tie risks to their owners and place a control, and the evidence for that control, against each risk. Policies run under version control, audit findings are tracked to a deadline, and a regulatory change lands with the right person. Work on personal data, occupational safety and the environment is read from a single dashboard under the same roof.
Details →We break projects down into a work breakdown structure, make resources and capacity visible, and put budget and actuals side by side. Milestones, risks and decisions sit in the same record; management reads the whole portfolio from a single dashboard and discusses which work comes first by looking at data.
Details →We design and build internal systems and subscription-based SaaS products that run in the browser, sit behind secure sign-in and show content according to role and permission. We shape them around how your business actually works, and we share the source code with you.
Details →We bring your field, sales and customer-facing work into a single app. We design iOS and Android applications around your needs, build them with offline mode and push notification infrastructure, and publish them on the App Store and Google Play.
Details →Desktop applications that keep going even when the internet drops, connect directly to barcodes and local hardware, and run fast on the shop floor and in the office. For Windows and macOS, with the source code yours.
Details →
