Test your processes

Step 5 of migrating from TWICE 1.0. Run your own processes on your own data, without help from TWICE. If you need someone on a call to complete a case, your staff cannot do it on the day either. Each case must produce what the customer receives, not only a correct record in the admin. A confirmation that renders correctly in the admin and never arrives in an inbox is a failure you will otherwise find on your busiest morning.

​

The cases

Cases below the handover row only apply if you take dated bookings — an extension or a late return has no meaning where the item never comes back. Skip the ones that do not describe anything you sell, and say in writing which you skipped, so nobody later assumes they passed. Run each case as the person who will actually do it. A manager completing a return proves the software works; it does not prove the counter staff can do it.

​

When something fails

A failed case is a normal outcome at this stage and a cheap one. Fix it, or write down the workaround and make sure the staff who need it know — an undocumented workaround is the same as an unfixed failure. Archive the test orders before you go live, under Settings → Archived assets.

​

Done when

• Every case above has been run by your own people.
• Each produced its customer-facing output in a real inbox.
• Anything that failed is fixed, or has a written workaround your staff know about.
• Your reports show the test orders correctly.

​

Related articles