Related
Need some career advice, hopefully I am in right party
How can a contact center agent, from being CRM end user get into CRM consulting? I have theoretical knowledge of CRM implementation, job role of admin, support agent etc. Is there any specific skill that has to be mastered or there are lot of other things to go through than the existing skills.
enlightenment on this would be greatly appreciated.
You are in the wrong place, but I like your question and I have some suggestions.
As a CRM end user you have primarily been concerned with figuring out how to use a process within the system (customer support in your case). CRM consultants need to understand how that process was designed and the tools used to configured it.
A good first step would be to explore some of the tools within CRM. Understanding the Advanced Find is important for CRM consultants and will also give you more power as an end user. Use the advanced find to create personal views to enhance your user experience. Similarly creating personal workflows will enhance your configuration knowledge while potentially providing you with improvements to your user experience.
You will probably be limited in the system you use so I recommend you get access to a sandbox system to play around in. Microsoft provides access to free CRM online systems for exactly this purpose. Practice creating new entities, relationships, and fields of different types. Set up forms and views for your new entities. Create business rules, process flows and workflows to create a process around your new entities.
Taking an online class on CRM customization and configuration can be an easy way to get yourself started with consulting concepts.
Go apply for CRM consulting jobs. CRM consulting is a fairly niche industry and it is difficult for consulting firms to hire experienced CRM consultants. As someone who hires CRM consultants I am generally skeptical of end user experience, but if an end user shows knowledge and aptitude I am likely to hire them.
I've not only worked Tier 2 support for Salesforce but also have worked as a consultant. You need to not only understand business requirements, but implement them in the most efficient manner possible in Salesforce. Getting a job as a consultant typically requires at least a couple years experience as an admin, not an end user, an actual admin. It also typically requires certifications, At least the Administrator, Developer, Sales Cloud Consultant and Service Cloud Consultant certifications, and probably the Advanced Administrator as well. There are a lot of getting started info out there, Salesforce has done a great job. For instance, here is the Workbook
On top of that you need to have an understanding of different industries, for instance the financial industry or manufacturing industry, to understand their business processes. Working in a contact center you should look to gain a deeper understanding in how and why things work there.
As highlighted before, this is not the right place to ask this question as it is a place for more technically oriented questions. That being said, each and every one of us on this forum had to start somewhere, and often with far less experience that you have as a user.
If you're willing to accept an entry level position - and you fall within the age category - then your current experience is the cherry, but the cake will have to be about actual technical experience. Ie. IT engineering degree and/or proven participation in programming projects (open source or otherwise) and anything that may show that you have the foundation skills for an IT consultant.
As the company will be investing a lot and want's to have some certainty that it will have a return on it's investment.
In case you're looking for an above entry level position, then your new employer expects that you can be put to work right away without too much training. As highlighted by BattleCodez, experience with development processes, relevant application certificates and actual work experience are now must-haves. Based on your description, I don't think you have that.
As for a general career move you may want to opt for a Business Analyst role. This is a more Industry Process related role where the business processes are the expected experience. In your case how are calls handled, routed, and what does the client in your industry expect from as a customer. In this role you would be expected to have a deeper then average user understanding of what the tool CAN do, but not HOW that is created.
In this case become a key user, obtain functional admin privileges and move away from the actual calls, to an expertise based supporting role.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I would like to make a performance test on spatial index in Oracle and SQL Server. I would like to include it in my Master of Science work. Is it against dbms's license to publish that kind of results ?
Maybe someone have already met that kind of problem ? I am not keen on digging through boring license stuff ;).
The standard license you agree to when you download software from the Oracle Technology Network (OTN) does state that you're not allowed to disclose benchmarks.
You may not:
<<list of things you cannot do>>
- disclose results of any program benchmark tests without our prior consent.
Microsoft's licenses (such as an older SQL Server 7.0 license) generally have similar terms
Performance or Benchmark Testing. You
may not disclose the results of any benchmark test of either the
Server Software or Client Software for Microsoft SQL Server, Microsoft
Exchange Server, or Microsoft Proxy Server to any third party without
Microsoft's prior written approval.
Most other large companies put similar terms in their license agreements. Whether those license terms are actually enforcable as a matter of law in your case (particularly where this is an academic exercise) and whether either company would ever seriously consider suing over the publication of a Masters thesis is something that you would need to discuss with your university's legal department (and/or the legal department of whoever owns the licenses for the software that you're using). As a practical matter, I would think it's extraordinarily unlikely that either company would ever seriously consider suing a masters student with no money over unfavorable benchmark results. Bloggers and conference presenters publish benchmark results all the time in forums that are much more likely to attract (or repel) potential customers and aren't sued.
I don't think you can license block a valid research paper. That's like Ford saying you can't verify its emissions claims. Gag orders like that on products/services are not generally legal, even if the terms say you agree to it. You could get sued out the ass for slander or libel though if there are flaws in either your experimentation methods or research analysis.
It is REALLY difficult to benchmark to the companies standards in such a way that you won't get sued.
Here's a paper on Oracle technology already. http://www.iisocialcom.org/conference/passat2012/PASSATProceedings/data/4578b119.pdf
"I am not keen on digging through boring license stuff" Well maybe you should be keen if you're afraid of getting sued.
Here's an oracle license from July. Quick glance, i see no restriction. http://docs.oracle.com/cd/E11882_01/license.112/e10594.pdf
Unless you state the specific technology down to the version or link to the license/terms of use, we cannot specifically say.
Here is an interesting read on the "gag" policies, but it's from 2007.
http://genellebelmas.com/documents/Belmas-Larson-Clicking%20away.pdf
Notable in the conclusion:
First Amendment jurisprudence provides considerable support to
the concept of a right to hear. Using the First Amendment to attack
gagwrap clauses directly would require that state action be found
first. Even without state action, however, the First Amendment provides a significant public policy basis upon which gagwrap clauses
might be found to be unenforceable. It remains to be seen how this
public policy rationale will work with the Restatement of Contracts
framework when evaluating gagwrap clauses.
I guess you could if you are using 'Oracle Database Express Edition' for the purpose. But I guess it would be clever to have a quick consultation with an attorney with the Licensing document of Express edition.
Our clients must pay a monthly Fee... if they don't, what is the best way to block the asp.net software usage?
Note: The application runs on the client own server, its not a SaaS app...
My ideas are:
Idea: Host a Web Service on the internet that the application will use to know if the client can use the software.
Issue 1 - What happen if the client internet fails? Or the data center fails?
Possible Answer: Make each web service access to send a key that is valid for 7 or 15 days, so each web service consult will enable the software to run more 7 or 15 days, this way the application will only be locked after 7 or 15 days without consulting our web service.
Issue 2 - And if the client don't have or don't want to enable internet access to the application?
Idea 2: Send a key monthly to the client.
Issue - How to make a offline key?
Possible Answer: Generate a Hash using the "limit" date, so each login try on software will compare the today hash with the key?
Issue 2 - Where to store the key?
Possible Answer: Database (not good, too easy to change), text file, registry, code file, assembly...
Any opinion will be very appreciated!
Ah, the age old issue of DRM. And that's what you're talking about here. Frankly, the fundamental answer to your question is: you can't. No matter what you do to the system, it can be hacked and modded in such a way that your DRM authentication scheme can be bypassed and/or broken.
This is a fundamental fact of software development: it can and will be pirated.
So, the answer to your question is that you will have to trust the client to pay you the fees you determine to be correct (which is the whole point of contracts in this situation).
Any other actions you take are a hardship and annoyance on your paying customer, and has the potential to erode your customer base.
Now, if you want control of your software in the nature described, then do not provide it to users to run on their own servers. Force them to be SaaS. In that way, you control all of that. But this is the only way.
Something that you don't appear to be thinking about, but I have seen networks which do not allow any type of "dial home" solutions, as a majority of the systems were internally focused and thus these internal servers were NOT allowed to contact the outer internet. At all. It was deemed a security risk to even allow them access. How would you handle those networks?
Frankly, if I was the customer, and I paid my fees to license your software (which I installed on my own device) I would be irate if I had to allow that device access to the internet in order for it to work. Doubly so, if the software in question was any type of financial management, customer management, HR management, quality management, inventory management, sales, or just anything related to my business, customers or employees. I don't trust software developers enough to have their software talk to something else when my business-relevant data is held in their software.
In the end, what you are describing is an antagonistic approach to take with your paying customers. If you don't believe me, look at the comments that UbiSoft is getting for their latest customer-hating DRM scheme.
IMO, you have two good paths here:
Go SaaS
Ensure your contract has a
bite for non-payment
usually you provide an scrambled key that includes a valid authorization token and the expiration date through which service is paid. Then the installer will use this to "activate" your software. Not sure how this would be viewed if you have 1-2 week periods. you'd want to warn them about upcoming expiration. Also not sure how to tell if they've set their own clock back.
In short, nothing will be perfect.
I've dealt with this before and its not possible to make a perfect system. There are risks in anything you do. The best thing is to weigh your options, and determine the method that has the least likelihood of being hacked and the most likelihood of working correctly and easily for the customer.
Like others have said, they could change their clock and invalidate the license checking mechanism. If you didn't trust the user, you could make the license system connect to your servers. You would then need to ensure that they always have a connection to your servers to check the license.
What if there is a valid reason that they cannot access your server?
Their internet connection has a problem.
YOUR internet connection has a problem.
In that case, should you disable the application? Probably not. But then again, what if they shut down the connection on purpose? Then you would WANT to disable the application.
If you give them a monthly key, you're adding a monthly annoyance and you may lose a customer after a while (people tend to do business with those who make it easy).
For example: If you base it on their clock, and the application needs their clock to be accurate for some reason, then its unlikely that the customer will change their clock.
I agree with Stephen but ultimately, I think that your contract is your best ally here.
As been previously mentioned, you don't want to inconvenience customers, especially if you have a large deployment.
As for SaaS, if I were a customer using your product and you said that the model is changing and we need to access the software from your server and ours must be decommissioned, I'd not be happy. I'd probably use the opportunity to switch packages.
In corporate settings, the contract really is the best way to handle these issues. I've worked on licensing issues for desktop and ASP.NET applications and they can cause a number of headaches for both you and your client.
However, if you insist on using something like this I suggest you go with a middle ground. Instead of only unlocking the application for a week or two, provide a license for 6 months or a year. This way, if you run into licensing issues (and you will run into issues) they only occur once a year rather than a couple of times per month. That will be cheaper for you in support and your clients will be less unhappy about dealing with licensing issues. If the company stops paying and you need to terminate the license you can handle that on a one-off basis, using contract enforcement as needed.
On the web service or client license options, I think a good license system would incorporate both. A client license to provide a the application a stable license and a web service to generate and deliver the license key when it is time for the application to be renewed. If the client won't allow the application to call home to get the license key also provide a manual entry method.
If you are going to store a license on the client, do not try to build a component yourself. There are many components available which will be much more robust and reliable than the one you build. There is a .NET .licx-based licensing method and a number of 3rd party methods that you can use. Which one is most appropriate depends on your scenario: how flexible you want the license and what other options you need. Most importantly, find something reliable - any time your customers spend fixing problems caused by licensing is non-productive for them and will reflect poorly on the application.
The important thing to keep in mind is that no system is fool proof. If your application is valuable, someone is going to figure out how to steal it. But at the corporate level and with custom software it's more likely the licensing will be used to remind people to pay rather than stop wholesale piracy.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
This is the only product that I know that a consumer must agree to something that only lawyer can (something) understand. I'm sure car accidents kill more people each year than software accidents. But I don't sign anything like an EULA when I buy a car.
So why does software have EULA? Were there a bad accident that triggered the need for software companies to protect themselves? (and what was the first software that had EULA?)
[Update] Just to clear my point: I don't understand why software have EULA. No other product that I can think of does (not even gun)! So what makes software different that this product needs some sort of "liability limitations"?
By the way, Wikipedia says that "The legal status of shrink-wrap licenses in the US is somewhat unclear."
The difference is that you are purchasing a license to use software, not the software itself (which the software company still owns). The EULA stipulates the method with which you can use the software. Similar agreements are in place when you rent things (e.g. a home), lease equipment, etc.
An EULA is designed to be a contract that conveys or limits “usage” rights, hence the name End User Licensing Agreement. It has nothing more to do with a copyright than the mortgage loan contract that I have with my bank. That is why the legality of shrink-wrapped licenses is questionable. It is a contract that you do not get to read until after you purchase a product. It is clear from many responses here that the vast majority of people have not wrapped their heads around the idea the copyright does not extend to “usage” rights.
One responder wrote “Actually, the book is yours but the rights to the book are not. Just as in software, you purchased the physical media, but are bound by law on how you can use it.” Nothing could be farther from the truth. There is no law that restricts how you can use the book. Any restriction on usage would have to be agreed upon by you and the retailer as part of the sale.
Consider that in the absence of copyright, the copying and distribution of books would be perfectly legal. A book would be typical tangible property and nothing more. Copyright limits your ability to legally copy and distribute the content of the book. No additional agreement is necessary. Copyright in no way dictates how you can use your book and copyright law does not convey to the author the power to convey, limit, or negotiate “usage” rights. The only way that they can limit usage rights is through a separate contract that would have to be completed as part of the sale or rental.
There was some confusion regarding the GPL. The GPL is not an EULA. It is a copyright license that permits copying and distribution of the content so long as you comply with the restrictions of the license. In absence of the GPL (say you choose not to accept it), you can still use the software, but you are restricted from copying or distributing the software by Copyright Law.
EULA exist for various purposes. Companies that develop software want to negotiate a position that puts them at the least risk and gives them maximum leverage.
If a consumer receives software without any license, consider what they might consider their rights:
They may believe they can copy the software, as many times as they want.
They may consider re-selling the software, and still keeping a copy for them self.
They may believe the software must work perfectly, with zero bugs (as they understand a bug)
They may believe it is fully waranteed against any perceived defect, and try to return it, for a full refund, at any point in the future.
In short, the EULA disabuses consumers of these notions. It defines ownership and copyright of the software, limits on its use, distribution, features, and quality.
Now it is true that as lawyers get involved in the EULAs more and more, stranger and stranger provisions creep in, such as provisions that you cannot review the software on a blog, or you cannot bad-mouth the software to the press, or that the publisher owns content created with the software.
But fundamentally, the EULA is supposed to be about the producer and the consumer coming to an understanding of what is, and is not, an acceptable use of the software.
Actually, what is quite funny, in Germany EULAs are pretty much legally-non binding, since you only get to see them after the purchase, so for us the answer to your question is:
To intimidate the user from doing stuff the company does not want
There are basically three reasons for EULAs:
Software is much more copyable than any other product I can think of. It is almost never left on its distribution medium. That creates a huge temptation to, for example, buy one copy of Windows and install it on all of a company's thousand computers. Developers want to explicitly lay out how many computers the software may be installed on.
Software often has undetected problems. Even the best QA department never finds all the bugs in a software product. Developers know this and want to be legally covered.
Software can often be easy to take apart to discover a developer's trade secrets or other information the developer doesn't want others to know. Developers want to legally restrict this to protect their advantage over competitors.
Of course, there are sometimes other reasons for other terms. EULAs for Apple's Mac applications, for example, usually state that you can only install the software on an Apple-branded computer; this ensures that Apple's software (which is usually sold much cheaper than it would be from any other developer) increases sales of Apple hardware. The GNU GPL tries to ensure that the innovations in derivative software remain available to the community that developed the original. There are as many reasons as there are clauses.
It depends on the exact wording of the EULA. Often, it's written to reinforce existing laws, such as copyright, by directly informing the user that it's unlawful to copy the program. It also adds on other restrictions such as no reverse engineering, restricting the intellectual property.
Additional clauses may include "not to be used in nuclear projects" or similar. This is merely covering the developer's bases, as it is extremely unlikely that a nuclear system developer would use a non-realtime, non-approved system without extreme amounts of research.
A further clause could restrict certain classes of users, such as military or government, which the developer feels strongly against.
As for which software had the first EULA, I have no idea.
Cars and guns technically have something like a EULA... we just call them "licenses". You have to learn the limitations and rules of their operation, then take some tests and sign some papers.
Nobody has mentioned the obligations of the provider, which are often in the EULA too. If I make your software a critical piece of my corporate infrastructure and you go bust I want to be able to get my hands on the code so your failure doesn't precipitate mine.
As someone said, this is more akin to a rental agreement than a purchase agreement, which is why the analogy with a gun does not really apply.
For proprietary software, License tells about your right to use specific software copy and impossibility to re-sell it, also your and software authors rights and charges
For open source software, License also tells about your right and charge about source code (distribute, do not do that, do that with limitations)
When you use a gun at a firing range, don't you have to sign some type of release or waiver? The logic is similar.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
A while back I worked with a software company that sold a specialized software product. Ever so often they would release a patch for free and a new version that would require an upgrade fee. This is typically how the software industry works.
After some time the company decided on a new strategy, Subscription based software. This turns out to be a way for the software company to charge a small, incremental fee for each "transaction" that is performed on their software. Under this model the patches and upgrades were included in the per/transaction fee and there was a 'true up' in the number of transactions every so often in order to collect their fees.
To me this seems like a better way to develop and sell software. The software company gets continual income stream, the customer doesn't have to worry about upgrade costs and such, and if the customer gets really big then your income stream grows with their growth.
The problem (and reason for this question) is that I don't see anyone doing that anymore. Is it because this model doesn't work? Have I taken an overly simplistic view of developing and selling software without seeing some of the negative sides of this model?
[EDIT] I am interested in the developers opinion on whether writing Subscription based software is a good way to develop software.
So this question is directed towards the professional developers who have worked on commercial applications: Can anyone speak with experience on this model and why it does/doesn't work?
I used to work for a company which moved from product license to subscription based model. Here are some observations about that:
Offer both product license and subscription models
In product license: user buys 'n' number of seats for their use.
In subscription models, customer buys your software for 'x' months time and 'y' people.
It will help you a lot if your company also develops 'consultants' who will work with your customers to get the software implementation etc at client site (any required installation, training etc)
In fact if you see services like GMail enterprise, Fogbuz etc they give different pricing options:
where you want the app hosted: your servers or their servers
you will be charged $x per number of people using the software
I think a subscription model (time based) will definitely work in the current times and in fact the cloud model helps towards such freedom in revenue models: for example, you can choose to 'subscribe' to a cloud database rather than purchasing a database server.
Yes it does. See salesforce.com for an example.
Red Hat seems to think it works. Buy a year of support get all the upgrades/etc/etc. Except they let you keep the product when the year is up (so.. I guess customers like that too =).
It's not exactly the same but basecamp from 37Signals is very succesful with a monthly fee basis, and FogBugz also uses the same model. The approach you're talking about here seems similar to the MircoPayment idea that was seen as a revenue earner in the early days on the web. I'm not sure if anyone succesfully made money from that model, I'm sure a lot of VC was spent trying.
[Edit] I think this an exellent way for small ISVs to run their businesses. The combination of SAAS and subscription is a great way of getting revenue quickly. There are a number of advantages
1) Continuous revenue
2) Small or zero initial payment, brings customers in, beats that credit card price point issue (it's easier to charge $10/month than $100 one off)
3) Builds a solid relationship between ISV and vendor
4) Chance to upsell, assuming the offering is good
And the only way you're going to be a big software vendor is by being a small one first.
Due to the nature of software development a subscription based model is really the way to go, but how do make sure that you have continues updates that actually make software worth subscription fees.
If you're providing a service it's a lot easier to motivate subscription frees but if you're planning on having people pay monthly for monthly releases, well than that's a thin line between success and utter failure. I don't see how this would work with most software.
Update: #Dscoduc
I would call that a service then. Make a clear distinction between software release schedule and support. If you want to charge for a premium support deal well that service gonna have to be pristine. But I do see how it could work. People might end up buying subscription based software on the premises that they will be able to tailor it to fit their needs without programming experience and at a low cost.
Your challenge lies in being able to listen to your customers and really find a way of taking their feedback and making that the foundation for your software life-cycle and that's not going to be an easy thing to do.
Maybe we should petition stackoverflow for a way of marking content not related to programming but interesting to programmers.