Web Studioオーナーからの人生のヒント:収益性を高めてリスクを減らす方法。 パート1

各Webスタジオには、顧客との作業時に独自のトリックと「チップ」があり、インターネットプロジェクトを開発する際のリスクを最小限に抑え、作業の各段階でコストを削減できます。 Yumisoftでの活動の性質上、Webスタジオの所有者と頻繁にコミュニケーションを取り、ようやく非公式の会話で聞いた興味深いレシピを共有するようになりました。 私は彼らがあなたに役立つことを願っています:)



これらの手法は誰にとっても普遍的なものではないことをすぐに言わなければなりません。一部の手法は、大規模な顧客、高予算、個々のプロジェクトを扱う企業にのみ適しています。 一部の手法は、ウェブサイトの開発が流れている企業にのみ関連します(またはこれを達成したい場合)。 いずれにせよ、あなたはあなたの会社でこれまたはその実践が実行可能であるかどうか、そしてそれがあなたにとって役立つかどうかを決定します。



1.顧客検索



匿名を希望する地域パートナーの経験:

Free-lance.ruは、多くの場合、Webスタジオから顧客をリードする競合他社として認識されています。 私的な会話で、私はこの意見に対する実際的な反論を聞いた。

同社はFree-lance.ruでアカウントを作成し、ポートフォリオに記入し、顧客に評価とレビューを残すように依頼し、公開された注文の定期的なレビューと入札への対応を開始しました。

結果: 100万ルーブル。 この活動の総費用は5万ルーブルで年間売上高に。 (サイトのアカウントを維持し、ユーザープロファイルの料金を支払う時間)。

範囲:この慣行は、平均価格セグメント(サイトの開発に3万から8万ルーブル)以下で働く人に適しています。 同時に、地域企業にとっては、これにより、資本顧客にリーチし、ポートフォリオに取り組むことができます。



2.契約の締結



契約を締結する段階で、企業のリスクを最小限に抑えることができます。 さらに、契約で規定されているポイントのいくつかは、「何かが起こった場合」を確保するだけでなく、他の段階で顧客と作業するプロセスを最適化することを可能にします。

インターネットエージェンシーTRINETからの実践がこのセクションの基礎になりました。



2.1。 調整の難しさ

顧客側の遅延は、多くの場合、長い内部承認と責任者の不在が原因で発生しますが、その解決策は最後の手段です。 原則として、そのような人物の役割は会社の総取締役である場合があります。 しかし、多くの場合、彼はすべての準備が整うまでプロセスに参加せず、その後、自分で調整を始めます。 明らかに、これにより作業の時間と範囲が増加します。 これは契約により回避できます。

フォームの契約の別館が作成されます:

契約NNの付録N

顧客によるプロジェクトの開発責任者のリスト

1.プロジェクトのすべてのセクションの設計の承認

姓I.O.

連絡先電話番号:()--

連絡先メールアドレス:mail@mail.ru

(署名)
2.委任事項の承認

姓I.O.

連絡先電話番号:()--

連絡先メールアドレス:mail@mail.ru

(署名)
3.請負業者との全業務範囲の受け入れ

姓I.O.

連絡先電話番号:()--

連絡先メールアドレス:mail@mail.ru

(署名)


そのようなアプリケーションが署名されている場合、これは開発者が他の人からの調整を受け入れる義務を負わないことを意味します。 実際には、ほとんどの場合、契約にそのようなアイテムが存在することは、少なくとも心理的には顧客を著しく規律します。 しかし、これはスタジオが譲歩する可能性を排除するものではありません-彼女にとって適切と思われる限り。



2.2。 必要な資料を提供していない

状況は顧客にとって非常に典型的です。 この場合も、プロジェクトの完了が遅れます。 契約の次の条項は、そのような状況が発生した場合のコストを最小限に抑えることを許可しています。



顧客は、データ転送ステージに先行する、付録Nで指定された作業の完了日から5営業日以内に、付録Nで指定されたステージの実装に必要なすべてのデータを提供することを約束します。

お客様がパラグラフaの条件を順守しない場合。 本契約の次の作業段階の開始日は、請負業者によって延期できますが、必要な資料の提供後20営業日以内に延期できます。



実際にはどのように機能しますか? 開発者は、顧客の資料なしで作業を可能な限り最大限に完了し、その後プロジェクトを「フリーズ」します。 同時に、顧客が必要な資料を提供すると、開発者は現在のプロジェクトを放棄して従業員の作業負荷を再配分したり、常に無料のリソースを保持したりする義務はありません。 開発者は、契約で次の作業段階に進み、トラブルを回避できる期間を説明します。

契約におけるこれらの義務は、いかなる場合でも顧客の利益を侵害しません。 顧客がインターネットプロジェクトに興味を持っている場合、そのような義務なしにすべてを時間通りに提供します。 興味がなく、プロセスを引きずり出したい場合は、スタジオでリスクを減らすことができます。



