Developer Tools
BugHerd
Connect your AI to BugHerd
Web designers, QA testers, and agency project managers collect website feedback in BugHerd, but the tasks, comments, and screenshots they need are spread across projects, boards, and a feedback inbox that clients keep filling. AI can triage, report on, and act on that feedback in seconds, but only if it respects project membership, keeps private comments away from guests, and changes tasks only when someone approves.
Why it matters
Capabilities that matter most for BugHerd
01
Feedback beside the project plan
Join BugHerd tasks with Asana, Jira or Teamwork.com lists so website feedback sits next to the work that will fix it.
02
Every project in one view
Summary lists roll feedback up across projects and boards, so agency leads see the backlog without opening each one.
03
Private comments stay private
AI tools respect project membership and per-user security, and change tasks only through approved actions.
Use cases
Example AI Use Cases for BugHerd
scenario
-
When a customer gets in touch about the website, support sees their Zendesk tickets but not the bugs they or their colleagues reported in BugHerd. Pulling both means searching two systems by email, one person at a time, and it is easy to miss that the same page keeps breaking for the whole organization.
What popdock provides
--
Give a customer's email, or a Zendesk organization name to cover everyone in it, and a period (180 days by default). It reads the Zendesk tickets for that person or organization, then the BugHerd tasks, feedback and archived tasks each person reported, for up to 25 people. You get a summary of open and solved tickets and open and finished bug reports, the tickets already linked to a BugHerd task with both statuses, the open tickets and open bugs, and a note if the same page or problem keeps coming up. Nothing is changed in either system.
Business outcome
---
Support sees a customer's whole website history in one view before replying, without searching Zendesk and BugHerd separately.
scenario
-
To see what one person really has on their plate, you open BugHerd and Jira separately, find them in each, filter to their open items and add the lists together. Items sent from one system to the other show up twice, so the total looks heavier than it is, and overdue work in either tool is easy to miss.
What popdock provides
--
Give a person's email, and optionally a Jira project key, and it finds that person in both BugHerd and Jira by email. It reads their open BugHerd tasks and open Jira issues, drops anything done or closed, and counts a linked task and issue once so nothing is double counted. You get totals for each system and combined, the overdue items on either side, and one table of all open work. It only reads, so nothing is changed in either system.
Business outcome
---
A true picture of one person's workload across BugHerd and Jira, with no double counting and nothing changed.
scenario
-
When someone asks what happened to the problems they raised, you search ServiceNow for their incidents and BugHerd for their tasks and feedback, each in its own screen. The same issue is often logged in both places, so you either report it twice or miss that one side was already finished.
What popdock provides
--
Give an email and a lookback period, 90 days by default, and it finds the person in ServiceNow and reads the incidents they opened, then reads the BugHerd tasks, feedback and archived tasks they requested. It marks a task and an incident as the same issue when they are linked, or when their titles clearly describe the same problem, and says when that match is a judgment. You get who they are, one table of open issues across both systems, a count of what was finished and the overlaps. It only reads, so nothing is changed.
Business outcome
---
Answer a requester about everything they raised in BugHerd and ServiceNow in one reply, with overlaps called out.
scenario
-
Posting a progress note on a BugHerd task means opening the right project, finding the task by its number, typing the comment and uploading any screenshot or file separately. When the file lives at a link, you download it first and upload it again, and it is easy to post the note on the wrong task or the wrong project.
What popdock provides
--
Name the project, the task number and your comment, and optionally a link to a file, and it finds the project in BugHerd and asks you to choose if more than one matches. It looks for the task on the board and, if it is not there, in the feedback inbox. You see the task title and exactly what will be added, and nothing is posted until you confirm. It then adds the comment once and attaches the file from the link, and it never changes the task's status, severity or assignee.
Business outcome
---
Updates land on the right BugHerd task with the file attached, without touching its status, severity or assignee.
scenario
-
A BugHerd task created from a Bugsnag error has an owner, but the error in Bugsnag often has nobody assigned. Matching them means opening the task, finding the assignee's email, looking up the same person among the Bugsnag project's collaborators and assigning by hand, so the two systems drift apart.
What popdock provides
--
Name the BugHerd project and task number, and it checks the task is linked to a Bugsnag error and has an assignee, then finds that person's email in BugHerd. It reads the Bugsnag error and its project and matches the same email to a collaborator there; if the person is not a collaborator, it says so and stops rather than adding them. You see the error, the person and both projects, and nothing is assigned until you confirm. It then makes the one assignment and gives you the error link.
Business outcome
---
The person fixing the BugHerd task also owns the Bugsnag error, with one confirmed change and no guessing at who that is.
scenario
-
BugHerd projects pile up as sites launch and clients move on. Some are left public, so anyone with the link can still leave feedback, and others sit active with no new tasks for months. Checking means opening each project's settings and task list one by one, so it rarely gets done.
What popdock provides
--
Optionally name a project owner, and it reads every BugHerd project, or just that owner's. For each active project it flags the ones that are public, checks whether any task was created in the last 90 days, and notes projects with tasks turned off. You get a table of public projects and a table of possibly abandoned ones, each with a recommendation to make private, deactivate or leave as is, and a reason. Nothing is changed; any fix is a separate request.
Business outcome
---
You see every exposed or idle BugHerd project in one review and decide what to close, with no settings changed behind your back.
scenario
-
BugHerd webhooks feed tasks into chat, ticketing and build tools, and when one starts failing nobody is told. The first sign is a missing alert days later, and working out which webhook broke means comparing success and error times and decoding error codes by hand.
What popdock provides
--
Optionally name a project, and it reads every BugHerd webhook, or just that project's, including the healthy ones for comparison. Each webhook is judged broken, flaky or healthy from its last success, last error and error count, and the error code is translated into a likely cause, such as rejected credentials, a target URL that is gone or a receiver that is failing. You get a table of broken and flaky webhooks and a count of healthy ones. Nothing is changed, and query strings that may hold tokens are cut from URLs.
Business outcome
---
Broken BugHerd integrations are found and explained in minutes, without exposing secrets in the report.
scenario
-
Judging a website's health means opening Ghost Inspector to tally suite runs and failures, then switching to BugHerd to count open bugs by severity, then matching URLs between the two by eye. Pages that both fail tests and draw bug reports are easy to miss when the numbers live in separate tools.
What popdock provides
--
Name the BugHerd project and a lookback period, and it matches the project to its Ghost Inspector suites by site URL. It works out each suite's pass rate, latest result and most often failing tests, then reads the open BugHerd bugs and recent feedback. The report gives a healthy, at risk or unhealthy headline, puts pages with both failing tests and open bugs first, and lists gaps on either side. It is read-only: no tests are run and nothing is changed in either system.
Business outcome
---
One page by page health verdict for your site, combining automated test results and reported bugs, with nothing changed.
scenario
-
Writing a weekly update on a BugHerd project means counting tasks per column, working out what was added and archived, checking the feedback inbox and scanning for critical or overdue items. It takes a while, and numbers copied from different screens at different times rarely add up.
What popdock provides
--
Name the project and, optionally, how many days to cover, and it reads the board's columns and their task counts, the tasks created and archived in that period, the feedback still waiting in the inbox and the open critical tasks. You get a report with a one-line headline, the board in column order, the period's numbers, the tasks at risk and up to three suggested focus points. It reports only counts it actually read, says when a count may be higher than shown, and changes nothing.
Business outcome
---
A ready-to-share BugHerd status report in minutes, built from real counts rather than estimates.
scenario
-
When a client asks what happened to a reported issue, the answer is spread across the BugHerd task, its comment thread and its attachments, and the task may already be archived or still in the feedback inbox. Piecing it together means clicking through each place and reading everything in the right order.
What popdock provides
--
Name the project and the task number, and it finds the task on the board, in the archive or in the feedback inbox. It reads the task details, comments and attachments and lays them out as one timeline in date order, with who did what and private comments marked as private. You get the task's details, its description as written, the timeline and a short summary of what was asked, what was done and what is still open. Comments are quoted briefly, not reworded, and nothing is changed.
Business outcome
---
You can answer any question about a BugHerd task in one read, with the full history in order.
scenario
-
After a release ships, judging whether it went well means comparing stability in Bugsnag against the previous version, picking out the errors that are new, then checking BugHerd for what testers and clients reported since. Those reports rarely get matched to the errors, so a bad release can look fine in one tool and broken in the other.
What popdock provides
--
Name the Bugsnag project, the BugHerd project and a release version, or leave the version out to use the latest. It reads the release and the one before it from Bugsnag, compares the share of unhandled sessions, and lists errors first seen since the release. It then reads the BugHerd tasks and feedback created since the release date and matches them to the new errors by page. You get a verdict of healthy, watch or roll back candidate, with one sentence why, and nothing is changed in either system.
Business outcome
---
You know in one question whether a release needs attention, backed by both error data and what people reported.
scenario
-
When a ServiceNow incident turns out to be a website problem, the web team needs it in BugHerd. Doing it by hand means retyping the incident, translating priority into severity, finding the caller's email and leaving a work note on the incident, and it is easy to create the same task twice.
What popdock provides
--
Name the ServiceNow incident and the BugHerd project, and it reads the incident, asks before going on if it is already resolved, closed or canceled, and checks BugHerd for a task already created from it. It maps priority to BugHerd severity and uses the caller's email as the requester when there is exactly one match. You see the task before anything is created and nothing is written until you confirm. Then it creates the task and adds a work note to the incident, without changing its state, assignment or priority.
Business outcome
---
Website incidents reach the web team in BugHerd once, with the task recorded on the ServiceNow incident.
scenario
-
Logging a bug in BugHerd by hand means picking the project, searching the board and the feedback inbox to see if someone already reported it, then setting severity and finding the right assignee. Skip the search and the same bug is logged twice; mistype an email and the task sits with nobody.
What popdock provides
--
Describe the bug and name the project, and optionally a severity and an assignee's email, and it searches the project's tasks and feedback for the same problem first. If a matching open task exists, it shows it and asks whether to log a new one or comment on that task instead. The assignee is checked against real BugHerd users. You see the project, description, severity and assignee before anything is created, then the task is added once to the board and you get its task number.
Business outcome
---
Bugs land on the BugHerd board once, with the right severity and a real assignee, and no duplicates to clean up.
scenario
-
An error in Bugsnag only gets fixed once it is on the web team's board in BugHerd. Logging it by hand means copying the error class and message, working out which page it happens on, choosing a severity, checking it is not already logged and linking the error back, and any skipped step leaves a duplicate or an error nobody can trace.
What popdock provides
--
Give a Bugsnag error and the BugHerd project, and it reads the error and its recent events to find the page where it happens most. It checks BugHerd for a task already logged from that error and stops if one exists. It drafts the task with the error details, users affected, first and last seen and the error link, and sets severity from the Bugsnag severity and user count. Nothing is created until you confirm; then it adds the task, reads back its number and link and links the Bugsnag error to it. It never changes the error's status or severity.
Business outcome
---
Bugsnag errors land on the BugHerd board once, on the right page, and each side links to the other.
scenario
-
A nightly Ghost Inspector run fails and someone has to open each result, find the failed step, copy the console errors and write it up as a BugHerd task. Do that for every failure and you end up with duplicate tasks for the same test, or a screenshot change logged as a bug.
What popdock provides
--
Name the Ghost Inspector suite, the BugHerd project and a lookback period, and it finds the tests that failed and are still failing. For each it gathers the first failed step and up to three console errors, then checks BugHerd for a task already raised from that test and skips it. You see the tasks it will create and can remove any before you confirm. It then creates one task per approved test, with higher severity for home, checkout or login pages, and comments the task number on the failing Ghost Inspector result. Screenshot only failures are listed separately, and it never re-runs tests or accepts screenshots.
Business outcome
---
Every real test failure becomes one well documented BugHerd task, without duplicates or hand-copied evidence.
scenario
-
Feedback often lands in the wrong BugHerd project, such as staging instead of production or one client site instead of another. Moving it means finding the task, choosing the destination from a list of similar names and then tracking it down again, because it gets a new task number once it moves.
What popdock provides
--
Name the task number, the project it is in and the project it should go to, and it checks that each name matches exactly one BugHerd project and that the two are different. It finds the task in the source project and shows you its title, status and both projects. Nothing moves until you confirm, then the task is moved once. It reminds you that the task gets a new number in the destination project and can look that number up for you.
Business outcome
---
Misfiled BugHerd tasks reach the right project without guessing at similar project names or losing track of the task.
scenario
-
Before a release, someone has to start the Ghost Inspector suite, wait for it, read the failures, then go through BugHerd for open critical and important bugs and decide whether to ship. The test results and the bug list live in different tools, so the go or hold call often rests on whichever one was checked last.
What popdock provides
--
Name the Ghost Inspector suite, the BugHerd project and, optionally, a start URL, and it tells you which suite will run against which URL before anything starts. After you say yes it runs the suite once and reads the result and the failing tests with their first failed step. It then reads open critical and important BugHerd bugs and applies a clear rule: hold for any failing test or open critical bug, go with care when only important bugs remain, go when both are clear. It creates no BugHerd tasks, and a cancelled or errored run is reported as inconclusive.
Business outcome
---
A release go or hold decision backed by a fresh test run and the open bug list, made in one conversation.
scenario
-
Client feedback piles up in the BugHerd inbox faster than anyone sorts it. Clearing it means opening each item, deciding which column it belongs in, setting a severity and picking someone to own it, one task at a time, while the oldest items wait longest.
What popdock provides
--
Name the project and how many items to work through, and it reads the oldest items in the feedback inbox, the board's columns and your BugHerd users. It proposes a column, a severity and an assignee for each item, with a reason, in one table. You choose which rows to apply and can edit them first. Only the rows you approve are updated, nothing is closed without your say, and you get a table of what changed and anything that failed.
Business outcome
---
The BugHerd inbox is cleared onto the board in one pass, with every change approved by you first.
scenario
-
The BugHerd backlog shows severity, but not how many customers a bug is pushing into Zendesk. Counting that means reading linked tickets, searching Zendesk for similar complaints and checking satisfaction ratings for each bug, so fixes get prioritised without knowing which ones would cut support work.
What popdock provides
--
Name the BugHerd project and a period (30 days by default). It reads the open bugs, counts the Zendesk tickets already linked to each, and for critical and important bugs searches Zendesk for tickets describing the same problem, saying these related matches are by judgment. It notes satisfaction ratings on the counted tickets. You get a table ordered by ticket count, with severity, linked and related tickets, bad ratings and the oldest ticket, plus the three fixes that would save support the most. Nothing is changed in either system.
Business outcome
---
You prioritise BugHerd fixes by the support load they cause, with linked and judged matches kept apart.
scenario
-
When a BugHerd task needs a new owner or a higher severity, you open it, change the fields and then leave a note so the team knows why. The note is the step that gets skipped, so the new assignee picks up a task with no context and nobody can see when or why it was escalated.
What popdock provides
--
Name the task number and project, and the new assignee, the new severity or both, and it reads the task's current values and matches the person to a real BugHerd user, asking you to choose if several match. You see the current and new values side by side, and nothing is written until you confirm. It then updates only the fields that change and adds a one-line note to the task saying what changed. If nothing would change it writes nothing, and if the update fails no note is added.
Business outcome
---
Reassignments and escalations happen in one step, with a note on the task so the team knows what changed.
scenario
-
Once BugHerd tasks and GitHub issues are linked, they drift. A developer closes the issue but the BugHerd task stays open, or the site is signed off in BugHerd while the issue lingers on GitHub. Finding these means checking every linked pair in both tools by hand.
What popdock provides
--
Name the BugHerd project, the GitHub repository and a lookback period, and it collects links from both sides: BugHerd tasks, including archived ones, that reference an issue, and GitHub issues whose titles carry a BugHerd task number. It reads the other side of each link and sorts the pairs into closed on GitHub but open in BugHerd, done in BugHerd but open on GitHub, and broken links, with the pairs in step given as a count. It is read-only, so nothing is changed in either system.
Business outcome
---
A clear list of drifted BugHerd and GitHub pairs to act on, with nothing changed until you decide.
scenario
-
Once a BugHerd task and a Jira issue are linked, their statuses drift. A developer closes the issue but the task stays open on the site, or the web team finishes a task while the Jira issue sits stale. Finding these pairs means opening each link on both sides and comparing statuses by hand.
What popdock provides
--
Name the BugHerd project and the Jira project key, and optionally a lookback period, 90 days by default, and it collects the links from both sides, including archived BugHerd tasks. It reads the other half of each pair and sorts them into in step, done in Jira but open in BugHerd, done in BugHerd but open in Jira, and broken links. You get a table for each problem class and a count of the pairs in step. It only reads, so nothing is changed in either system.
Business outcome
---
See every linked BugHerd task and Jira issue that has drifted, so fixes get verified and stale issues get closed.
scenario
-
Linked BugHerd tasks and ServiceNow incidents fall out of step. The web team fixes the bug while the incident stays open, or the service desk resolves the incident before the site is fixed. Spotting this means checking each pair in both systems and comparing states by hand.
What popdock provides
--
Name the BugHerd project, and optionally a lookback period, 90 days by default, and it collects the links from BugHerd tasks, archived tasks and ServiceNow incidents. It reads the other half of each pair and sorts them into in step, fixed in BugHerd but open in ServiceNow, resolved in ServiceNow but open in BugHerd, and broken links. You get a table for each problem class and a count of the pairs in step. It only reads, so nothing is changed in either system.
Business outcome
---
See every linked BugHerd task and ServiceNow incident that has drifted, so incidents get resolved and fixes get checked.
scenario
-
BugHerd tasks raised from failing Ghost Inspector tests are easy to lose track of. A test starts passing but its task stays open, or a task is closed while the test still fails, and nobody notices until a client reports it again. Checking means opening each task and then its test's latest run.
What popdock provides
--
Name the BugHerd project, and it reads every task, including archived ones, that was raised from a Ghost Inspector test. For each it reads that test's latest result and sorts the pairs into fixed but open, closed but failing, and orphaned where the test no longer exists, with the pairs in step given as a count. Each table shows the task, its status, the test and the latest result date. It is read-only, so no tests are run and nothing is changed in BugHerd.
Business outcome
---
Catch closed bugs that still fail and open bugs that are already fixed, without opening a single test run.
scenario
-
Once a Zendesk ticket is linked to a BugHerd task, the two move at different speeds. Bugs get fixed while the customer is never told, tickets get solved while the bug is still open, and links point at tickets that no longer exist, and finding these means comparing every pair by hand.
What popdock provides
--
Name the BugHerd project, and it reads every task, feedback item and archived task linked to a Zendesk ticket, then reads each ticket. It sorts the pairs into customers waiting on a fix, fixed but customer not told, ticket closed with the bug still open, in step, and broken links. You get one table per group with ticket, requester, both statuses, severity and days open, with waiting customers ordered longest first. Nothing is changed in either system.
Business outcome
---
You catch customers left waiting and tickets closed on unfixed bugs before the customer has to chase you.
scenario
-
When a developer says a bug is fixed, someone has to find the Ghost Inspector tests that cover that page, run them, read the results and then go back to BugHerd to close the task and note why. Without that, tasks either sit open for days or get closed without proof.
What popdock provides
--
Name the BugHerd project and task number, and it reads the task and finds the Ghost Inspector tests that cover it, either the test that raised it or tests whose start page matches the task's page. If none do, it tells you a manual retest is needed. It lists the tests and runs them only after you confirm. If every test passes, it proposes marking the task done with a comment naming the tests and date, and waits for a second yes. If any fail, it reports the failed step and leaves the task alone, and it notes when a passing test does not cover everything the task describes.
Business outcome
---
Close fixed BugHerd tasks with test evidence attached and keep unfixed ones open, in one conversation.
scenario
-
BugHerd shows due dates task by task, but not who has fallen behind across projects. Finding overdue work means filtering each project, skipping tasks that are already done and grouping the rest by person, so late tasks are usually spotted only when a client chases them.
What popdock provides
--
Ask for overdue tasks across all projects, or narrow it to one project or one assignee, and it reads the open BugHerd tasks whose due date has passed, leaving out done and closed tasks and any task with no due date. You get the tasks grouped by assignee, with unassigned ones in their own group, each showing project, severity, due date and days overdue, ordered by severity. Each assignee gets a suggested next step: re-plan, reassign or escalate. Nothing is changed.
Business outcome
---
You see who is behind on what in one list and can act before clients start chasing.
scenario
-
Clients and reviewers report bugs in BugHerd, but developers work from GitHub issues. Moving a task across by hand means copying the description, page, severity and reporter, adding a link back, and remembering whether it was already sent, so the same bug often ends up as two issues.
What popdock provides
--
Name the BugHerd project, the task number and the GitHub repository, and optionally an assignee, and it reads the task and checks GitHub for an issue already opened for it. If one exists, it reports that issue and stops. It drafts an issue titled with the BugHerd project and task number, with the description and a list of page, severity, requester, reported date and the task link, labelled bug. Nothing is opened until you confirm, then it creates the issue once, reads back its number and link, and comments that link on the BugHerd task.
Business outcome
---
BugHerd reports reach developers in GitHub once, with full context and a link both ways.
scenario
-
Moving a website bug from BugHerd to Jira by hand means creating the issue in the right project and type, copying the description, page and severity, finding the assignee in Jira, and then linking the two. Miss the duplicate check and the developers get two issues; miss the link and nobody can trace the issue back to the page.
What popdock provides
--
Name the BugHerd project and task, the Jira project key and optionally the issue type, Bug by default, and it reads the task and checks Jira for an issue already sent from it. It resolves the project and issue type, and matches the BugHerd assignee to a Jira user by email, leaving the issue unassigned when there is no single match. You see the issue before anything is created and nothing is written until you confirm. Then it creates the issue with the due date, adds the description, a remote link to the task and a comment on the BugHerd task, and reports which steps succeeded.
Business outcome
---
Website bugs reach developers in Jira once, with full detail and a link back to the BugHerd task.
scenario
-
Starting a new site review in BugHerd means creating the project, adding each team member and inviting each client as a guest. It is easy to create a second project with the same name, or to try adding a client as a member when they are not part of your organization.
What popdock provides
--
Name the project, the member emails and the guest emails, and it checks whether the BugHerd project already exists and only plans to create it if it does not, asking for the site URL when needed. Each member email is matched to a user in your organization, and anyone not found is listed so they can be invited as a guest instead. You see the full plan and nothing is applied until you confirm. It then creates the project if needed, adds the members and invites the guests, leaves visibility at BugHerd's default, and reports who was added and any errors.
Business outcome
---
New BugHerd projects are ready with the right team and clients in one step, with no duplicate projects.
scenario
-
When a BugHerd task is closed, its linked Bugsnag error often stays open, and when an error is fixed in Bugsnag the task stays on the board. Bringing them back in step means checking every linked pair by hand, and marking fixed an error that has started firing again hides a regression.
What popdock provides
--
Name the BugHerd project, and it reads the tasks and archived tasks linked to Bugsnag errors and the state of each error. It proposes marking errors fixed where the task is finished, but flags any error with new events since the task closed as may have regressed instead. Where the error is fixed or ignored and the task is still open, it proposes setting the task to done with a comment. You see all proposals in one table and only the rows you approve are applied. It never discards, ignores or reopens an error and never reopens a task.
Business outcome
---
BugHerd and Bugsnag agree on what is fixed, regressions are flagged rather than hidden, and only approved changes are made.
scenario
-
Linked BugHerd tasks and GitHub issues fall out of step all the time. Fixing them means closing issues one by one on GitHub, marking tasks done in BugHerd and leaving a note on each so people know why, and doing it in bulk by hand risks closing the wrong item.
What popdock provides
--
Name the BugHerd project and the GitHub repository, and it finds linked pairs where exactly one side is finished. For issues closed on GitHub it proposes marking the BugHerd task done with a comment asking for a check on the site. For tasks done in BugHerd it proposes commenting on and closing the GitHub issue. Every proposal appears in one table and only the rows you approve are applied. It never reopens anything or changes titles, labels, assignees or milestones, and if one update fails it reports the error and carries on.
Business outcome
---
BugHerd and GitHub agree again, with a comment explaining each change and only the changes you approved.
scenario
-
When a developer finishes a Jira issue, the linked BugHerd task often stays open on the site, and when the web team closes a task, the Jira issue lingers. Fixing each pair means opening both records, updating the task and leaving comments, one link at a time.
What popdock provides
--
Name the BugHerd project and the Jira project key, and it finds the linked pairs where only one side is finished. For a Jira issue that is done, it proposes marking the BugHerd task done with a comment; for a BugHerd task that is done, it proposes a Jira comment asking the team to verify and close, and leaves the Jira status to the Jira workflow. You see every proposal in one table and only the rows you approve are applied. It never reopens anything, and it reports what changed on each side and anything that failed.
Business outcome
---
Linked BugHerd tasks and Jira issues back in step, with only the changes you approve applied.
scenario
-
Linked BugHerd tasks and ServiceNow incidents drift apart: the bug is fixed on the site while the incident stays open, or the incident is resolved while the task waits. Closing each one by hand means opening both records, writing close notes and comments, and doing it pair by pair.
What popdock provides
--
Name the BugHerd project and which side to update, ServiceNow by default, BugHerd or both, and it finds the linked pairs where one side is finished and the other is open. It proposes resolving an incident with a close note when the BugHerd task is finished, or marking a BugHerd task done with a comment when the incident is resolved. You see every proposal in one table and only the rows you approve are applied. It never reopens anything or changes priority, impact, urgency or assignment, and it reports what changed and anything that failed.
Business outcome
---
Linked BugHerd tasks and ServiceNow incidents closed in step, with only the changes you approve applied.
scenario
-
When the web team finishes a BugHerd task, the customers who reported the problem in Zendesk are often still waiting. Telling them means finding which finished tasks link to open tickets, writing a personal reply for each and solving the ticket, and it rarely happens consistently.
What popdock provides
--
Name the BugHerd project and a period (14 days by default). It finds tasks finished in that period that are linked to Zendesk tickets and keeps only the tickets still open. It drafts a short public reply for each, thanking the customer by first name, describing the problem in their words and inviting them to reply if they still see it, with no internal task numbers or links. You see every draft in one table and can edit them; only the replies you approve are sent, each solving its ticket. BugHerd tasks are never changed.
Business outcome
---
Customers hear that their website problem is fixed, in a reply you approved, and their tickets are solved.
scenario
-
Client feedback in BugHerd arrives as a mix of real bugs, change requests, questions, duplicates and test clicks. Deciding what each item is, how serious it is and who should look at it means reading every one, and serious issues can sit in the inbox behind cosmetic ones.
What popdock provides
--
Name the project and how far back to look, and it reads the feedback inbox and classes each item as a bug, change request, question or noise. It proposes a severity from what the description says, not who reported it, spots duplicates, and suggests an assignee only from your real BugHerd users. Items too thin to judge are marked as needing more information. You get a table with a recommended action for each item and the three to deal with first. Nothing is changed.
Business outcome
---
You know what is in the BugHerd inbox and what to fix first, without changing a single task.
No items found.
Ready to unlock your data?
Start building tools that turn your business systems into AI superpowers
Join forward-thinking companies that are transforming their operations with intelligent, secure AI automation.