// Automate the Busywork
Two Separate Help Desks, Kept in Step Both Ways
A client help desk and a service provider's system that had to agree
The story in briefTwo organizations ran two different ticket systems on the same work, which meant the same updates were typed twice and the two records still disagreed. We built a two-way sync so a ticket raised on one side appears on the other and both stay current, while deliberately leaving the decisions that affect billing to people.
The situation
Two organizations were working the same tickets in two different systems. The client ran their own help desk for their staff. Their service provider ran a separate system that drove their service delivery and billing. When work was assigned across the boundary, it existed in both places and agreed in neither.
Why the usual options fell short
The tempting answer is to make one side give up their system, and it is the wrong answer. Each was doing a real job for its owner. The practical alternative, having people copy updates between the two, is exactly the invisible work that never gets counted: it is slow, it is dull, and it fails quietly whenever someone is busy.
What we built
A two-way sync between the systems. A ticket assigned across the boundary creates its counterpart on the other side, and from then on both records stay current: status, summary, notes and conversation, recorded time, on-site scheduling, and reopening. Where the two systems could disagree, the rules for resolving it were decided deliberately rather than left to chance.
The part they didn’t expect
How much depended on drawing a firm line around what automation must not do. Finished work is parked in a settled state and closed by a person at review, because closing a ticket has billing consequences. Keeping that decision human is what made the rest of the automation safe to trust.
The payoff
- One piece of work, recorded once, visible correctly on both sides.
- Status, notes, time and scheduling stay current in both directions.
- No one copies updates between systems by hand.
- Neither organization had to abandon the system that works for them.
- Decisions that affect billing remain with people, by design.
// is this you?
If this sounds like a problem you recognize — even if you never pictured building your own answer to it — that is usually the sign. Describe your version and a senior engineer will tell you plainly whether it is the kind of thing we build.
Start a project// common questions
Questions about this kind of build
Why not just have everyone use one system?
Because both sides had good reasons for theirs. The client's help desk served their internal staff; the provider's system ran their service business and their billing. Forcing either party onto the other's tooling breaks something that works. Syncing them respects both.
What actually stays in sync?
The things people rely on being current: status, the summary of the issue, notes and conversation, time recorded against the work, and scheduling for on-site visits. Reopening a closed issue is handled on both sides too.
Does the automation close tickets?
Deliberately not. Automation parks finished work in a settled state and people close it during review. Anything that affects billing stays a human decision, which is a rule we would apply again.
What happens when the two systems disagree?
Conflicts are the hard part of any two-way sync, so the rules for which side wins are decided explicitly up front rather than left to whichever update happened to arrive last.
// next step
Have a system in mind?
Describe what you are trying to build or fix. A senior engineer reviews every inquiry and responds directly, with a technical read on the problem.