Cara Membina Portal Pelanggan: Fail, Status, Invois dan Kebenaran

Portal pelanggan ialah kawasan persendirian di mana setiap pelanggan anda log masuk untuk melihat status projek, fail yang dikongsi, permintaan yang terbuka dan invois mereka. Untuk membinanya, tentukan dengan tepat apa yang perlu dilihat oleh pelanggan dalam sepuluh saat pertama, model pelanggan, projek dan fail supaya setiap rekod tergolong kepada satu pelanggan, kuatkuasakan di pelayan bahawa pelanggan hanya melihat rekod mereka sendiri, dan simpan muat naik dalam storan persendirian. Senarai ciri boleh kekal pendek; mendapatkan kebenaran dengan betul ialah perkara yang paling penting.

Mengapa perniagaan membina portal pelanggan

Portal biasanya menggantikan timbunan benang e-mel, folder dikongsi dan mesej "apa statusnya?". Ejen, akauntan, perunding, pembina, studio dan perniagaan perkhidmatan semuanya menggunakannya. Portal yang baik:

• Menjawab soalan status sebelum pelanggan bertanya.
• Meletakkan fail di satu tempat, dengan versi terkini jelas kelihatan.
• Memberikan permintaan rumah yang sesuai dan bukannya e-mel yang bertebaran.
• Menjadikan anda kelihatan teratur, yang penting untuk pengekalan dan rujukan.

Jika anda hanya mempunyai satu atau dua pelanggan dan tiada apa yang sensitif, dokumen atau folder dikongsi mungkin memadai. Portal berbaloi dibina apabila anda mempunyai ramai pelanggan, kerja berulang, atau maklumat yang pelanggan tidak sepatutnya lihat tentang satu sama lain.

Apa yang diperlukan oleh portal pelanggan

Mulakan dengan log masuk, gambaran keseluruhan, fail dan permintaan. Tambah invois, kelulusan dan pemesejan apabila pelanggan benar-benar memerlukannya.

Data

Portal biasa mempunyai: pelanggan (syarikat), pengguna pelanggan (orang yang log masuk, tergolong kepada satu pelanggan), ahli pasukan anda, projek (tergolong kepada satu pelanggan), pencapaian atau kemas kini status, fail (tergolong kepada satu projek), permintaan, dan secara pilihan invois. Peraturan reka bentuk utama: setiap rekod hendaklah dapat dikesan kembali kepada tepat satu pelanggan. Ini menjadikan kebenaran mudah untuk dikuatkuasakan dan disemak.

Kebenaran

Tulis ini dan uji:

• Pengguna pelanggan hanya melihat projek, fail, permintaan dan invois yang tergolong kepada pelanggan mereka.
• Nota dalaman tidak sekali-kali dipaparkan kepada pelanggan.
• Ahli pasukan melihat pelanggan yang ditugaskan kepada mereka, atau semua pelanggan jika anda kecil.
• Pautan fail adalah persendirian dan terhad masa, bukan URL awam yang sesiapa boleh kongsi atau teka.
• Membuang pengguna pelanggan serta-merta menamatkan aksesnya.

Pemeriksaan mesti berlaku di pelayan. Portal yang memuatkan data semua pelanggan dan menapisnya dalam pelayar bukanlah persendirian.

Keputusan dan pertukaran

Kaedah log masuk

Pelanggan jarang log masuk, jadi mereka sering terlupa kata laluan. Pautan ajaib (pautan log masuk yang dihantar melalui e-mel) atau log masuk tunggal dengan akaun yang sudah mereka gunakan selalunya lebih baik daripada kata laluan untuk portal. Apa pun pilihan anda, jemput pelanggan dari pihak anda dan bukannya membenarkan sesiapa sahaja mendaftar sendiri. Panduan kami tentang menambah log masuk pada apl anda membandingkan pilihan tersebut.

Satu portal atau satu bagi setiap pelanggan

Satu apl dengan senarai pelanggan lebih mudah diselenggara daripada laman berasingan bagi setiap pelanggan. Anda masih boleh memberikan setiap pelanggan rasa berjenama mereka sendiri - logo mereka, nama projek mereka - dalam apl yang sama.

Fail

Gunakan storan fail yang betul dan bukannya menyimpan muat naik pada cakera pelayan sendiri, tetapkan saiz fail maksimum, hadkan jenis fail jika boleh, dan hanya hidangkan fail kepada pengguna yang lulus pemeriksaan kebenaran. Tentukan cara versi berfungsi: menimpa, atau menyimpan sejarah.

Invois dan pembayaran

Anda boleh memaparkan invois daripada alat perakaunan anda, menjana invois ringkas dalam portal, atau memautkan ke halaman pembayaran yang dihoskan. Membina sistem invois penuh ialah projek tersendiri - lihat cara membina apl invois. Untuk portal, memaparkan status invois dan pautan "Bayar sekarang" ke checkout yang dihoskan biasanya sudah memadai.

Integrasi

Banyak portal menarik status daripada alat yang anda sudah gunakan - pengesan projek, CRM atau perisian perakaunan - dan bukannya meminta anda mengemas kini dua tempat. Integrasi menjimatkan masa tetapi menambah persediaan dan penyelenggaraan. Jika pasukan anda sudah menggunakan CRM, pertimbangkan untuk membina portal di atas data yang sama.

Prompt pertama untuk pembina AI

