-
Leads: https://app.futuresimple.com/apis/leads/api/v1/custom_fields.json
-
Contacts:
| # delete local tag '12345' | |
| git tag -d 12345 | |
| # delete remote tag '12345' (eg, GitHub version too) | |
| git push origin :refs/tags/12345 | |
| # alternative approach | |
| git push --delete origin tagName | |
| git tag -d tagName |
There are a lot of CRM systems in the wild. Some of them are even free but every one I've seen seem predicated on one factor -- money. Specifically, which customer bought which widget, which customer hasn't bought widgets for a year, how many millions in what widget line were bought across all sectors of a market. This is great; this is a necessary thing for 99% of CRM users out there but I work in academia, and specifically in libraries, and what I wasn't seeing was a CRM focused on librarian-patron interactions -- what professor published which work, how many instruction sessions did this department need. I want something like a hopped-up Rolodex that can detect patterns and gank info out of academic databases.
I'm hoping this can be that. At some point. When I figure out what I'm doing.
| .ui-datepicker { | |
| background-color: #fff; | |
| border: 1px solid #66AFE9; | |
| border-radius: 4px; | |
| box-shadow: 0 0 8px rgba(102,175,233,.6); | |
| display: none; | |
| margin-top: 4px; | |
| padding: 10px; | |
| width: 240px; | |
| } |
UK Flooring Direct would like their CRM to contain information that helps them determine who a prospect/customer and where in the purchase cycle they are. This data will be used by the Marketing team (but possibly also by the Contact Centre team) to discover interesting customer semgents which can be targeted.
The CRM system should store high level attributes about a person, not log level information. For example, if a person visits 20 pages of the website, the following attributes against a person's CRM record.
Total Pageviews: 20
| # This is a template .gitignore file for git-managed WordPress projects. | |
| # | |
| # Fact: you don't want WordPress core files, or your server-specific | |
| # configuration files etc., in your project's repository. You just don't. | |
| # | |
| # Solution: stick this file up your repository root (which it assumes is | |
| # also the WordPress root directory) and add exceptions for any plugins, | |
| # themes, and other directories that should be under version control. | |
| # | |
| # See the comments below for more info on how to add exceptions for your |
| <?php | |
| $view = new View($this, false); | |
| $view->set(compact('some', 'vars')); | |
| $html = $view->render('view_name'); |
