I agree.

I would like to let a supplier access to a view and would not like him “to move around and about” the application.

ADJ

[Reply]

I agree.

I would like to let a supplier access to a view and would not like him “to move around and about” the application.

ADJ

[Reply]

I think that the functionality is already there using the HTTP API interface using a public website (this allows adding records and querying views without having access). However, that ends up being more difficult to implement. I would like some users to simply be able to add maintenance request entries and maybe query views, similar to your IT Tracking example. They would be able to add requests via a simple web form and check the status of their requests (based off an email address), and perhaps (but not necessarily) be able to see other requests. However, like your example, paying for 4000 users is not very reasonable. It is hard to imagine a per user fee; perhaps a per database table charge (the IT or maintenance requests table) with no preset users.

[Reply]

I think that the functionality is already there using the HTTP API interface using a public website (this allows adding records and querying views without having access). However, that ends up being more difficult to implement. I would like some users to simply be able to add maintenance request entries and maybe query views, similar to your IT Tracking example. They would be able to add requests via a simple web form and check the status of their requests (based off an email address), and perhaps (but not necessarily) be able to see other requests. However, like your example, paying for 4000 users is not very reasonable. It is hard to imagine a per user fee; perhaps a per database table charge (the IT or maintenance requests table) with no preset users.

[Reply]

Hi, Dave,

Yes, the functionality you describe is definitely there! We are working on the difficulty piece with this possible option.

Tell us more about why a per user charge is hard to imagine? For example, we could always make that “reasonable”. Reasonableness being in the eye of the beholder, of course! But I’m guessing there is something more to your comment on that. Is it that you don’t really view them as users per se, which might mean that you never would need to “act” on them. So if it is a help desk request, you just need their name, not to have some of the “user” type features.

Thanks for your input!
Jana

[Reply]

Hi, Dave,

Yes, the functionality you describe is definitely there! We are working on the difficulty piece with this possible option.

Tell us more about why a per user charge is hard to imagine? For example, we could always make that “reasonable”. Reasonableness being in the eye of the beholder, of course! But I’m guessing there is something more to your comment on that. Is it that you don’t really view them as users per se, which might mean that you never would need to “act” on them. So if it is a help desk request, you just need their name, not to have some of the “user” type features.

Thanks for your input!
Jana

[Reply]

Not sure I fully understand the origin of this topic, but I assume QB is responding to numerous requests for varying functionality….and is looking at it in a very generic sense (which is probably good).

My need is to have an easy but still robust way to get info out to my clients in a “My Account” approach. I have started to implement something, but I anxiously await the time when QB would have this functionality built in so that we could relatively easily create this access for our clients. I do believe it could dramatically increase the use of the QB product since right now it is more of an internal tool. Not sure if QB is interested in going that way, but appears to me to be a huge opportunity.

If this notion of a “Simple…User” is intended to maybe be a first step in that direction then that’s good. Pricing is always an important consideration in whether folks will use it. I think it will depend on just how flexible it is…i.e, the more flexible the usage, the more creative ways people will use it and therefore the need for payment options (e.g., maybe reduced per user, or reasonable fixed charge).

[Reply]

Not sure I fully understand the origin of this topic, but I assume QB is responding to numerous requests for varying functionality….and is looking at it in a very generic sense (which is probably good).

My need is to have an easy but still robust way to get info out to my clients in a “My Account” approach. I have started to implement something, but I anxiously await the time when QB would have this functionality built in so that we could relatively easily create this access for our clients. I do believe it could dramatically increase the use of the QB product since right now it is more of an internal tool. Not sure if QB is interested in going that way, but appears to me to be a huge opportunity.

If this notion of a “Simple…User” is intended to maybe be a first step in that direction then that’s good. Pricing is always an important consideration in whether folks will use it. I think it will depend on just how flexible it is…i.e, the more flexible the usage, the more creative ways people will use it and therefore the need for payment options (e.g., maybe reduced per user, or reasonable fixed charge).

[Reply]

Not sure I fully understand the origin of this topic, but I assume QB is responding to numerous requests for varying functionality….and is looking at it in a very generic sense (which is probably good).

My need is to have an easy but still robust way to get info out to my clients in a “My Account” approach. I have started to implement something, but I anxiously await the time when QB would have this functionality built in so that we could relatively easily create this access for our clients. I do believe it could dramatically increase the use of the QB product since right now it is more of an internal tool. Not sure if QB is interested in going that way, but appears to me to be a huge opportunity.

If this notion of a “Simple…User” is intended to maybe be a first step in that direction then that’s good. Pricing is always an important consideration in whether folks will use it. I think it will depend on just how flexible it is…i.e, the more flexible the usage, the more creative ways people will use it and therefore the need for payment options (e.g., maybe reduced per user, or reasonable fixed charge).

[Reply]

Not sure I fully understand the origin of this topic, but I assume QB is responding to numerous requests for varying functionality….and is looking at it in a very generic sense (which is probably good).

