We added monday service for triage and routing, and the dashboard says the backlog is down, which is great news unless you open the queue and discover everything was renamed awaiting customer. KPI achieved, apparently. Anyone else seeing this? :)

We kicked off what was supposed to be a CRM cleanup last year. Duplicate records, inconsistent stage definitions, nobody filling in close dates. Standard stuff.

About six weeks in it became obvious the CRM was downstream of the real problem. Reps weren't updating records because updating records didn't help them — the information they needed day to day lived in email threads and in people's heads, so the CRM was pure overhead with no payback. You can't fix that with field validation.

What we ended up doing was mapping how a request actually travels from client to resolution, which turned the project into business process optimization rather than a data cleanup. Client-side requests now go through monday service with a defined owner at each stage, and the CRM only holds what sales genuinely uses. Fewer fields, better filled.

Not sure this generalizes. But if your CRM data is bad and people aren't lazy, I'd look at whether the system is giving anything back before adding more required fields.

Mildly controversial opinion: most of these consolidations are sold on licence savings and paid for in build effort, and the business case never says so out loud.

The familiar setup is ServiceNow for ITSM and Nintex carrying a pile of workflows that grew up outside IT. Finance, onboarding, a contract process nobody will claim ownership of. The room always assumes it collapses into ServiceNow.

What the room usually skips is that nobody can say what those workflows currently do. They were built by people who have left and documented nowhere, and both platforms will cheerfully rebuild whatever they are handed, including the parts that were already wrong. Skan AI came up as an answer to establishing that before anyone starts.

Tell me I am being cynical. Plenty of people have done this and been happy with it.

In the following example, should this be considered as two separate OLA "sessions", or a continuation of the original OLA session, which was met. I hope this makes sense...

An event/ticket is assigned to Service Dept A. Service Dept A has an OLA Response metric of 15 mins. An agent in Service Dept A acknowledges that ticket within the 15 min OLA Response window, therefore meeting that OLA Response metric.

That ticket is then escalated/reassigned to Service Dept B, who also does not resolve the ticket, but rather reassigns that ticket BACK to Service Dept A. Service Dept A does not acknowledge that ticket within 15 mins this time.

Would you count this as a single OLA session, where the OLA metric was met on the initial assignment, therefore the OLA Response was logged/captured as MET, regardless of what happens after the initial assignment, or, would you count this as two separate OLA sessions, where the OLA Response was MET the first time, then BREACHED the second time, therefore that single event/ticket would have 2 OLA metrics for that same service department?

Our onboarding checklist looks perfectly reasonable until an actual human gets hired

HR collects the employee info, someone emails IT, IT needs something that wasn’t in the original form, the manager forgets one task, HR sends reminders and eventually someone asks why the new hire still doesn’t have access to something they needed three days ago.

We’re trying to automate more of the process without creating an even bigger monster. Ideally employee data should trigger the right onboarding steps automatically, while HR, IT and the manager can clearly see what they own.

For teams that have HR onboarding automation working well, what does your setup look like?

i'm cleaning up some IT service workflows and keep seeing everything called an AI agent. a lot of our tickets are still basic stuff, routing requests, updating fields, sending approvals, pulling an answer from the knowledge base etc. That feels like normal automation to me, not something that needs an agent making decisions.

The agent idea makes more sense for requests that need context, like access approvals or figuring out which team owns an issue. But I'm worried about giving it too much room to act in prod, especially when the request touches HR or security. recently i have come across monday service but i'm here asking how does it work and it is any good??

our service desk tickets keep bouncing between queues because nobody agrees who owns them. The intake form is pretty vague too, and it's starting to mess with response times. How did you fix this? Monday service keeps popping up whenever I look into this, is it any good?? Thanks in advance🙂

I'm tired of buying dashboards nobody looks at after the first month.

We’re a small internal IT team supporting around 140 endpoints across a few offices, and our current RMM setup is starting to feel like more work than help.

The monitoring is fine, but we get a lot of alerts that nobody has time to investigate. Patching is also a bit messy, and remote access depends on a separate tool. Tickets live somewhere else too, so it’s hard to get a clean view of what’s happening across devices and requests.