2.3。 長期契約のリスク

サイトの技術サポートなど、恒久的または定期的なサービスの提供に関する契約を締結する場合、スタジオは、契約で設定された価格で、契約期間中に記載されたサービスの全額を提供する義務があるという事実を危険にさらします。 契約が1年間締結され、市場の状況が変化した場合、開発者が価格を上げるなどの契約条件を変更することは容易ではありません。 これは、次の点で回避できます。



本契約は一方的に終了する場合があります。 この場合、契約の終了を開始した当事者は、少なくとも契約の終了30日前に相手方に通知するものとします。



これは、何らかの理由で、契約がその形式でお客様にとって関心を失う場合、いつでも契約を終了できることを意味します。 さらに、この契約の終了後、新しい条件(たとえば、新しい価格)または追加で新しい契約を締結することを誰も気にしません。 価格の変更を伴う現在の契約への同意。

顧客は主に自分自身に投影するため、通常、このような条項に非常に簡単に同意します。 一方、顧客が仕事に満足していない場合、そのようなアイテムの有無は状況の改善に影響を与えることはできません。



2.4。 署名行為

これは、顧客側で常に迅速に行われるとは限りません。 時には客観的な理由で、時には組織的な問題のために。 この場合、開発者は次の条項を契約に含めることで自分を保護できます。



作業の各段階の完了後、請負業者は顧客に作業の転送と受諾の行為を提供し、顧客は受理日から5(5)営業日以内に承認するか、または作業の受理を理由付けられた拒否を与えます。 お客様による作品の譲渡行為の日から5(5)営業日以内に、作品の受け入れを理由として拒否することが不可能な場合、その作品は受け入れられたと見なされます。



正式には、これは開発者が登録レターで証明書を顧客に送信する必要があることを意味し、レシートを受け取った瞬間から5日以内に理由のない拒否で登録レターを受け取らない場合、作業は受け入れられたと見なされます。 そのようなプロセスをより簡単に整理することは、会社が顧客であるほど大きくなると理解できると思います。 このような行動は、紛争が発生した場合に関係の改善にはつながりませんが、望ましくない裁判のリスクがある場合には非常に適切です。



将来のプロジェクトの不採算の内部リスクを減らす方法。 Alexey Samoilov 、Kinetika Internet Agencyのヘッド:

「Webスタジオの従業員に対する支払いスキームは、経済的な観点から考えると、多くの場合、事業主にとって有益ではありません。 そのため、セールスマネージャーはサイトを販売しました。 ただし、これはセールとは見なされません。 商品が出荷されていないため、販売行為はまだ行われていません。



私は例えを言います:私は基地に来て、小麦粉の袋のためにレジ係にお金を与えました。 売り手はまだ私にそれを売っていません-結局、私は倉庫のもう一方の端に行きます、そして、そこにだけ店主が私に商品を出荷します。 私は彼女が好きなら、私は請求書にサインして、私の肩にバッグを置いて、家に帰ります。 今、販売が行われました。 しかし、突然倉庫の小麦粉の品質を疑った場合、店主は私に失礼だった、または私は小麦粉を必要としない方法に沿って気付いた(ところで、ウェブ上の典型的な状況)、その後、私は非常に安全にレジに戻ってお金を集めることができます。

お金を集めるためにキャッシュデスクに戻りますが、基地が非常に長く、1か月など非常に長い間歩いていると想像してください。 初日が来て、レジ係は私に売られた小麦粉のレジから自分のパーセンテージを取ります。 2日目にレジに行き、購入しなかった商品のお金を集めます。 キャッシャーは彼のボーナスを受け取り、私はお金を返しました。 事業主は赤のままでした。



Webスタジオの場合、この状況は非常に特徴的です。 もちろん、より複雑でベールに包まれたバージョンでは(たとえば、彼らは小麦粉の袋を支払い、ヘロインの袋を取りました)。 これを避けることは、他の貿易分野と同じことをすれば難しくありません-売上の割合は常に商品の出荷後に計算されます。 私たちの場合、各段階の作業証明書に署名した後。 したがって、アカウントに「100万」の新しい売上があっても、このお金が実際に売上になるまで売上の割合を支払う必要はありません。

理想的には、すべての従業員がこのスキームに従って作業する必要があります。 実際には、これを実装することは難しく、実際には、所有者のみが危険にさらされています。 しかし、このようなスキームは、すべての従業員に適用できるわけではない場合、管理職に確実に適用されます。 もちろん、特定の会社に応じて、変更する必要があります。」



第2部では、設計の開発と承認の段階でのレシピ、CMSとプログラミングの実装、およびプロジェクトの実施について説明します。 一般的に、継続する:)。



UPD:ここは2番目の部分です



All Articles