My need is to have an easy but still robust way to get info out to my clients in a “My Account” approach. I have started to implement something, but I anxiously await the time when QB would have this functionality built in so that we could relatively easily create this access for our clients. I do believe it could dramatically increase the use of the QB product since right now it is more of an internal tool. Not sure if QB is interested in going that way, but appears to me to be a huge opportunity.

If this notion of a “Simple…User” is intended to maybe be a first step in that direction then that’s good. Pricing is always an important consideration in whether folks will use it. I think it will depend on just how flexible it is…i.e, the more flexible the usage, the more creative ways people will use it and therefore the need for payment options (e.g., maybe reduced per user, or reasonable fixed charge).

[Reply]

We have a number of applicatons that could benefit from this. For example, we would like to have a scholarship application. This would include an application form that would not normally be completed in one sitting. So we would need to issue a large number of passwords that would be used for a very limited time. Another example would be to have a large number of donors create profiles that they could maintain and that could be matched up with giving/investment opportunities. Again, we would need a large number of passwords and a very simple user interface. Another example might be workshop or class registrations. A user would create a profile and register for workshops once or twice a year. We would also need a much eaiser way to issue a large number of passwords … perhaps importing a list.

I like the idea of pricing base on the application/tables rather than number of users. Maybe a limited Quickbase version … 3-5 tables, limited number of fields(?), limited functionality (no multi-record functions), no ability to create or modify views, etc.

[Reply]

We have a number of applicatons that could benefit from this. For example, we would like to have a scholarship application. This would include an application form that would not normally be completed in one sitting. So we would need to issue a large number of passwords that would be used for a very limited time. Another example would be to have a large number of donors create profiles that they could maintain and that could be matched up with giving/investment opportunities. Again, we would need a large number of passwords and a very simple user interface. Another example might be workshop or class registrations. A user would create a profile and register for workshops once or twice a year. We would also need a much eaiser way to issue a large number of passwords … perhaps importing a list.

I like the idea of pricing base on the application/tables rather than number of users. Maybe a limited Quickbase version … 3-5 tables, limited number of fields(?), limited functionality (no multi-record functions), no ability to create or modify views, etc.

[Reply]

I love this concept! We are just working through a solution to somehow publish basic dashboard information and simple lists with search capability to provide IT project/work order statistics to the rest of the organization but do not need to have individual users do more than view. Perhaps a setup of a simple user with their own “overview page” with limited views and search/view would be sufficient.

As far as pricing, I prefer bulk and w/out having to maintain each individual user administration. How about pricing for root email addresses or something. Ie. pricing for X# of concurrent users for email root address for X@abccompany.com?

[Reply]

I love this concept! We are just working through a solution to somehow publish basic dashboard information and simple lists with search capability to provide IT project/work order statistics to the rest of the organization but do not need to have individual users do more than view. Perhaps a setup of a simple user with their own “overview page” with limited views and search/view would be sufficient.

As far as pricing, I prefer bulk and w/out having to maintain each individual user administration. How about pricing for root email addresses or something. Ie. pricing for X# of concurrent users for email root address for X@abccompany.com?

[Reply]

Thanks for the great feedback! A couple of questions:

Tony – Can you give me some more details on getting info out to your clients on a “My Account” approach? Are these current QuickBase users that could utilize something like the “Alerts” functionality for broadcast messages, or are the details more specific to the users (maybe using notifications?)

Larry – For your simple users, you mentioned issuing them passwords. Obviously we are super-security conscious here but also want to make sure we provide the right solution to our customers. Do you think your simple users would not want to go through our current registration process themselves?

Gloria – When you say each of your users would have their “own overview page” do you imagine a generic overview page for each “simple-role” (i.e. Show a view of all work orders) or an overview with more permissions (i.e. Alex only sees work orders that were submitted by him?) I’m trying to get more ideas on how this functionality may be implemented.

Thanks!

[Reply]

Thanks for the great feedback! A couple of questions:

Tony – Can you give me some more details on getting info out to your clients on a “My Account” approach? Are these current QuickBase users that could utilize something like the “Alerts” functionality for broadcast messages, or are the details more specific to the users (maybe using notifications?)

Larry – For your simple users, you mentioned issuing them passwords. Obviously we are super-security conscious here but also want to make sure we provide the right solution to our customers. Do you think your simple users would not want to go through our current registration process themselves?

Gloria – When you say each of your users would have their “own overview page” do you imagine a generic overview page for each “simple-role” (i.e. Show a view of all work orders) or an overview with more permissions (i.e. Alex only sees work orders that were submitted by him?) I’m trying to get more ideas on how this functionality may be implemented.

Thanks!

[Reply]

Correct … The email from Quickbase corpsales gets caught in their spam filters, or they ignore it, plus we would have to provide access to hundreds or thousands of users. Then, the MyQuickbase page is confusing (they just want to access one application) and the “getting started” popup is irrelevent. We just want to give them access straight into a simple application. Very simple self-registration would be great … similar to amazon or gmail. The idea of charging for concurrent users is really good. We might have 1000 users but only 25-50 at any given time.