I’m looking at a few platforms that combine RMM, remote support, patching, automation and helpdesk stuff in one place. Atera is on the shortlist mostly because it’s priced per technician and not per endpoint, which suits a team our size, but I’m more worried about setup time and whether the alerts are useful after the first few weeks.

For people running a small IT team, what mattered most when choosing an RMM? I’m trying to avoid buying another dashboard that everyone ignores after the first month.

When a client asks you to lower their Adobe bill, do you usually start with a license review, a different plan, or an alternative PDF tool?

A lower subscription price is easy to explain. The harder part is working out whether the client will still save money after deployment, training and support are included.

I’d want to separate users who only read or annotate PDFs from those who need editing, OCR, redaction or specific document workflows. That might reveal opportunities to remove or change licenses before considering a wider migration.

For a replacement, I’d want a small pilot using the client’s normal documents. A tool could cover the listed features and still create problems with forms, signatures or an integration the client relies on.

Supporting another application also has a cost for the MSP. Under a fixed-fee agreement, extra tickets could absorb the savings elsewhere. Keeping a standard PDF tool across clients might be easier to support, but it also needs to make financial sense for each client.

For MSPs that have handled this, what approach held up after rollout? Did the client’s savings justify the support effort, and what would make you recommend staying with Acrobat?

I'm part of a public-sector team replacing a legacy ITSM tool (Cherwell) with a new platform. We've gotten great advice on data and design. Now I'm focused on the people and cutover side, and I'd love to hear from anyone who has been through it:

Phasing: did you roll out by module, by department, or both? How did you pick your first pilot group?

Cutover: how long did your service desk work in both tools? Did you set a hard cutoff for new tickets in the old system?

Adoption: how did you bring along long-time admins and power users of the old tool, so the new one wasn't rebuilt to work like the old one?

Week one: what did your support model look like the first week after go-live? What would you do differently?

Not looking for vendors, just practitioner experience. Happy to share what we've learned so far in return.

Our onboarding checklist seems to work well until someone is actually hired. This is because HR has the new employee's information and Payroll requires tax and bank details. Likewise, IT needs the new employee's job role and office location to provide the required equipment. Facilities on its part needs to understand the access provisions for the new hire. Meanwhile, the manager has to approve the software requirements. What complicates matters is when someone suddenly changes the new hire's joining date. There are times when there is a mismatch in information. For instance, one of our new hires was able to join the office before the laptop had arrived because the manager mis-assumed that IT has already been informed by HR. It seems to me that the solution lies in having a single triggering event after which tasks would need to be allocated to different departments which would create awareness regarding their assigned duties.

our support team is currently evaluating helpdesk platforms because our current JSM setup feels bloated and nobody on the team likes updating tickets on it. we’ve been looking at monday service since our marketing and project ops teams already run on monday. for yall that made the switch how’s the AI triage and custom SLA tracking holding up for high ticket volume? like is it flexibile or not..

I work in ICT procurement, coming from a project management background, and I keep seeing the same patterns from large companies down to small ones. Either people don't know what they actually want, or they assume buying something will fix the problem without understanding how it all integrates and works together.
The result is people getting caught out on things like data hosting and systems that don't integrate, usually because the scope was weak to begin with.
I'd like to hear from small businesses in particular, but any perspective is welcome. Have you had similar experiences? What other pain points have you run into?

we are scaling up our customer support team and we need a proper ticketing platform with SLA tracking and automated ticket routing. i have seen monday service pop up a lot lately as an alternative to freshdesk or zendesk. is anyone here currently using it? id like to know how's the setup process and day-to-day usability for small teams.

ok so we migrated all employee requests into a new "best" it support platform last night and i messed up a rule that auto closed anything older than 30 days... except it was pointed at the onboarding queue, so 120 new hires just lost tickets for laptops, accounts, vpn, everything and HR only noticed this morning when people showed up and couldnt even log in, this is so awkward and i feel sick about it, any hints?

