Client & Project Snapshot
| Client | ACT360 Web & IT (internal project) |
|---|---|
| Engagement type | Web-based application built on a vendor API (Autotask PSA) |
| Core constraint | Autotask had to remain the system of record for tickets, time, and client data |
| ACT360’s role | Design, build, and deploy a reply portal for its own service delivery team |
| Systems involved | Autotask PSA (ticketing, time entries, client records) |
| Author | Jeffrey Bowles, Partner & Director of IT Services, ACT360 |
The Problem: When Everyone Can Answer, No One Reliably Does
ACT360 runs service delivery on Autotask, which holds tickets, time entries, and the client record. But customer correspondence didn’t arrive in one place. Clients emailed the people they knew: account managers, technicians, project managers, as well as the ticket system itself. Correspondence lived partly in Autotask and partly across individual mailboxes, and responsibility for replying was split across the team accordingly.
The predictable outcomes followed. Two people would answer the same client separately. Or nobody would answer, because each person assumed someone else had it.
Why This Mattered
Duplicate replies damage credibility. A client receiving two different answers from two staff members learns that their provider isn’t coordinated, regardless of how good the technical work is.
Delayed replies cost more than time. Silence on a ticket erodes trust quickly, and the cause here was rarely capacity. It was ambiguity about who owned the response.
Coordination consumed billable capacity. Staff spent time checking with each other about who had already responded, pure overhead generated by the tooling, not the work.
Correspondence outside the ticket system is invisible. Context that lives in one person’s mailbox can’t be seen by whoever picks the ticket up next, which makes handoffs, escalations, and absences expensive.
The information was already in Autotask. This wasn’t a data problem. It was an interface problem, which meant it could be solved without touching the system of record.
The Real Challenge Wasn’t Missing Data, It Was Adoption
The fastest tool wins, and the fastest tool was the inbox. Staff default to whatever lets them answer a client in the fewest clicks. Any solution slower than replying from Outlook would be routed around, and the problem would persist. Adoption was the primary risk here, not functionality.
Ticketing systems generally aren’t built for conversation. Native ticket interfaces tend to present correspondence as a flat list of records with quoted text stacked up inside it, which takes reading and inference to reconstruct, exactly the friction that produces duplicate replies.
Ownership was implicit. Because responsibility was split by relationship rather than assignment, there was no single place to look and see whether a reply was owed and who owed it.
Autotask had to remain the system of record. Time entries, billing, and reporting all depend on it. A second store of customer correspondence would have created a reconciliation problem worse than the original issue.
Working through a vendor API means the portal’s behaviour is bounded by what that API exposes and how quickly it responds, which constrains both feature design and the perceived speed of the interface.
How ACT360 Approached It
Every design choice below exists to solve the adoption problem, not just the technical one.
Decision
Why it mattered
Built on the Autotask API rather than alongside it
Autotask stays authoritative for tickets, time, and client data. No migration, no sync reconciliation, no competing version of a ticket
Modelled as an email client, deliberately
Matches the mental model staff already have. A familiar interface that’s faster than the alternative gets used, and a tool that gets used is the only kind that fixes a process problem
Threaded conversation view
The full exchange is readable at a glance, in order, with the most recent reply and its author immediately visible. This is the specific mechanism that addresses duplicate replies, not a policy or a reminder
Optimized for reply speed
Every unnecessary step in the portal is a reason for someone to go back to Outlook. Reducing the cost of replying in the right place is what pulls correspondence out of individual inboxes
Visible ownership and assignment
Removes the assumption that caused delays: that someone else was probably handling it
What Changed
The clearest evidence of adoption is what people stopped doing: going back to their personal inbox to answer a client.
Before
After
Correspondence split across personal inboxes and Autotask
Consolidated in one portal, visible to the whole team
Duplicate replies discovered after the fact, if at all
Structurally unlikely, visible before anyone starts typing a reply
Handoffs and coverage were expensive, context lived in one person’s mailbox
Cheap. Full conversation history is visible to whoever picks up the ticket
Staff spent time confirming who had already replied
That coordination overhead is recovered, the answer is visible on screen
Autotask was the system of record but not where correspondence happened
Autotask remains the system of record, and correspondence now happens there too
Removed the structural cause of duplicate replies. Whether a client has already been answered, and by whom, is now visible before a reply is composed rather than discovered afterward.
Reduced delays caused by ownership ambiguity, the dominant cause of slow responses, distinct from capacity constraints.
Consolidated customer correspondence where it’s visible to the whole team, making handoffs, coverage during absences, and escalations substantially cheaper.
No new system of record and no data migration. Autotask remains authoritative. Billing, time tracking, and reporting were unaffected.
These outcomes are stated directionally. Baseline metrics such as average reply time or duplicate-reply frequency weren’t captured before the change, so no percentage or dollar figure is attached to this case study. What changed is the structural cause of the problem, not a number we’re choosing to report.
The Bigger Picture
Response handling became a controllable process rather than a matter of individual habit. The behaviour ACT360 wanted is now the path of least resistance, which is more durable than process documentation or reminders.
ACT360 stopped waiting on a vendor’s interface roadmap. The constraint was never Autotask’s data, it was its UI for this particular job. Building the interface layer means workflow improvements can now ship on ACT360’s own schedule rather than the vendor’s.
It’s a demonstrable capability, not a claim. ACT360 built the tool it uses to serve its own clients, on a vendor API, to solve a coordination problem common to nearly every service business. That’s the same underlying pattern behind another ACT360 engagement: fronting a field service company’s legacy system with a purpose-built companion app rather than replacing it. The specifics differ, but the principle doesn’t: when a vendor system holds the right data but the interface is the problem, build the interface, not a replacement.
Jeffrey’s Take
When the system of record holds the right data but makes the daily work slow, the problem is usually the interface, not the database, and replacing the system is the most expensive possible response to that.
The real lesson here is about adoption. This wasn’t fundamentally a software problem. It was a process problem caused by staff routing around a tool that was slower than their inbox. Process documents and reminders don’t fix that. Making the correct path the fastest path does. The threaded view matters less because it’s modern than because it makes duplicate replies structurally unlikely, the check happens automatically, before anyone starts typing.
