Pluno

a support AI can give a correct answer to the wrong person. imagine a troubleshooting guide written for your agents. It includes a temporary workaround that needs an engineer’s approval. that guide can be accurate and useful. It still isn’t automatically something the AI should turn into instructions for a customer. this is one place where an agent copilot and a customer-facing AI need different defaults. in @pluno_ai, imported non-public Help Center articles are available to Copilot, our assistant for human support agents. They’re excluded from customer-facing Deflection AI unless you explicitly opt in. that’s a choice I’d want the team to make deliberately. Useful to an agent and approved for a customer are two different things. before connecting another knowledge source, I’d ask: • who was this written for? • what can the AI use from it in a customer reply? • does the answer depend on who the customer is? giving AI more context is useful. So is deciding where that context belongs. how do you separate internal guidance from customer-ready answers on your team?

back in April 2025, Cursor’s support AI turned a logout bug into an upsell. this was before Cursor’s acquisition by SpaceX. It’s a useful case to revisit when evaluating support AI today. a customer had reported being logged out when switching machines. the reply from “Sam” explained: “Cursor is designed to work with one device per subscription as a core security feature.” then it told the customer they’d need a separate subscription for each device. that policy didn’t exist. Cursor’s cofounder confirmed the answer came from a front-line AI support bot. He later said the team had fixed the session bug, refunded the customer, and started clearly labelling AI support replies. the answer sounded plausible. It explained the symptom. It even offered a next step that would cost the customer money. that’s a failure I’d test for before putting AI in front of customers. and that was also a focus when we developed @pluno_ai Deflection AI -> knowing when to escalate is just as important as knowing how to answer. take a real bug your team had to investigate. Give the AI the customer’s original message and the information available at the time. Keep the eventual diagnosis hidden. then check what it does when its sources don’t explain the problem. does it look for more evidence? Ask a useful question? Hand the case over with what it’s already checked? or does it make up a rule that makes the bug sound intentional? a useful escalation should count as a successful outcome when the answer isn’t known yet. what’s the most convincing wrong answer you’ve had to correct in support?

the bug is “done” in Jira. the customer is still asking if anyone is working on it. somewhere between those two screens, support has become a detective. does “done” mean the code was merged? Deployed to production? Enabled for the affected account? Does the customer need to retry something? before I’d tell a customer their issue is fixed, I’d want four things clear: - the fix is live where they experienced the problem - it applies to their account - any action they need to take is explained - someone owns the update and checks whether it worked that’s also how I’d test AI handling engineering follow-ups. give it an issue marked “done” with the fix still waiting for deployment. Does it announce that the problem is solved, or explain to the support agent what’s actually happened and what comes next? then test a deployed fix that requires the customer to retry. copying a status is easy. Knowing what you can safely tell the customer is the useful part. when engineering marks a bug “done”, what does your support team still have to chase before updating the customer?

before raising daily ticket targets, look at the support process behind them. a support leader had a practical problem. They needed to set a healthy expectation, because of long queues, and no hiring budget. “it depends” only gets them so far. a support manager told them they have a target of 100 tickets a day. Another said their team closing 3, sometimes 0. the first manager said their B2C SaaS team averaged closer to 75. But getting there required substantial tooling so common issues could be handled quickly. the second had tickets that required connecting to a customer’s network over VPN and investigating multiple servers. If I were on the receiving end of these benchmarks, I’d focus on what made the higher volume possible for the first manager -> "the team invested in making the work easier to complete." so before changing the target or even setting one, I’d look at where the effort goes: • finding a previous solution? • gathering evidence and investigating the issue? • preparing an engineering escalation? • chasing udpates and keeping the customer informed? those are specific steps we can improve. and they’re also how I’d evaluate support AI. Can it find the relevant solutions from previous similar cases? help investigate the cause? prepare a useful handoff? keep updates flowing? once those improvements are in place, I’d check how much time they actually save the team. That gives us a basis for deciding whether a higher daily target is realistic. which of those steps takes the most time on your team todya?

the problem with support ai might be the process we’re asking it to automate i came across a discussion in Support Drive slack about some experienced customers being forced to talk to an ai agent before they could open a support case the problem was that they had already done the initial troubleshooting and research the ai would guide them through. But they still had to go through the it to reach support the team was exploring a faster route to a form, with guided suggestions to gather the context support still needed that makes sense. but it still leaves the customer investigating, checking settings, and reporting back why are we focused on making that process easier when the ai agent could do more of the work itself? if you have a customer saying “my leads stopped syncing” and it's Pluno on the other end, it will directly check their current account configuration and take action inside the product to resolve the issue when it's fixable on their side and when the issues are actual bugs, @pluno_ai would escalate them with the all the context that it will gather itself + the actions already taken. Support can pick up the investigation from there we shouldn't be focused on guiding customers through troubleshooting and improving those workflows when we can directly give them a product expert that would make all that redundant and once customers know what the product agent is capable of, they would just stop feeling they need to do all that work before asking for help that’s really the outcome they need, not a special route that saves customers from repeating the work but still leaves them having to do it all themselves

