Go-live checklist

Run through this before the first real job goes out. Each item is something that’s quick to fix now and awkward to fix with customers waiting. Most of it needs the Tenant Admin role.

If you haven’t set up yet, start with Set up WorkWing for the first time.

Your organisation and brands

• The Workspace URL under Settings > Organisation profile is the one you want. It’s fixed 24 hours after sign-up, so if it’s still changeable, decide now.
• Each brand has its logo and colour, so customer emails look like you. See Appearance.
• The job number format under Job settings is the one you’ll keep. Your test jobs will already have used some numbers.
• Business hours are set for each brand, if any job type counts its SLA in business hours.

People and permissions

• Everyone who’ll use WorkWing has accepted their invitation. Nothing is left under Colleague invitations or Pending external invitations in Settings > Team Members that you don’t expect.
• Each person holds the least role that lets them do their job. Only the people who need it are Tenant Admins. See Roles and permissions.
• Every engineer shows on Resources, with working hours set. See Availability and location.
• External workers have the right access end date, and two-factor where you want it. See External workers.
• Anyone who’s left has been removed, which signs them out everywhere and frees their seat.

Sign-in and security

• The sign-in methods under Settings > Authentication suit both the office and the field. Engineers who signed up with an email code need Email code left on. See Authentication and SSO.
• If you’ve set up single sign-on, Test Connection passes and at least one administrator has signed in through it, before you enforce it.
• Two-factor, location sharing, screenshots and reporting from mobile are set the way you want under Settings > Security. If two-factor is required, everyone has set it up on the web already. See Security policies.
• If you require location sharing, your engineers know, and your data retention and privacy policy cover it.

Job types

• Every job type you’ll use is active, and the ones you won’t are switched off so they don’t appear on the create form.
• Each has been run through at least one complete job on a phone. Required fields such as a signature stop the engineer until they’re done, and the answers land on the job in the web app.
• Durations, default priorities and SLA targets match how you actually work. See Creating a job type.
• Job types that need particular skills have them set, and your engineers have those skills recorded, if you use auto-assignment.

The mobile app

• Every engineer has the app on an iPhone and has signed in at least once, with a connection. First sign-in on a device can’t happen offline.
• Notifications are allowed on each phone. An engineer who declined sees Enable Notifications under Me > Settings.
• Someone has worked a test job with the phone in airplane mode, and watched it send when the signal came back. See Working offline.
• Engineers who work for another WorkWing customer too know how to switch organisation from Me, and that switching with unsent work loses it.

Onboard your first field engineer covers all of this for one person.

What your customers receive

• You’ve read each email under Email templates in the wording your customers will see, and turned off any you don’t want sent.
• Customers you want to hear from you have Email Opt-in or SMS Opt-in ticked. Without it they get nothing.
• The en-route text is switched on for the brands that should send it. It needs the Basic plan or above and goes to UK numbers. See Customer notifications.
• If you’re on the Professional plan and use the customer portal, you’ve opened a tracking link yourself and seen what a customer sees.

Send the test jobs to a customer record with your own email address, so the first copy of every email lands with you.

Integrations, webhooks and API keys

• Each integration has been run from the Test console and from a job form on a phone, and the run shows in its history. See Execution and history.
• Each webhook endpoint is reachable from the public internet, checks the signature, and shows successful attempts under Deliveries. You’ve stored the signing secret, because it’s shown once.
• Each API key is named after what uses it, belongs to the right brand, and carries only the permissions it needs. Nothing holds Full Access that doesn’t have to. Keys for temporary work have an expiry, and keys for servers with fixed addresses have an IP restriction.
• Keys and webhook URLs used during testing have been revoked or deleted.
• If anyone has connected an AI assistant, they’re happy for it to do whatever their own role allows, because it acts as them. See AI assistants.

Billing

• You’re on the plan you mean to be on, with enough seats for everyone. See Billing and plans.
• You’ve chosen Hard cap or Pay-as-you-grow under Account > Billing, and you know what happens when you reach your job allowance. See Plan limits and overage.

End-to-end jobs

Before go-live, run several complete jobs the way real ones will run: created by your dispatchers, assigned or scheduled on the dispatch console, worked on the phone, and completed. Include one that fails with Can’t complete and one that’s rescheduled, so your team has seen both.

Afterwards, delete the test jobs so they don’t sit in your reports. Deleting needs the Brand Administrator or Tenant Admin role. Test jobs count against your job allowance once someone is assigned, but repeat visits to the same customer at the same location count once, so keep your tests on one test customer.

Who to contact

Email support@workwing.io. It reaches the people who build WorkWing. Include your organisation name, the job number or screen you were on, and whether it was the web app or the phone. For an API problem, include the request id from the response.

An engineer can send a report straight from the app with Report a Problem under Me > Settings. It carries the app version and their account details, so nobody has to copy them off a screen.