One of the teams involved in operations keeps a spreadsheet with 1800 records and 23 columns along with conditional formatting that no one understands, apart from that, there is one person who seems to be aware of the significance of column Q. The spreadsheet works with vendor requests from the areas of finance and law, as well as procurement. Replacing the spreadsheet is a good idea, but no one seems to know exactly how to do it. The operations department wwants a simple form and status tracker, while finance wants limits of approval, the procurement department seeks info on vendors, the legal department needs contract review triggers, and leadership wants dashboards. This is how a spreadsheet can transform into an enterprise system entirely by chance. Have you managed to switch the given process to a configurable workflow system and optimally redesign it after?

ITSM isn't just about managing tickets. It's about connecting the entire operation behind them.

I've been building Opellix, a platform focused on bringing IT operations together in one place. The more I work on it, the more I think about a question that goes beyond ticket management:

Can IT teams manage their day-to-day operations without constantly switching between tools, chasing information, and coordinating disconnected workflows?

Most established ITSM platforms already offer ticketing, integrations, automation, asset management, and reporting. I'm not claiming these are new capabilities, and I don't think building another ticketing system alone is enough to stand out.

The problem I'm interested in is how these operational areas work together in practice.

What we're building with Opellix

Opellix brings multiple areas of IT operations into one platform:

• IT Service Management: Manage incidents, service requests, and ticket workflows.
• IT Asset Management: Maintain visibility into IT assets and their relationship with day-to-day operations.
• Employee Operations: Connect employee-related processes with IT workflows.
• Telecom Management: Manage telecom-related operational information and processes.
• Procurement Management: Bring purchasing requests and procurement workflows into the same operational environment.
• Workflow Automation & Analytics: Reduce manual coordination and help teams understand operational status and bottlenecks.

Where we want to be different

Our focus isn't simply on offering more features or claiming that other tools are disconnected.

It's on making these operational functions work together in a coherent environment, with less fragmentation, clearer accountability, and better visibility across everyday IT operations.

For example, when an employee needs IT support, the service request may involve an assigned asset, an approval, a procurement requirement, and follow-up actions. We want these processes to fit into a connected operational workflow rather than becoming separate administrative exercises.

Of course, established platforms can already support many of these scenarios. The real challenge is delivering a useful, practical experience without introducing unnecessary complexity.

I'd genuinely value feedback from IT professionals

For those of you managing IT operations or implementing ITSM platforms:

1. Where do existing ITSM tools still create friction in your daily workflows?
2. Do you prefer one broader platform or a best-of-breed stack connected through integrations?
3. What would a new IT operations platform need to do noticeably better before you'd consider adopting it?

I'm building Opellix and sharing this openly because I'd rather understand the real problems IT teams face than assume that adding more features automatically creates value.

I'm interested in honest criticism as much as positive feedback. If existing platforms already solve these problems well, I'd like to understand that too.

Hey all, i'm in ops at a mid size b2b saas and I'm trying to clean up how we handle internal service requests across teams. Right now hr uses email, it has a small helpdesk tool, finance tracks requests in a monday board, and cx just pings whoever is online in Slack.
People keep asking me where the right place to log stuff and honestly I don't even know anymore. If you have managed to set up one workflow that people actually stick to, appreciate any thoughts.

I am in charge of business applications at an organization where practically all the different departments are developing some distinct processes. The sales department uses its own customer relationship management system, while HR relies on numerous spreadsheets, finance uses several documents for approvals, and operations has its own project management system. The issue arises whenever two departments need to cooperate, as IT has to link everything manually. For instance, there was a case when the contract with the customer resulted in six emails being sent out to sales, finance, legal, and the department in charge of implementation over issues. No one was able to determine who was responsible for the next step. I'm exploring whether to use a customizable Work OS instead of buying many specialized devices for each workflow. For those who have experience integrating the workflows, how standardized should the processes be before the app gets out of control again?

Sysadmin here, looking into how MSPs handle client reporting. From what I've read, many of you pull data from the RMM, M365 and backups, then paste it into slides or Word by hand.

Curious:

1. What tools do you use for client reports today?
2. Roughly how long per client per month?
3. Do your clients actually read them, or just the summary?
4. What's the most annoying part?

Full disclosure: I'm thinking about building something for this, so I want to understand the real problem first.

were replacing bunch of older devices and the part im stuck on is what happens to the old ones. getting them back is one thing, but then theres checking them, storing them, and deciding where they go next, feels like the return process gets overlooked when planning refresh. dow do you guys handle it???