if you designed support from scratch today, you wouldn’t make customers leave your product to ask for help think about what happens when a customer gets stuck in your product: - they leave it and search the help center, open a chat or file a ticket. - someone who can’t see their account asks for screenshots. - hours later, they get a list of steps. - then they go back into the product and do it themselves. it’s a strange way to help someone. but it made sense when it was designed. support started as a phone line, then became an inbox, then a help desk, then a ticketing tool. every version sat outside the product, staffed by people who couldn’t see the customer’s setup and couldn’t change anything in it. The best they could do was explain. and because people who really knew the product were scarce, the only way to scale them was a queue that constraint is gone. in 2026, AI can know your product, your docs and every ticket you’ve ever solved. It can see a user’s configuration and permissions. It can change a setting, run an export or fix a broken integration. nobody starting from scratch today would build a system whose main job is passing a customer’s problem from person to person until it reaches someone who knows the answer. you’d put the product knowledge at the front, not the back. that’s what we built with the Pluno Product Agent when a lead sync breaks because of an unmapped field, it doesn’t send a help article. It maps the field and re-syncs the leads. When something looks like a real bug, it hands the case to your team with the context and the steps already tried. queues made sense when expertise was scarce. Now it isn’t. what else in your company is still running on rules from another era?

At @pluno_ai, our team spends all week looking after customers 3 times a week, for 9 weeks, we made time to look after each other too we trained together for a 15K run in Munich some of us had more running experience than others so we wanted a plan where nobody got left behind We'd train together, just not all at the same level. two options for every session so you picked one based on your experience and how you felt that day, plus you could switch whenever you needed to. the night before, we had a pasta party. I strongly recommend making that an official part of the plan 🍝 then the weather had other plans. nice and sunny turned into cold and rainy right before the start And that same week there were reports of a possible puma on the loose near Munich Quite a lot of extra context for a friendly company run 😂 But that didn't stop us. Everyone finished the full 15 km, then we went for a well-earned meal. What I loved most was how we kept each other going, through nine weeks of training and right up to a cold, rainy start line. If you lead a support team and want to build something together outside the inbox, comment "plan" and I'll DM you our nine-week training plan. Adapt the distance and sessions to whoever's joining. And whatever you change, keep the pasta party.

Play ping-pong with your teammates, not your customers support tickets. Most of the clock on a support ticket runs down during discovery, investigation, and troubleshooting by the time the actual problem is clear, the ticket has already played numerous sets of pong between the customer, support, and engineering We built @pluno_ai to end that rally. Pluno handles and investigates every ticket the moment it arrives - investigation starts with the past resolved tickets, known issues in Jira, Linear, etc. (keeping simple tickets simple) - When deeper investigation or actions are needed, it works with all of your connected tools like Datadog, or custom external API connections - And for bugs, escalates and links the ticket to an existing Linear, Slack or Jira on-going issue or creates a new one for engineering with a recommended fix Before replying to customers, it uses everything it has already found to prevent unnecessary back and forth Learns from all of your best support interactions with your customers , it follows the team’s tone, and keeps every conversation moving toward resolution Zooming out, in the background, it reviews all interactions to find specific improvement/coaching opportunities across the team and it works directly inside your help desk. No need to switch the entire platform. and the proactive side of it solves your customer issues directly in your product before they even become a ticket :) Happy Friday!!

An in-app documentation chatbot makes your help center conversational. But is that enough for your users? instead of searching through articles, users can ask a question and get a summarized answer That’s faster than manual search. But a documentation chatbot typically knows what should happen according to your docs. it doesn’t necessarily know what is actually happening in this user’s account. For example, the documentation might say that a reporting feature is available to administrators. But the chatbot may not know that the person asking is a viewer, that their workspace is on a different plan, or that a required setting is disabled. the screenshot below shows the difference. both assistants get the same question about a scheduled import that didn't work. The documentation chatbot on the left gives the user four possible causes to investigate. The product agent on the right checks the account, finds that the import ran but failed because team assignment is disabled, and turns it on when the user says yes that difference matters In the first scenario, the user still has to troubleshoot the problem themselves. maybe they figure it out. Maybe they try a few things, get frustrated, and contact support Then your support team has to collect the context, identify the root cause, explain the fix, and wait for the user to apply it. During all of this, the user is distracted from what they actually came to your product to do. A product agent can shorten that entire detour from something isn't working to it's fixed Yes, that means fewer tickets and less work for your support team. But I think the more important outcome is a much better customer experience. put yourself in the user's shoes and compare the two conversations. Which one would you rather have? btw the product agent on the right in the screenshot below is @pluno_ai :)

