
01買取
買取受付・査定アプリ
出張買取の予約と訪問の管理、店頭での査定の記録、査定額の根拠の記録。受付から成約後の出品準備までを一つの流れにします。
買取、ささげ、在庫、販売、本部の数字まで。リユースの業務を知っているチームが、既製のシステムとつなぎながら、足りないところを作ります。
リユースの業務には、一点ものの在庫、買取と販売をまたぐ原価、販路ごとの出品仕様のように、数量を前提に作られた汎用のシステムでは収まらない部分があります。その部分を、現場では電話や表計算、紙で補っています。
私たちは、既製のもので足りる部分と作る部分を切り分けるところから入り、足りない部分だけを業務に合わせて作ります。AIは開発の手段として使い、商品説明のように書く作業が多い業務にも組み込みます。

リユースの業務の流れに沿って並べています。既製のサービスで足りる部分はそのまま使い、足りない部分だけを作ります。

01買取
出張買取の予約と訪問の管理、店頭での査定の記録、査定額の根拠の記録。受付から成約後の出品準備までを一つの流れにします。

02ささげ
商品説明、状態の説明、査定のコメント、問い合わせへの返信の下書きをAIが作り、担当者が確認して確定します。お客様側にAIの知識は要りません。

03ささげ
撮影・採寸・原稿の後の、販路ごとの出品データの作成と送信を自動化します。複数の販路へ同じ在庫から出し、売れたら他の販路の出品を下げます。

04在庫
一点ものの在庫を数量ではなく所在で管理し、店頭の販売と在庫の数字を一致させます。既存POSの範囲外を補う開発から、POSと在庫管理(OMS)の個別開発まで。

05販売
自社ECの構築と、既存のカートからの移行。在庫と受注を基幹とつなぎ、店舗とECで同じ在庫を売ります。

06販売
国内の在庫をeBayに出品し、受注と在庫を国内の基幹と同期します。英文の出品原稿は、書く作業のAI化と合わせて作ります。

07販売
複数の販路の受注を一か所に集め、発送通知の送信と、販路別の入金照合までを人の手を挟まずにつなぎます。

08本部
店舗と販路の実績を自動で集め、数字の定義を統一します。手作業で続いている費用の集計も、同じ仕組みに載せ替えます。

09顧客
買取や在庫の問い合わせにAIが一次応答し、担当者が確認して返します。会員証、ポイント、買取の受付、通知を同じLINEに集めます。

10顧客
買取のお客様と購入のお客様の履歴を一つにし、再来店と再買取の働きかけに使います。
買取から本部の数字までの流れの、どこに何を置くかを示した図です。顧客との接点は、買取と販売の両側にあります。
開発を「決める」「作る」「確かめる」に分けると、AIを使うのは「作る」の中だけです。決めるのはお客様と技術者、確かめるのは技術者とお客様で、成果物の責任は当社が負います。
業務の流れ、画面、帳票をお客様と協議して確定し、技術者が設計書を作ります。以後はこの設計書を仕様の基準にします。
技術者が仕様を指定し、AIを使ってプログラム・テスト・文書の案を作ります。案は技術者が読み、設計と合わない部分は仕様を定め直して作り直します。
技術者の精査、自動テストを含むテスト、リリース判定の順で確認します。受入テストと検収はお客様が行います。
作る時間が短くなる分は、そのまま費用と納期に反映します。要件定義、設計、作成物の精査、受入テスト、検収、定着支援は、従来の開発と同じ内容で行います。
契約の形
進め方は2つあります。作るものが決まっているときは、成果物と金額を先に決めてから始めます。決めながら進めたいときは、月の金額と時間の枠を決め、その中で一緒に作っていきます。どちらにするかは、お話を伺ってから一緒に決めます。
Project
要件定義から開発・導入まで、何を作るかと金額を先に固めて進めます。金額が途中で動かないので、予算の確保と社内の説明がしやすい形です。規模の大きな開発に向いています。
Monthly
毎月の金額と時間の枠を決め、その中で優先度の高いものから順に作ります。要件が固まりきる前から始められ、状況に合わせて中身を変えられます。社内に開発の担当を置かずに、必要な期間だけ続けられます。
要件が固まっていなくて構いません。今の業務と困りごとを伺い、既製のもので足りる部分と、作る部分の切り分けからご一緒します。