[Reply]

Correct … The email from Quickbase corpsales gets caught in their spam filters, or they ignore it, plus we would have to provide access to hundreds or thousands of users. Then, the MyQuickbase page is confusing (they just want to access one application) and the “getting started” popup is irrelevent. We just want to give them access straight into a simple application. Very simple self-registration would be great … similar to amazon or gmail. The idea of charging for concurrent users is really good. We might have 1000 users but only 25-50 at any given time.

[Reply]

I imagine a overview page for the simple user role, not necessarily based on their user id. Since I assume that the simple user will not interact with the system other than “viewing,” I don’t expect that user to even have potentially records that may be associated with that person. I’m thinking basically the concept of a group or user role, that I can set with a long list of users who has limited access & settings to manage. They would all see the same set of views/pages with search for specific information.

[Reply]

I imagine a overview page for the simple user role, not necessarily based on their user id. Since I assume that the simple user will not interact with the system other than “viewing,” I don’t expect that user to even have potentially records that may be associated with that person. I’m thinking basically the concept of a group or user role, that I can set with a long list of users who has limited access & settings to manage. They would all see the same set of views/pages with search for specific information.

[Reply]

I’d like people to be able to enter in a record and then come back and edit that record. They should not be able to view other records. They should be able to add additional records, and also “Add Similar” their own records.

[Reply]

I’d like people to be able to enter in a record and then come back and edit that record. They should not be able to view other records. They should be able to add additional records, and also “Add Similar” their own records.

[Reply]

Alex…the “My Account” functionality refers to very specific data relative to the client.

[Reply]

Alex…the “My Account” functionality refers to very specific data relative to the client.

[Reply]

I don’t have a lot of time right now to get into details, but I certainly this this would be a great addition to QB.

One client I have has an internal process that they plan to manage using QB, with about 50-80 staff using QB with full read/write access. They would love to also enable their vendors (100+) to log in just so that each vendor could view information pertaining to themselves. For reasons I don’t have time to discuss here, enabling vendors to read some limited information would be a great for their business processes. But adding 100 users at the current cost would be too expensive for them, and it would seem strange to have the cost for that limited vendor access to be the same as the full access for internal staff.

So I encourage you to add this feature. I can think of some other uses also.

(In the example that I gave, whether this is rational or not, the idea of paying for an account for each vendor would be rejected by some in the organization off-hand; but the concept of sharing limited information with vendors – at a lower cost – would be more acceptable. It’s partly about how it is packaged and the perception that creates.)

[Reply]

I don’t have a lot of time right now to get into details, but I certainly this this would be a great addition to QB.

One client I have has an internal process that they plan to manage using QB, with about 50-80 staff using QB with full read/write access. They would love to also enable their vendors (100+) to log in just so that each vendor could view information pertaining to themselves. For reasons I don’t have time to discuss here, enabling vendors to read some limited information would be a great for their business processes. But adding 100 users at the current cost would be too expensive for them, and it would seem strange to have the cost for that limited vendor access to be the same as the full access for internal staff.

So I encourage you to add this feature. I can think of some other uses also.

(In the example that I gave, whether this is rational or not, the idea of paying for an account for each vendor would be rejected by some in the organization off-hand; but the concept of sharing limited information with vendors – at a lower cost – would be more acceptable. It’s partly about how it is packaged and the perception that creates.)

[Reply]

Pricing for concurrent users seems like a good option.

[Reply]

Pricing for concurrent users seems like a good option.

[Reply]

Would you please e mail me with instructions for me to find samples of what you do? Real or fake data base set ups?

I am totally frustrated reading about what your company can do, or will do in the future. I don’t want to hear shining stories of how great you are! Never let a salesmen build your sample! I WANT A DEMONSTRATION TO CONVINCE ME TO WANT YOU AND NOT SOMEONE ELSE TO DO MY DATA BASE?

If this sample is not simple enough for me to use, what’s the point? I know how to create a data base, I don’t need practice. I want you to show me what YOU DO! If your afraid someone will steal an idea from you, then your ideas aren’t that good or complicated in the first place! If I wanted to do it myself, I wouldn’t be here in the first place!

SHOW ME SOMETHING! STOP TALKING!

Ray O’Mara

[Reply]

Would you please e mail me with instructions for me to find samples of what you do? Real or fake data base set ups?

I am totally frustrated reading about what your company can do, or will do in the future. I don’t want to hear shining stories of how great you are! Never let a salesmen build your sample! I WANT A DEMONSTRATION TO CONVINCE ME TO WANT YOU AND NOT SOMEONE ELSE TO DO MY DATA BASE?

If this sample is not simple enough for me to use, what’s the point? I know how to create a data base, I don’t need practice. I want you to show me what YOU DO! If your afraid someone will steal an idea from you, then your ideas aren’t that good or complicated in the first place! If I wanted to do it myself, I wouldn’t be here in the first place!

SHOW ME SOMETHING! STOP TALKING!

Ray O’Mara

[Reply]