#Accelya is continuing to enhance its NDC support operations with @pluno_ai. Accelya is a global airline software provider powering more than 200 airlines with an open, modular platform that supports airline retailing from offer to settlement. As Accelya's NDC business continues to grow, ensuring support teams have fast access to accurate and relevant information is increasingly important. Support knowledge spans multiple systems, including Zendesk, Jira, Confluence, knowledge articles, historical tickets, and operational documentation. To further streamline knowledge access and improve efficiency, Accelya introduced Pluno to connect these sources, surface relevant expertise, transform resolved support cases into reusable knowledge, automate appropriate workflows, and provide agents with additional context when handling customer inquiries. The goal was not to replace existing processes, but to help support teams access information more quickly, improve consistency, and reduce the time spent searching across multiple systems. After introducing Pluno earlier this year, the feedback from support teams was overwhelmingly positive. Today, Pluno is becoming an important component of Accelya's NDC support workflow, complementing the team's existing capabilities and helping agents work more effectively. The support team has already recorded more than 2,000 AI-assisted responses, while weekly adoption has grown more than sixfold. Agents regularly leverage Pluno-generated recommendations and contextual insights to accelerate investigations and support decision-making. With the latest Jira x Pluno Copilot integration, support teams can incorporate relevant Jira information directly into responses while surfacing similar historical issues, helping agents investigate faster and work with greater context. A special thank you to Shahan Mohammed, Vice President of Service Management at Accelya, for championing this initiative and supporting innovation across Accelya's NDC support organization.

two months ago, the product we were building started taking over the wrong tabs on my laptop the day before, attachments had been disappearing Then the extension began crashing 3 to 4 times a day there's a particular kind of discomfort in dogfooding your own product and realizing "i wouldn't accept this experience from another company" This wasn't a random side project. We were testing new ways to extend @pluno_ai, our AI support agent for complex B2B tickets, beyond the traditional help-desk interface. The vision is to evolve deflection AI beyond the standard definition, that it resolve issues before a support ticket is even created but before that vision matters, the experience has to workk So i became our most annoying user screen recordings,, slack messages, tiny edge cases... Anything that felt wrong went straight to the team they did the unglamorous work of fixing and fixing dozens of small improvements that will never make an exciting launch video One issue, the agent navigating the wrong browser tab, went from my Slack message to fixed in under an hour laast week, we reached another milestone that would have felt out of reach not long ago Those facts belong in the same story The dashboard shows the milestone but the real progress happened in bug threads no customer will ever see Still plenty to improve. But I'm proud of how quickly this team turns “this is broken” into “this is awesome”

here's what i think why so many people feel AI is making their days longer and tougher AI was supposed to take work off our plates but despite everything happening faster, somehow the day got fuller i think it's because AI made individual tasks cheaper but didn't remove the work around them you still have to notice what needs doing and as individual tasks got faster, filling the empty space with more tasks made sense the problem grew and now companies are trying to solve it with even more AI an AI for email an AI for meetings an AI for CRM... which explains the weird tension happening inside companies employees feel like AI hasn't made work easier management sees AI and expects more output so when building @pluno_ai we realized people don't need another AI they have to prompt just to speed up output the AI should be proactive notice the repetitive work itself and take over you keep expanding your scope AI keeps taking over the workflows behind you because as long as it's easier to update the record in HubSpot yourself than prompt an AI and fill a chat with all the context... we'll keep finding ourselves buried in work with the most capable tools we've ever had sitting right in front of us

we took the Pluno team to Mallorca for a week and held the Plunolympics the name alone deserves a medal 🏅 last week we spent a full week together in Colònia de Sant Pere, in Artà, Mallorca morning runs. A bike tour. A hike. Swimming. Exploring the town. And a murder mystery dinner to put our detective skills to the test plus, of course, our own take on the Olympics a whole week together gives you time to get to knoww the people you’re building with beyond whatever everyone is working on. Shared experiences you’ll still be talking about long after you’re back grateful to be building @pluno_ai with this crew 💜

