Talk to Sales

Trial Account Onboarding

Trial Account Onboarding

Your Cloud RT trial gives you a fully managed Request Tracker instance for 14 days, with no credit card and nothing to install. This guide walks you from signup through the setup that makes RT useful for your team, and covers what happens when the trial ends.

Every Cloud RT plan includes the complete RT feature set. Nothing in this guide is a trial-only preview or a feature you will lose later.

Unlimited queues, custom fields, lifecycles, scrips, assets, RTIR, and the REST API, are all available to you on day one and on every plan after.

Start your trial

  1. Go to requesttracker.com/free-trial.
  2. Enter your work email address and click the submit button. Best Practical starts building a dedicated RT instance for you, hosted on AWS and managed by us.
  3. Watch for the email titled Welcome to Request Tracker. It usually arrives within a minute or two and contains your trial site URL, your username (root), and your password.
  4. Click the URL or cut and paste it into a browser. Your site is normally ready about five minutes after signup.

If you follow the link before the build finishes, you will see a message saying we are still building your site. Leave the page open. It updates on its own and shows the RT login screen as soon as the instance is ready.

You do not choose a subdomain. Your trial site is issued at an address under try.requesttracker.io. If you later subscribe to a plan that includes a custom domain, we update the site address at that point.

Your trial site does not arrive empty. We preload a sample configuration showing what a typical helpdesk instance looks like, so you have working queues, workflows, and settings to explore from your first sign-in rather than a blank system to build from scratch. Those are starting settings, not limits: RT is used to track a very wide range of tasks and workflows, and everything in the sample configuration is yours to change.

The first thing you will see after signing in is the Getting started portlet on your home page. The sample tickets listed there are not filler: each one walks you through part of the system, so working through them is a good companion to this guide. Your trial site header also carries a Customize Your Trial link if you would like us to tailor the site to a different use case.

Use a work email address. Trial instances are provisioned for business domains only, so signups from consumer mail providers (Gmail, iCloud, Yahoo and similar) are not accepted. If you need to evaluate RT and only have a consumer address, write to sales@bestpractical.com.

If you would rather run RT on your own hardware, the open source version is free to download and self-host, with full source code, and the same feature set. See Install & Upgrade in these docs.

Onboarding: Six steps to a working RT

Work through these in order. Steps 1 through 3 get you to a system your team can actually use. Steps 4 through 6 are where RT starts doing work for you that a shared inbox or spreadsheet cannot. Every step ends with something to go and do.

Step 1. Explore the sample configuration, then make a queue your own

Queues are how RT organizes work. Each queue is a category of requests with its own permissions, its own workflow, and its own custom fields. Most teams end up with one queue per workflow: Support, IT Requests, Facilities, New Hire Onboarding.

Your trial site already has a sample helpdesk configuration in place, so start there.

  1. Sign in to your trial site with the root credentials from your welcome email.
  2. Go to Admin > Queues > Select to see the queues that are already configured.
  3. Create a test ticket using the Create new ticket button, and follow it through a reply and a resolve to see how a ticket moves through the system.
  4. Add a queue of your own under Admin > Queues > Create. Name it for a workflow your team actually runs, for example New Hire Onboarding.
  5. Create a ticket in your new queue and compare it against the test ticket you created in step 3.

All plans allow for an unlimited number of queues.

Post-onboarding: Working with RT covers day-to-day ticket handling, including the distinction between a reply (sent to the requestor) and a comment (internal only).

Step 2. Email

RT was built around email, and it shows. Requestors send mail to a queue address and get a ticket. They reply to the ticket and the reply lands in the history.

Your trial site comes with this already working. We provision a testing email address for you, listed in your welcome email, so there is no mail server to configure, no DNS to point, and nothing to connect for your trial.

Create a ticket by email:

  1. Find the testing address in your welcome email. It looks like yoursite-testing@try.requesttracker.io.
  2. Send a message to it. RT creates a ticket, and your message becomes the first correspondence on it.
  3. Reply to that ticket from inside RT and watch the exchange thread into the ticket history.

See how internal comments work:

  1. Open a ticket and choose Actions > Comment.
  2. Add yourself as a Cc on the comment, write a note, and submit.
  3. You will receive the comment by email. Reply to that email and your reply is added to the ticket as another comment.

That second exercise is worth doing deliberately, because it is the piece of RT that changes how teams work. A comment is internal and never reaches the requestor; a reply does. Both live on the same ticket in one timeline, so the customer conversation and the team’s own discussion sit side by side without a second tool and without any way to send an internal note to a customer by accident. Notice too that your emailed reply landed back on the ticket: your team can work a ticket entirely from their inbox and RT keeps the record straight.

Trial sites do not connect to your own mail transfer agent. The provisioned testing address is how you evaluate RT’s email handling during the trial. Mail integration with your own domain is set up when you move to a paid plan.

Post-onboarding: Email management.

Step 3. Add your team and set rights

RT’s permission model is granular by design: rights are granted to users, groups, and roles (Owner, Requestor, Cc, AdminCc), globally or per queue. Grant rights to groups rather than to individual people and future you will be grateful.

  1. Go to Admin > Users > Create and add a team member.
  2. Go to Admin > Groups > Create and create a group that matches how your team is organized, for example Support Staff.
  3. Add your new user to that group.
  4. Go to Admin > Queues > Select, open the queue you created in Step 1, and choose Group Rights.
  5. Select your Support Staff group and grant it a working set of staff rights: SeeQueue, ShowTicket, CreateTicket, ReplyToTicket, CommentOnTicket, OwnTicket, and ModifyTicket. Save.

