セルフサービスのプラン変更チェックアウトフロー
共有者はGustoの行動面接(ビヘイビアラル面接)でまさにこのプロジェクトを語り、内定を獲得しました。
この面接を練習する
実際の深掘り4問 · うち難問1 · 約12分
各質問に自分で答えると、本人の実際の答えが見られます。
本人はこう語った
中小企業の管理者がサポートにメールしなくても、自分でプランのアップグレード/ダウングレードができるガイド付きフローです。
全文を読む
私のチームでは、プランを変更したい顧客はサポートにメールし、サポートが手作業で変更していました。私のインターンプロジェクトは、既存のReactアプリ内のセルフサービスのプラン変更フローでした。新しいプランを選び、支払額と変更点のビフォー/アフターを明確に確認して、確定する、というものです。実際の課金ロジックには触れていません——日割り(proration)のプレビューを返す既存の社内価格エンドポイントと、実際の変更を行う別の確定エンドポイントを呼びました。作業の大半はフロントエンドの状態管理でした。フローにはプレビューのステップと確定のステップがあり、プレビューで見せた価格が確定時に適用される価格と厳密に一致することを保証しなければなりません。画面を開いたまま深夜0時を跨ぐと日割り額がずれることがあるからです。これは、プレビューのquote IDを確定の呼び出しに渡し、古くなったquoteはバックエンドに拒否させることで対処しました。こうすれば、表示した数字と違う金額を黙って請求することは絶対に起きません。失敗時の状態にも本気で時間をかけました——カードの拒否、quoteの期限切れなど——中小企業のオーナーにとって、中途半端に終わったプラン変更は怖いものだからです。インターンの終盤に、feature flagの裏で一部のアカウントに向けてリリースされました。
実際に聞かれた質問
プレビューで表示した価格が確定時に請求される価格と一致することを、どう保証したのですか?
難しい課金には触れていないとのことですが、ではフロントエンドプロジェクトとして実際に難しかったのは何ですか?
普通なぜ別のフローとしてではなく、既存のReactアプリの中に作ったのですか?
易しいトラフィックが10倍になったら、このフローの何が心配ですか?
普通