3 ops leaders told me the same thing this week, their teams have ai tools, completed the training, and their day to day work still looks the same. "if ai could show us everything our team should automate and build the workflows for us, we’d have automated everything that makes sense by now" that’s the part most ai adoption programs quietly leave to the employee we give people ai tools, training sessions and prompt libraries then we expect each person to figure out where ai belongs in their actual day meanwhile, the best opportunities are hiding inside routines nobody thinks or have time to document the same information copied between tools the same tabs opened every morning the same update made every friday each task looks harmless on its own once it becomes part of the routine, people stop noticing it altogether Pluno learns how each employee works inside the browser and surfaces the opportunities they may never think to look for it can recognize a repeated process, suggest where ai could help, put the workflow together itself and run it once the employee approves so people can benefit from automation without first becoming process designers themselves productivity gains from ai depend heavily on task fit and how well the technology is integrated into the workflow finding the right task is already half the work ai adoption becomes visible when workflows change, repeated tasks disappear and people get time back without having to constantly ask for it we’ve spent a lot of resources teaching people to understand and adopt ai and it hasn't worked. so it’s time we get the AI to understand their work, find its way to fit in, and start creating value proactively.

we're launching on Product Hunt... from an offsite in Mallorca 🌴⚡️ yes, we're a little crazy, but this marks an important milestone in our journey to make ai automation accessible for every workflow where it makes sense. pluno's new automation module: → identifies your repetitive activity → extracts the decision criteria behind the workflow → suggests an automation → asks you to review, confirm, and set it up with 1 click this launch wouldn't exist without the feedback, edge cases, skepticism, and "this would be useful if..." messages from all of you. huge thank you from the entire Pluno team! 💜 if pluno has saved you time, taken an annoying task off your plate, or felt different from other ai tools you’ve tried, we’d love your support today. an repost, upvote, or comment from a real operator helps others understand what using pluno actually feels like. upvote and comment on Product Hunt: producthunt.com/products/plu… Big thank you! 💜⚡️

according to @Gartner_inc, only 1 in 4 customer service ai use cases produces roi. as an ai vendor, i think our industry should take that personally. companies now pursue nearly five use cases on average and commit 13% of their customer service budgets to ai. yet 42% still cannot say what value those systems create. the gap often starts before deployment: • the goal is simply "add ai" • use cases are chosen by volume • containment becomes the headline metric • measurement ends at deflection strong rollouts begin with a specific customer problem and a baseline: resolution rate, customer effort, escalation quality, time, and cost per resolved case. ai should earn broader scope through measured results. vendors need to make outcomes observable and accountable from day one. buyers should expect the same. the next phase of customer service ai will be won in the measurement layer. here’s the article: customerexperiencedive.com/n…

the moment I clicked on "connect", ai suggested my exact next two steps: - add the contact to hubspot and - schedule a follow-up task for the next day. it knew because i had done that workflow manually again and again. now one click confirms everything, right when it matters. watching ai learn my habits this closely is a little scary. but the result truly feels like magic. that feeling is what every product builder is chasing and @pluno_ai is slowly or not so slowly becoming a clone of myself

nobody wants to send the third "just checking in." an ai agent doesn't mind. this is the reminder it sent me after a teammate was still waiting on my answer. externally, follow-up agents are an obvious use case: - failed payment? they follow up. - missing document? they follow up. - customer hasn't taken the next step? they follow up again. but internal follow-ups might be even more useful. chasing colleagues is weirdly uncomfortable. you don't want to nag. so sometimes you just... don't. and then tasks sit. an agent has no social hesitation. it can remind someone tomorrow, next week, or keep following up until something moves. and somehow, a reminder feels less personal when it comes from a system. a lot of work doesn't get stuck because it's difficult. it gets stuck because nobody wants to keep chasing everyone. ai agents may be most useful for the socially awkward work humans avoid.

we offer @pluno_ai fully self-serve. but we also push hard to get every customer into an onboarding call. why the double strategy? not because Pluno is hard to use. it is because we see hundreds of different support setups, workflows, and goals. a short conversation helps us understand your situation and guide you toward the right solution faster. it helps you: - focus on the features that matter - set up the right workflows - avoid unnecessary complexity - get value from Pluno sooner and importantly: it helps us learn where the product can improve. self-serve gives you the freedom to start immediately. onboarding helps you get the most out of it.

Two years after our first team running challenge, we are back for round two. The goal was to find something that would challenge everyone without requiring a crazy time commitment. We are still a startup, after all :D Finding the right challenge was surprisingly difficult. • Too many of us can already comfortably run 10K • A half marathon requires too much training time • A backyard run needs a lot of preparation • Splitting a marathon between everyone sounds fun, but it would not really feel like a team run So we created our own challenge: Run 15K together in October. And somehow, 86% of the team has signed up. That is pretty awesome. It will not be a huge race with hundreds of people, but we will make it special in our own way. Everyone will train toward the same goal. Everyone will start together. And hopefully, everyone will finish together. Part of the fun will be seeing how many of us can complete the full 15K in October. A big shoutout to Timo for organizing the run and creating personalized training plans for the entire team. Now we just have to do the running 🏃