How to know it worked

Sign in as the user you created in step 1, or use Admin > Users to check their rights. That user should now see your queue, be able to create a ticket in it, take ownership, and reply. If they cannot see the queue at all, SeeQueue is the right that is missing.

Post-onboarding: Authentication and Custom roles.

Step 4. Shape the workflow with custom fields and lifecycles

This is the step that separates an evaluation from a decision. Most teams stop at “it receives email and makes tickets.” RT will model your actual process.

  • Custom fields capture the data your process needs: severity, customer, contract number.
  • Lifecycles define your real ticket states and the legal transitions between them. You are not stuck with new/open/resolved. Define the states your team uses and RT will enforce them.
  • Scrips run automation on ticket events: notify a group on escalation, set a due date on creation, move a ticket between queues on a status change.

Try it on the queue you created

  1. Go to Admin > Custom Fields > Create and add one field your process actually needs, for example a Severity select field. Apply it to your queue, then create a ticket and set the value.
  2. Go to Admin > Lifecycles and read through the default lifecycle. Note which states your team would add or rename before you went live.
  3. Go to Admin > Scrips and look at the scrips already running on your trial site. These are the notifications firing behind the tickets you have been creating.

Post-onboarding: Lifecycles, Scrip conditions and actions, Templates, and SLA.

Step 5. Build a search and a dashboard

Once tickets are flowing, make the system answer questions.

Build the search

  1. Open Search > New Search to reach the Query Builder, and build a search that matches how one person on your team actually works, for example open tickets you own in your Support queue that are due this week. Add each condition, then click Add these terms and Search.
  2. If you would rather type the query directly, the Advanced tab holds the same search as editable TicketSQL. The two views stay in sync, so you can start in one and finish in the other.

Save the search

Back on the Query Builder, give the search a name in the save panel and choose who it is visible to: just you, a group, or everyone. Saving is what makes the search reusable and what lets you put it on a dashboard. The Query builder documentation covers the save options in detail.

Put it on a dashboard

  1. Create a dashboard, then add your saved search to it as dashboard content. The Dashboards documentation walks through creating a dashboard and choosing what goes on it.
  2. Subscribe to the dashboard so it arrives by email on a schedule.

Saved searches and dashboards can both be shared with a group, so the whole team gets the same view instead of each person rebuilding it.

Post-onboarding: Query builder, Dashboards, Charts, and Reminders.

Step 6. Think about how RT can connect to the rest of your stack

  • REST 2 API. Can read and write tickets, queues, users, and custom fields programmatically.
  • Extensions. Many extensions are available to add additional functionality to RT, including custom forms, customer surveys, and automatic ticket assignment.
  • AI, on your terms. RT’s AI features are bring-your-own-model: connect the provider you already use, or run a model locally, with your own API key. There is no proprietary AI subscription, and ticket data stays within the AI environment you choose and control.

Post-onboarding: Extensions, Automating RT, and AI Power for Request Tracker.

What your trial includes

Trial
Length14 days
Time to provisionWelcome email in a minute or two, site normally ready in about five minutes
Site addressIssued under try.requesttracker.io. Custom domains are available on plans that include them.
Starting contentA sample helpdesk configuration, fully editable
Feature setComplete RT feature set, no gating
HostingDedicated environment on AWS, managed by Best Practical
Patching and updatesManaged by Best Practical
EmailA provisioned testing address, supplied in your welcome email. Trial sites do not connect to your own mail server.
Ticket volume and storageSized for evaluation, not metered against a published cap
EligibilityBusiness email domains; consumer providers are not accepted
Data exportYou own your data and can export it at any time

Your trial is sized for evaluation. If you are planning to import a large existing dataset during the trial, tell us first at sales@bestpractical.com and we will make sure the instance is sized for it.

Move from trial to a paid plan

Cloud RT plans differ on scale and support, never on features. Every plan gets the full RT feature set. What changes between tiers is ticket volume, storage, support channel and SLA, and options like SSO, custom domain, data residency and failover, and a separate development environment.

Current plans and prices are on the Cloud RT pricing page. Cloud RT is priced per user, with plan minimums. We also offer capacity-based pricing, so you don’t have to worry about additional costs each time you add users as your organization expands its adoption of RT.

There are two ways to convert, and both keep the instance you have already configured.

Subscribe from inside RT. Your trial instance homepage carries a subscribe link that takes you straight to the Cloud RT plans. This is the fastest path, and it is the one to use if you already know which plan you want.

Talk to us. Write to sales@bestpractical.com. Use this if you want help sizing a plan, you are comparing Cloud RT against staying self-hosted, or you have requirements around SSO, data residency, custom domains, or a separate development environment.

Either way, everything you built carries over as long as you subscribe before your trial period ends. The queues, custom fields, lifecycles, scrips, dashboards, and tickets from your trial are the ones you keep. If you subscribe to a plan that includes a custom domain, we move your site off the try.requesttracker.io address at the same time.

Subscribe before the trial period ends to keep your configuration and data. If you need more time to evaluate, write to sales@bestpractical.com before your trial expires rather than after.

Where to go next