Bina portal pelanggan untuk Northlight, sebuah agensi reka bentuk web kecil. Pelanggan ialah syarikat; setiap satu mempunyai satu atau lebih pengguna pelanggan yang log masuk. Pengguna pelanggan hanya melihat projek syarikat mereka sendiri. Bagi setiap projek: status semasa (Penemuan, Reka Bentuk, Binaan, Semakan, Langsung), pencapaian seterusnya dengan tarikh, ruang fail di mana kedua-dua pihak boleh muat naik dan muat turun (PDF, imej, ZIP, maksimum 50 MB), borang permintaan (tajuk, butiran, keutamaan) dengan senarai permintaan lepas mereka dan status, serta garis masa kemas kini. Ahli pasukan agensi melihat ruang pentadbir dengan semua pelanggan, boleh menukar status projek, menyiarkan kemas kini, menambah nota dalaman yang tidak pernah dilihat oleh pelanggan, dan menjawab permintaan. Kuatkuasakan semua peraturan akses di pelayan. Simpan data dalam pangkalan data dan fail dalam storan fail persendirian dengan pautan muat turun yang terhad masa. Log masuk placeholder buat masa ini - kami akan menambah pengesahan sebenar kemudian. Reka bentuk yang kemas dan profesional yang berfungsi pada telefon.

Bina secara berperingkat: data dan pentadbir dahulu, kemudian paparan pelanggan, kemudian log masuk sebenar, kemudian fail, kemudian tambahan. Cara menulis prompt untuk pembina apl AI mempunyai lebih banyak corak.

Langkah membina

1. Senaraikan apa yang pelanggan perlu lihat dahulu, dan apa yang mereka kini e-melkan kepada anda.
2. Reka bentuk data supaya setiap rekod tergolong kepada satu pelanggan.
3. Bina paparan pentadbir dan masukkan data sebenar satu pelanggan.
4. Bina paparan pelanggan untuk pelanggan itu.
5. Tambah log masuk sebenar dengan jemputan dari pihak anda.
6. Tambah fail dalam storan persendirian dengan pemeriksaan kebenaran semasa muat turun.
7. Uji kebenaran: cipta dua pelanggan ujian dan cuba setiap cara untuk melihat data yang lain - menukar ID dalam URL, meneka pautan fail, menggunakan jemputan lama.
8. Tambah permintaan dan pemberitahuan melalui e-mel.
9. Lakukan pilot dengan satu atau dua pelanggan yang mesra dan tanya apa yang mereka masih e-melkan kepada anda.
10. Tambah invois, kelulusan atau integrasi berdasarkan maklum balas itu.

Kesilapan biasa

• Menapis dalam pelayar dan bukannya di pelayan. Bug portal yang paling serius: data setiap pelanggan dimuat turun, cuma disembunyikan.
• URL fail awam. Pautan kongsi yang sesiapa pun boleh buka mengalahkan tujuan portal.
• Pendaftaran terbuka. Pelanggan harus dijemput, bukan boleh membuat akaun sendiri dan memilih syarikat.
• Terlalu banyak ciri semasa pelancaran. Portal yang pelanggan tidak fahami akan diabaikan dan mereka kembali kepada e-mel.
• Dua sumber kebenaran. Jika status berada dalam alat projek anda dan juga portal, satu akan ketinggalan zaman. Pilih satu atau segerakkan keduanya.
• Terlupa menamatkan akses. Apabila kakitangan pelanggan pergi, akses mereka mesti ditamatkan.
• Menyimpan data yang dikawal selia tanpa perlindungan yang betul. Rekod kesihatan, undang-undang atau kewangan mungkin membawa keperluan undang-undang yang perlu anda penuhi.

Kos dan alat

Kos operasi ialah pengehosan, pangkalan data, storan fail (yang meningkat seiring dengan fail yang anda kongsi), dan pembekal e-mel untuk jemputan dan pemberitahuan. Jika anda menggunakan pembekal log masuk atau pembayaran yang dihoskan, semak harga semasa mereka di laman mereka sendiri. Berbanding perisian portal yang dikenakan bayaran setiap tempat duduk, kos portal anda sendiri meningkat mengikut penggunaan dan bukannya mengikut bilangan pelanggan.

Bila produk siap sedia lebih sesuai

Perisian portal pelanggan, dan ciri portal yang dibina dalam alat perakaunan, perundangan atau pengurusan amalan, boleh menjadi pilihan yang lebih baik apabila industri anda mempunyai keperluan khusus - tandatangan elektronik yang mempunyai kesan undang-undang, penyimpanan rekod yang dikawal selia, pertukaran dokumen cukai - atau apabila alat sedia ada anda sudah menyertakan portal. Produk tersebut telah mengendalikan pematuhan dan sokongan. Bina sendiri apabila aliran kerja anda tidak sesuai dengan portal generik, apabila anda mahukan portal yang sepadan dengan jenama dan proses anda dengan tepat, atau apabila harga setiap pelanggan atau setiap tempat duduk tidak lagi munasabah bagi anda.

Membina dengan Mythex

Mythex boleh membina portal dalam prompt di atas: paparan pelanggan, paparan pentadbir, permintaan dan garis masa, dengan pangkalan data Postgres khusus dan storan fail yang ditambah apabila apl memerlukannya. Log masuk pelanggan ialah bawa-sendiri - akaun Mythex adalah untuk orang yang membina apl, dan anda memilih pendekatan auth untuk pelanggan anda yang dimasukkan oleh ejen. Mythex tidak mempunyai produk tandatangan elektronik atau invois terbina dalam, jadi itu adalah integrasi atau ciri yang anda bina sendiri. Gunakan rahsia projek untuk sebarang kunci API, dan gunakan penguji apl dalam sembang untuk melayari aliran pelanggan dan pentadbir sebelum anda menerbitkan.

Dokumentasi mempunyai use case portal pelanggan dan meliputi storan fail serta menambah log masuk. Untuk prompt permulaan, cuba templat portal klien agensi atau layari templat apl. Sebelum menjemput pelanggan sebenar, jalankan senarai semak keselamatan untuk apl yang dibina dengan AI kami.

Soalan lazim