__________________
http://www.idee-regalo.biz/regali-natale.html -
http://www.giftideashop.net/christmas-gift.html
Allora evita di utilizzare le email, o meglio, il professionista e il
cliente non devono mai vedere le reciproche email, solo
l'amministratore può.
I contatti tra professionista e cliente avverranno sul sito, saranno
però obbligati ad accedere.
Poi stà al sito inviare un'email al cliente o al professionista ogni
volta che ha una risposta (tipo le notifiche di facebook);
Se ho capito bene vuoi fare una roba del tipo 'rent a developer'.
Dimenticati però che il tuo sito si colleghi agli indirizzi email del
cliente e del professionista e ne gestisca le email tra di loro..
Anche perchè è l'unico modo di gestire la rintracciabilità e gli
storici.
advent net support center...che l'ultima volta che c'ho dato un'occhiata
era gratis (non so se per uso business anche).
funziona che apri un "ticket" (ma puoi "disegnare" la pagina in modo
tale che sembri qualcosa di diverso, imposti che arrivano solo agli
amministratori, dopodich� l'amministratore assegna tale "ticket" ad un
professionista.
ora hai due scelte, entrambi (cliente e pro) entrano nel sito e
continuano a rispondersi sul sito stesso oppure si mandano dalla loro
email un messaggio all'indirizzo del sito che integra un parser e
provvede (sulla base del codice nell'oggetto che non va modificato) a
rigirare il contenuto del messaggio alle persone che ruotano intorno al
ticket stesso ((in questo caso solo cliente e prof)
il professionista per rispondere al cliente manda un messaggio al sito e
questi lo ruota al cliente e ad ogni messaggio ruotato (al cliente o al
prof) lo stesso viene accodato nel ticket per lo storico o per una
consultazione pi� rapida
giusto per completezza per�...non ci azzecca nulla con php in quanto la
maggior parte � java e necessita di un server proprio (nel senso non si
accontenta solo di php e apache)
La lettura delle email e il parsing può benissimo essere fatto tramite
php, unico problema è che bisognerebbe prevedere un cronjob da
eseguire ogni minuto
se intendi che usi il prodotto "modificandolo" mi sa che sei fuori
strada...il tutto funziona da java e jboss (Application Server) che ti
installa lui quando esegui il tutto cio� � un qualcosa di parecchio
"proprietario" tanto per capirsi, se invece semplicemenmtne stai
prendendo l'idea allora per il cronjob non c'� bisogno di avere un
server web ma magari te la cavi con un hosting, esistono online siti che
permettono di fare schedulazioni di pagine sul proprio sito.
Dato che ha postato sul gruppo php ho dato per scontato che volesse
usare php per farlo,
quindi anche senza usare advent net support center, leggere e parsare
le email di un server smtp da php è fattibilisimo!
ah quello si...era perch� lui ha chiesto se per caso esistesse un cms o
qualcosa gi� fatto...anche perch� tecnicamente � OT il prodotto perch�
non mi ricordo una sola riga in php...per� (a mio avviso) � quello che
gli serve...altro non conosco.
tanto per chiarezza, lungi da me il voler fare pubblicit� dato che mi ci
sono scontrato (nel senso di scontro-dolore) parecchie volte coi loro
prodotti, l'ho citato solo per dare un aiuto...
Ok!
Diciamo cmq che io personalmente sconsiglio il discorso di utilizzare
le email parsata ad hoc;
Intanto per parsare gli allegati (ad esmepio) c'è letterlamente da
impazzire, inoltre, come tu hai detto, i clienti e i professionisti
dovrebbero mettersi in testa di non modificare mai una parte del
messaggio (ad esempio, l'oggetto dovrà sempre cominciare con la
stringa TO: $codice_cliente).
Sarebbe infinitamente più semplice 'obbligare' gli utenti a loggarsi
sul sito e ad utilizzarlo come unico vettore di comunicazione,
sicuramente è più 'scomodo' rispetto a inviare un'email, ma non lo
vedo come uno scoglio eccessivo o deterrente... e praticamente toglie
(a occhio e croce) un 20% del tempo di stesura del progetto
dipende quanto vuole smazzarsi lui a scrivere...di pronti cos� non ne
conosco...il problema � che secondo me lui alla fin fine vuole qualcosa
che se non lo � gi�, assomiglia molto ad un ticketing system...
il metodo di parsare le email � quello che ho visto usare, al di l�
dell'implementazione pi� o meno semplice e del fatto che dai in mano ad
un professionista MA ANCHE ad un potenziale incompetente una direttiva
come "non toccare mail il subject" purtroppo fa si che molte volte
accadr� il contrario (esperienza visto che quel coso lo uso).
il fatto � che lui chiedeva (se non sbaglio) di non doversi
loggare...non mi viene in mente altro che non sia un parsing delle mail
per riconoscere il treadh a meno di non mettere qualcosa di nascosto
nell'header..ma poi finisci che "e se il cliente scrive la mail ex-novo
invece di fare un reply?"...
Appunto, per evitare una cosa 'scomoda' (il loggarsi sul sito) si
rischia di creare un sistema cotoso, oneroso, e con un altissimo
indice di errore da parte dell'utente.
L'idea di nascondere un codice negli header dell'email è buona,
bisogna però vedere se non viene presa come spam..
Per evitare che il cliente scriva l'email ex-novo, basterebbe
utilizzare un'unico indirizzo email, ma con un alias per ogni cliente/
professionista, così almeno dovresti essere in grado di risalire a chi
voleva comunicare con chi, al massimo perdi il filo della discussione.
Come hai detto tutto dipende da lui, ma a stò punto io consiglierei
(ad esempio) di utilizzare il sito come vettore, poi magari trovare
qualcuno che crei un add-on per firefox che possa gestire le
comunicazioni (ad esempio).
Cmq vabbhè, di idee ce ne sarebbero anche troppe, sentiamo il creatore
del 3d che ne pensa (ormai il 3d lo mandiamo avanti io e te ;)
Esempio: il cliente fa una domanda attraverso il modulo contatti.
Arriva una mail all'admin, che decide il professionista e lo collega.
Arriva una mail al professionista che rispoonde.
La mail arriva direttamente al cliente (e viene salvata nell'archivio)
Il cliente risponde e arriva direttamente al professionista (e viene
salvata nell'archivio)
Ecc.
Voglio dire, ma se anche il cliente scrive la mail ex novo, non si
riesce a far capire al sito a quale professionista è stata assegnata
quella mail così da collegarli?
Grazie
Ciao
Sia il professionista che il cliente che email hanno?
Sono sul tuo server, con il tuo dominio?
Se la risposta è si, allora è possibile leggere le email anche da php,
parsarle ad hoc e fare quello che devi fare.
Ma credimi che è una cosa non proprio semplice..
Altrimenti, se il professionista ha un'email @libero.it e il cliente
@gmail.com, e si mandano un'email tra di loro, il tuo 'sito' come fà a
saperlo?
L'unica è che entrambi inviino le email a un tuo indirizzo email (tipo
risp...@tuosito.it).
Dal mittente potresti recuperare il destinatario (se l'admin lo
collega 'manualmente'), ma ogni volta perderesti il 'filo del
discorso', senza contare che se un cliente comunica contemporaneamente
con 2 professionisti (o vice versa), magari per progetti diversi, il
discorso non è più fattibile.
O meglio, è fattibile inserendo dei codici all'interno delle tue email
(come diceva Argaar), ma sono più i problemi che potrebbe dare questo
metodo che le soluzioni che offre.
Un'altra cosa che mi viene in mente, se non ti interessa avere avere
un threading, potrebbe essere utilizzare degli alias email: tu crei
solo un indirizzo email sul tuo server (risp...@tuosito.it) ma
configuri il server smtp in modo che le tutte le email inviate al tuo
dominio (*@tuosito.it) finiscano in quella cartella.
Al cliente mostri l'email fittizia del professionista
(pinco...@tuosito.it).
Al professionista mostri l'email fittizia del cliente
(pl...@tuosito.it).
Entrambe le email arrivano sul tuo server, tu le parsi, le archivi, ci
fai quel che devi fare insomma, poi le rigiri agli indirizzi reali dei
due.
Dovrai anche prevedere un anti-spam coi controcoglioni se pensi di
usare questo metodo.
>
> Un'altra cosa che mi viene in mente, se non ti interessa avere avere
> un threading, potrebbe essere utilizzare degli alias email
credo che sia quello che fa craigslist, no?
http://www.craigslist.org/about/sites
Bho, non ho mai visto prima mia quel sito (e non capisco a cosa
serve ;)
Cio� se ho ben capito, il cliente pippo apre il progetto
"faccio_un_bel_sito" il professionista pluto accetta, ora tu crei due
alias tipo
e
che sarebbero alias di un tuo solo indirizzo email reale e poi metti
delle regole (o un parser o altro) che tutto ci� che arriva per
pluto_at_etc dall'email reale del cliente lo lega come thread al
progetto "faccio_un_bel_sito" e spedisce alla vera email di pluto_at_etc
tutto giusto?
soluzione interessante che in fin dei conti per� tu devi prevedere un N
mila alias per ogni progetto...e gestirli....
e il sito come fa a sapere che il cliente sta scrivendo al
professionista e sta parlando del progetto X?
e se il cliente ha due progetti con lo stesso professionista il sito che
ne sa di cosa stanno parlando?
l'unica � mettere un qualcosa da cui tu puoi risalire ed identificare
correttamente il flusso delle informazioni scambiate, che sia un id
relativo al progetto, che sia un alias etc...qualcosa che distingua ci va
vendita/regalo di usato, in efetti in italia non funzionamolto, qua in
germania � usatissimo spesso la gente regala le cose giusto per non fare
la fatica di doverle andare a buttare (frigo vecchio, letto un po'
ammaccato etc).
Idea interessante!
ci darò un'occhiata
>> vendita/regalo di usato, in efetti in italia non funzionamolto, qua in
>> germania � usatissimo spesso la gente regala le cose giusto per non fare
>> la fatica di doverle andare a buttare (frigo vecchio, letto un po'
>> ammaccato etc).
>
> Idea interessante!
> ci dar� un'occhiata
o meglio, ci sono annunci di ogni tipo, pero' io lo uso nel modo che ti
ho descritto :)
Ho letto il 3d e scrivo solo per aggiungere una considerazione che
riguarda in generale il funzionamento di queste soluzioni "solo per il
sito", qualsiasi sia poi l'implementazione scelta per attuarla. Parto
dal presupposto che le esigenze siano due: tenere traccia sul sito
dell'intero carteggio tra cliente e fornitore ed impedire che i due
possano parlarsi direttamente, anche per evitare accordi extra-sito (che
cos� perderebbe la sua fonte di guadagno). Se � cos�, cosa vieta ai due
di scambiarsi il proprio indirizzo e-mail all'interno del corpo della
stessa per poi continuare a parlare "fuori" dal sistema gestito dal
sito? Per evitarlo non credo che esistano soluzioni "automatiche":
l'admin del sito � obbligato a leggere a manina tutto il carteggio e
censurare eventualmente parti delle mail scambiate.
Neanche un sw scritto apposta che effettui il parsing del contenuto
potrebbe bloccare un'invio fraudolento di indirizzo mail "nascosto" in
una frase di senso comune oppure scritta in una jpg allegata oppure
ancora messa in un sito la cui url viene indicata nella mail da uno dei due.
Insomma: se � vera la premessa e quindi non volete contatti diretti tra
i due, come pensate di risolvere tecnicamente questo "problema"
(risolverlo legalmente � facile: basta un contratto che impedisca
esplicitamente contatti diretti)?
asleo
Semplice: non lo risolvi..
"fatta la legge, trovato l'inganno", è impossibile prevedere tutte le
casistiche, se i due vogliono fare i furbi un modo lo trovano (ad
esempio, se il professionista al termine del primo lavoro inserisce i
propri contatti nello zip da mandare al cliente? L'admin dovrà anche
controllare tutti i file di tutti gli archivi che si mandano?
impensabile).
Da un altro punto di vista, se sia il cliente che il professionista
sono soddisfatti del servizio offerto dal sito, non ci penseranno
nemmeno ad aggirarlo (o meglio, sarà una percentuale molto bassa,
trascurabile).
Mettere li una persona a leggere ed approvare tutta la corrispondenza
degli utenti, apparte che a livello legale sarebbe una gran bella
grana per la privacy (scrivilo nel contratto come ti pare, ma son
sempre grane), è impensabile e inattuabile.
Anche perchè il professionista per forza di cose dopo un pò saprà
esattamente chi è il cliente (o meglio, l'azienda), specialmente se il
lavoro consiste nel fare un sito web, un logo, un programma ad hoc.
O più semplicemente se il cliente si registra col nickname
$nomeazienda.
ovviamente non si può, o meglio non è convenientem in termini di
massima, farlo.
però se uno basa il proprio business solo su questo allora è spacciato,
potresti però offrire anche uno "storage" tipo sourceforge, il
professionista ha a disposizione una comoda interfaccia per caricare e
dare al cliente il "prodotto", nel caso di un sito potresti prevedere un
"area test" dove professionista e cliente vedono il sito direttamente
online ma su un'area fatta apposta.
non so insomma qualcosa di aggiuntivo che invogli a continuare ad usare
il sito.
anche un'auto è un qualcosa che si muove e tutte le auto lo
fanno...tutto sta a vedre qual'è quella che è più veloce, + più comoda o
ofre più gadget per i passeggeri
Questo esempio mi ha lasciato perplesso ;)
Io la vedo un pò come gli agenti di commercio di un'azienda: prendono
la provvigione per ogni ordine che l'azienda gli fà, perchè quando
devono fare un altro ordine chiamano l'agente (che fornisce loro anche
assistenza, in teoria), non l'azienda.
Se il cliente chiama direttamente l'azienda, l'agente non vede nessuna
provvigione: stà quindi all'agente tenersi buono il cliente, andandolo
a trovare, consigliandoli sui prodotti (e non vendendogli la prima
cosa basta che faccia fatturato), etc...
E' una buona idea l'offrire un'area sul sito per condividere i lavori,
nel caso di applicazioni web, ma forse è poco praticabile.
Un'altra cosa che forse si potrebbe valutare, per risolvere un
problema che spesso capita, è il discorso di offrire lo storico di
tutte le comunicazioni: quante volte il cliente dice 'a ma questo non
me lo avevi detto, a ma io non lo sapevo'?
Avendo un terzo strumento imparziale (il sito, appunto) che mostra
tutte le comunicazioni, tutti i passaggi avvenuti, potrebbe essere
utile.
Volendo, ce ne sarebbero di idee interessante e spunti per far si che
sia il professionista sia il cliente si appassionino al sito e non lo
abbandonino più ;)
>> Insomma: se � vera la premessa e quindi non volete contatti diretti tra
>> i due, come pensate di risolvere tecnicamente questo "problema"
> Semplice: non lo risolvi..
Perfetto :) Credevo di essermi perso qualcosa... Infatti io non lo
risolverei, � per questo che ho chiesto.
Giusto per spiegare meglio il mio pensiero, concordo con Argaar sul
fatto che basare un business su questo � da folli. Cos� come riconosco
che a certe condizioni pu� essere un servizio "utile" e/o interessante.
ciauz
asleo
Mhhh, non ne sarei tanto sicuro.. non ci scommetterei niente forse, ma
se il servizio è fatto bene, con strumenti veramente utili ad entrambe
le parti, e costi bassi (tipo 5€ al mese sia per il cliente sia per il
professionista, esempio buttato a caso eh) potrebbe avere un discreto
successo, guarda quelli di rentacoder o getacoder o
comecavolosichiama; hanno un volume di traffico non indifferente...
Se poi su 1000 lavori, 100 fanno accordi al di fuori dal sito per
'fregare' il servizio, bisogna vedere se nei margini c'è spazio per
queste perdite.
sono un genio lo so :D
>
> Io la vedo un p� come gli agenti di commercio di un'azienda: prendono
> la provvigione per ogni ordine che l'azienda gli f�, perch� quando
> devono fare un altro ordine chiamano l'agente (che fornisce loro anche
> assistenza, in teoria), non l'azienda.
>
> Se il cliente chiama direttamente l'azienda, l'agente non vede nessuna
> provvigione: st� quindi all'agente tenersi buono il cliente, andandolo
> a trovare, consigliandoli sui prodotti (e non vendendogli la prima
> cosa basta che faccia fatturato), etc...
>
>
> E' una buona idea l'offrire un'area sul sito per condividere i lavori,
> nel caso di applicazioni web, ma forse � poco praticabile.
beh qui dipende da chi programma e sopratutto quanto � capace e ne ha
voglia...
>
> Un'altra cosa che forse si potrebbe valutare, per risolvere un
> problema che spesso capita, � il discorso di offrire lo storico di
> tutte le comunicazioni: quante volte il cliente dice 'a ma questo non
> me lo avevi detto, a ma io non lo sapevo'?
>
> Avendo un terzo strumento imparziale (il sito, appunto) che mostra
> tutte le comunicazioni, tutti i passaggi avvenuti, potrebbe essere
> utile.
>
> Volendo, ce ne sarebbero di idee interessante e spunti per far si che
> sia il professionista sia il cliente si appassionino al sito e non lo
> abbandonino pi� ;)
oh beh...ci sarebbe da far business pure sulle idee per far business... :D
non ho mai visitato quei siti ma ne ho sentito parlare, alla fine per�
non credo basino il loro business SOLO sul far incontrare gente, penso
che offrano cose che comunque (magari per 5� appunto) uno trova pi�
comodo demandare a loro ed � ben felice di spendere...almeno io la vedo
cos�, se un domani mi servisse penso sarei ben lieto di spendere....
Allora stiamo dicendo la stessa cosa, un servizio del genere non può
fermarsi al far conoscere gente e farli comunicare tra di loro!
Però, il web stà facendo girare milioni di dollari in modi bizzarri,
basti pensare a twitter, facebook, google, etc..
Solo 15 anni fà, chi avrebbe investito su twitter, o google?
si, � la stessa cosa infatti...
> Per�, il web st� facendo girare milioni di dollari in modi bizzarri,
> basti pensare a twitter, facebook, google, etc..
>
> Solo 15 anni f�, chi avrebbe investito su twitter, o google?
guarda...conosco (solo di nome) 4 scemi che l'hanno fatto...io sto
ancora qui a scrivere dalla sedia del mio ufficio...(non che non mi
piaccia farlo, � che preferivo farlo da sopra una piscina) :D
posso dirti che se mi andasse bene fra poco ce l'ho anche io la
piscina...ma non ci credo granch'� c'� chi ha cu*o e chi no, non credo
che in questi casi sia stata solo un'idea, google ha saputo sfruttare
per bene il suo algoritmo, per facebook e twitter io immagino sia stata
solo fortuna che la cosa � piaciuta di pi� di altri, perch� pure msn
spaces, myspace etc pi� o meno erano simili...ma guarda che fine hanno
fatto/stanno facendo....
Fortuna?
Forse.
Io la penso come te, ma forse, invece di fortuna, siamo noi che non
capiamo ancora del tutto il web e i mercati che si sviluppano al suo
interno.
Ti faccio un esempio che dovrebbe fare riflettere: apple fà miliardi
vendendo applicazioni del piffero a 2 euro.
I gestori di telefonia fanno miliardi vendendo suonerie da 1 euro.
Mozilla firefox, è forse il browser migliore al momento e ha ruato
quasi metà del mercato di IE.
Se firefox, invece di essere gratis, costasse anche solo 20 centesimi
di euro, credi vesse avuto lo stesso successo?
Se le applicazioni per iphone fossero gratis, avrebbero un mercato più
grande, credi?