State machine

At the core of every good system is a good state machine, and that's what we've been building for the past few weeks. As a customer service platform, it's doubly important since it helps us answer the following questions per customer: What state are they in, why are they in this state, and when something happens, what state should they transition to?

In Plain, customers are in one of three states: IdleActive and Snoozed.

When a customer is Active it means they are waiting to be helped. When they are Snoozed it means we are waiting for something to happen for them to be brought back to the attention of an advisor. When they are Idle it means that we think there is nothing left to do 😌

Our state machine is there to handle different events happening and consistently transition customers to the right state. For example, if an issue is opened, an Idle customer will be transitioned to Active. Importantly the state machine also enforces certain requirements such as preventing a customer with open issues to transition from Active to Idle. There are many many transitions and conditions - thank god for Whimsical.

While building this, we had an interesting debate as a team around how to best handle status in our app. We didn't feel that exposing customer status one-to-one from our API to the support app would offer a very good experience to first-time users. Equally, we were unsure about having one term within our API and another in our app since that could lead to an odd developer experience.

After some experimentation and testing, we ultimately decided that the context was so different between our API and the day to day work of an advisor that the best solution was to have different wording for the same statuses. That's how we ultimately ended up on:

Customer details panel

Thanks to Aimee Quantrill for helping us iterate on the right language here and land on something that felt human and intuitive!

  • #changelog
© Plain. CS without the BS since 2020.