The team: a focused project inside a larger organisation
Northstar Systems is a fictional business software company preparing a new analytics release for a pilot group of employees. Six people formed the release support team: a release manager, two product specialists, two engineers, and a technical writer. They needed a temporary coordination workspace for release questions while the rest of the company continued using its existing tools.
The challenge: feedback had no single front door
Pilot questions arrived in personal emails and several Slack conversations. A reported problem might be a defect, an unclear instruction, or a request for a future feature. Without one queue, the release manager struggled to see which questions had an owner and which were waiting for more information. Engineering work already had a home in the company’s issue tracker; the missing piece was managing the conversation around that work.
The choice: six Scale seats for access control
The team selected Scale on monthly billing at $89 per agent, for $534 per month before tax. Six seats exceeded Scale’s five-seat minimum. Scale provided SAML SSO, custom roles, and a 365-day audit log alongside Growth’s routing and reporting features. Pilot participants remained external correspondents rather than RelayDesk workspace members. The company’s other employees did not automatically receive seats.
The rollout: pilot the support process before launch
The release manager became workspace Owner and an engineering lead became Admin. The team configured SAML SSO and tested access before inviting the full six-person team. A release inbox received pilot emails, with tags for access, documentation, suspected defect, and feature request. Historical feedback was imported as a small CSV batch with external IDs to avoid duplicates; imports did not trigger rules or send customer messages.
The workflow: own the conversation, link the engineering work
On new conversations, advanced rules routed tagged questions and set priority. Team members added tags after reviewing ambiguous reports and assigned those conversations manually. An engineer reproduced a suspected defect, created an issue in the company’s separate tracker, and pasted its URL into a private note. There was no native tracker integration or public API connecting the systems. The RelayDesk owner kept the reporter informed while the engineer worked in the tracker.
The launch rhythm: Slack for awareness, RelayDesk for replies
The team used Slack notifications for new and high-priority conversations. Notifications contained a subject and conversation link, without message bodies or attachments. A Slack thread did not become part of the support conversation, and a Slack reply did not reach the reporter. The release manager used workload and business-hours SLA reports to spot unowned or slow-moving work; those internal targets were separate from RelayDesk’s own support response targets.
The outcome: release feedback with an accountable next step
In this fictional scenario, the project team gained one place to see questions, owners, and pending follow-ups throughout the pilot. The technical writer could turn repeated questions into documentation improvements, while engineers kept implementation work in their established tracker. RelayDesk did not manage a release calendar, deploy software, synchronise issues, or guarantee a faster launch. The example illustrates a coordination pattern rather than measured project results.
After launch: decide what to keep
The Owner could keep the workspace for ongoing release enquiries or export conversation data before the paid term ended. If the team cancelled, access would continue through the current billing term and then stop. Data would be retained for 30 days before deletion from active systems, with backups potentially retaining it for up to 35 additional days. The team therefore planned its export while it still had access, rather than treating post-cancellation retention as an archive service.